Following our last post Calling Zig from Go, we can also utilize Zig to call Go. There are two possible approaches here, using go tool to generate C and importing it in Zig, or building a library and linking it with Zig. I opted for the library route from Go. It should be a more general use-case that can be applied to other languages as well.

Environment Assumptions:

*************************

• Golang 1.18+ [>]
• Zig 0.10.0-dev+ [>]
• An x86_64 architecture.

Files:

******

• hello.go
  

package main

import "fmt"
import "C"

func main() {
}

//export HelloGopher
func HelloGopher() {
        fmt.Printf("Hello Gopher")
}

Here we need the comment decoration to export our HelloGopher symbol for Zig to use.



• hello.zig
  

const std = @import("std");
pub const go = @cImport({
    @cInclude("libhello.h");
});

const stdout = std.io.getStdOut().writer();

pub fn main() !void {
    try stdout.print("Hello Ziguana\n", .{});
    go.HelloGopher();
}

Using the @cImport and @cInclude built-ins we can import the header file autogenerated by the Go c-archive build process. This translates the header from C to Zig, to see what is generated by this process you can run zig translate-c libhello.h after the build process.



• build.zig

const std = @import("std");
const Builder = std.build.Builder;

pub fn build(b: *Builder) void {
    // Standard target options allows the person running `zig build` to choose
    // what target to build for. Here we do not override the defaults, which
    // means any target is allowed, and the default is native. Other options
    // for restricting supported target set are available.
    const target = b.standardTargetOptions(.{});

    // Standard release options allow the person running `zig build` to select
    // between Debug, ReleaseSafe, ReleaseFast, and ReleaseSmall.
    const mode = b.standardReleaseOptions();

    const exe = b.addExecutable("hello", "hello.zig");
    exe.linkLibC();
    exe.linkSystemLibrary("hello");
    exe.addIncludeDir("./");
    exe.addLibraryPath("./");
    exe.setTarget(target);
    exe.setBuildMode(mode);
    exe.install();

    const go = build_go(b);
    const make_step = b.step("go", "Make go executable");
    make_step.dependOn(&go.step);

    const run_cmd = exe.run();
    run_cmd.step.dependOn(b.getInstallStep());

    const run_step = b.step("run", "Run the app");
    run_step.dependOn(&run_cmd.step);
}

fn build_go(b: *std.build.Builder) *std.build.RunStep {

    const go = b.addSystemCommand(
        &[_][]const u8{
            "go",
            "build",
            "-buildmode",
            "c-archive",
            "-o",
            "libhello.a",
            "hello.go",
        },
    );
    return go;
}


There is not much that has changed from our last build.zig, other than the steps being reversed. We need to call the go step before our default step so we can link the produced library with our Zig program. Note that for the library to be found it must be named libhello.a and be produced in our defined Library search path (the current directory.)

Running zig build go && zig build will compile the executable.


Calling Go!

linux@solar ~/P/goz> ./zig-out/bin/hello
Hello Ziguana
Hello Gopher





Conclusion:

*************




Zig and Go interop feels painless. Both are innovative languages with different but compatible goals. Go has the advantage of a huge ecosystem of libraries and being able to tap into that with Zig seamlessly is a powerful tool. There has been a handful of times when I wanted to vendor a library that simply did not exist in C, and having Go as an additional option will help cover more bases.