Hacker News Reader

Beyond linking it is also a problem with ABI compatibility of object layouts, etc. It is so much simpler with more dynamic languages.

View on HN

The C ABI on pretty much any platform defines object layout for structs, which is usually good enough.

The C ABI is nowhere near enough for passing arbitrary Go structs, all you need is a map or a sync.Mutex field and you need to exactly match plugin compilation to caller compilation.

I wish https://pkg.go.dev/plugin was clearly documented as not being a viable 3rd party plugin solution.

It's not enough to pass arbitrary C++ classes, either. The point is that you can still design a fairly expressive API involving structured data within the constraints that the C ABI imposes on you - and that C ABI will guarantee stability. This is how plugins were usually handled in the C++ world, historically speaking.

(There are also higher-level ABIs like COM, but they are usually reducible to the C ABI in practice - e.g. COM can be described entirely in terms of struct and function pointers.)

You can write C plugins, or C-ABI plugins in any language that can do that, and call them from Go just fine. Nobody just considers that a very good way to write Go, or plugins for Go.

Reply on news.ycombinator.com