undefined | Better HN

0 pointsint_19h3y ago0 comments

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

0 comments

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.

int_19hOP3y ago

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.)

yencabulator3y ago

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.

j / k navigate · click thread line to collapse

0 comments

yencabulator3y ago

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.

int_19hOP3y ago

(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.)

yencabulator3y ago

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.

j / k navigate · click thread line to collapse