Purego – A library for calling C functions from Go without Cgo

Very cool! I will definitely give this a try, I&#x27;ve been looking to build Go bindings to Mach[0] soon.<p>It looks like this would make cross-compiling CGO easier (no target C toolchain needed?)<p>Does this do anything to reduce the overhead of CGO calls &#x2F; the stack size problem? IIRC the reason CGO overhead exists is at least partly because goroutines only have an ~8k stack to start with, and the C code doesn&#x27;t know how to expand it-so CGO calls &quot;must&quot; first have the goroutine switched to an OS thread which has an ~8MB stack.<p>One reason I think Go &lt;-&gt; Zig could be a fantastic pairing is that Zig plans to add a builtin which tells you the maximum stack size of a given function[1], so you could grow the goroutine stack to that size and then call Zig (or, since Zig an compile C code, you could also call C with a tiny shim to report the stack required?) and then eliminate the goroutine -&gt; OS thread switching overhead.<p>[0] <a href="https:&#x2F;&#x2F;github.com&#x2F;hexops&#x2F;mach">https:&#x2F;&#x2F;github.com&#x2F;hexops&#x2F;mach</a><p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;ziglang&#x2F;zig&#x2F;issues&#x2F;157">https:&#x2F;&#x2F;github.com&#x2F;ziglang&#x2F;zig&#x2F;issues&#x2F;157</a>

I thought I had a piece of dust on my screen, but as I scrolled the dust scrolled: what do these 0xB7 characters do in the identifiers? Are they just &quot;name mangling&quot; to keep them from being exported or something?<p><a href="https:&#x2F;&#x2F;github.com&#x2F;ebitengine&#x2F;purego&#x2F;blob&#x2F;v0.2.0-alpha&#x2F;sys_darwin_amd64.s#L28-L29">https:&#x2F;&#x2F;github.com&#x2F;ebitengine&#x2F;purego&#x2F;blob&#x2F;v0.2.0-alpha&#x2F;sys_d...</a><p>I noticed another 0xB7 character in a comment, and sure enough it seems to be part of the identifiers: <a href="https:&#x2F;&#x2F;github.com&#x2F;ebitengine&#x2F;purego&#x2F;search?q=runtime%C2%B7cgocallback">https:&#x2F;&#x2F;github.com&#x2F;ebitengine&#x2F;purego&#x2F;search?q=runtime%C2%B7c...</a>

I did not know that this could reasonably be done. For some reason it did not occur to me that you could break the chicken and egg problem by simply linking to libdl dynamically; Go binaries are usually static and I didn&#x27;t even realize it had a mechanism for dynamically linking like this.<p>This is pretty cool because you can already do this sort of thing on Windows (using the syscall package, since the Windows Loader is always available from kernel32 anyways) and I use it all the time. Probably the most consequential thing I&#x27;ve done with it is my WebView 2 bindings. But with this, you could probably do the same thing on Linux and Mac with GtkWebkit and ... WebKit, and get a native HTML window without CGo on Windows, Mac, and Linux. Perhaps this has already been done (haven&#x27;t paid attention) but it would make a pretty nice way to get a UI going in Go. (It&#x27;s not like I&#x27;m a fan of using HTML UIs for native apps, but it works pretty well if you don&#x27;t overdo it, and using native widgets on a given platform does mess up predictability a bit, but it saves disk space at least.)

Could I suggest adding a &quot;Motivation&quot; section to the README?<p>It made sense after reading the comment about not needing a C toolchain for cross-compiling CGO but I didn&#x27;t realize it immediately.<p>Neat stuff

An explanation of how this works and what makes it novel would be nice. I&#x27;m not familiar enough to understand how this is better than Cgo.

D does it the easy way:<p><pre><code> extern (C) size_t strlen(const char*); ... size_t length = strlen(p); </code></pre> You can call any C code like that. You can even simply import C code!

Interestingly it’s easy to do this with just standard library on Windows: syscall.NewLazyDLL plus NewProc are enough. (Of course in practice you should probably use golang.org&#x2F;x&#x2F;sys instead.) I’ve never thought about why dlopen isn’t offered in syscall on *nix until now.

Awesome!<p>This would be such a game-changer for server-side rendering Javascript in Go with V8.<p>I&#x27;d love to integrate this into Bud[1].<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;livebud&#x2F;bud">https:&#x2F;&#x2F;github.com&#x2F;livebud&#x2F;bud</a>

This could be very useful for a project I am just starting on.<p>No documentation, and example has no content makes the learning curve a bit steep.<p>Does anyone have any pointers on how to use this?

Quite interesting. That&#x27;s one more option to consider besides using wasm as an intermediary.<p>Thinking about this as I&#x27;d like to call native android libraries.

How is this any different than a mature tool such as SWIG (<a href="https:&#x2F;&#x2F;www.swig.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.swig.org&#x2F;</a>)?<p>I&#x27;ve used SWIG extensively with Python to call C code and import C headers for testing&#x2F;tooling purposes.

I wonder whether I can use it to create a Go library that I can import in Python?

Why?

Can this be used&#x2F;adapted for Rust too?

nice, so this is like libffi but in written in go ?

Nice job!

C should have never ben part of Go to begin with. all this &quot;compatibility&quot; for Google&#x27;s sake made Go for the worse.

I really really want to learn and use Go, I spent months with it.<p>In the end, it&#x27;s a very different paradigm and it is a pain for me to switch from the C-family-syntax to Go and back on a daily basis, and I gave up. Using C, JS, Java, C++, Dart, maybe even Rust(only tried it shortly) on the other hand is much more comfortable and natural for me. Go is just such a different style.<p>Been vastly different does carry some cost shall I say, Go could be a great language for new programmers however.