I'm not sure if your question is rhetorical, but Go doesn't have the concept of compiled library that you can link to another binary.

So in Go you make available the library's source code, and the end-user will download it at build time, or vendor it in the source tree.

Which is a non starter for businesses that don't ship source code.

Businesses that want to sell libraries without a source code license can ship APIs.

Not sure I understand what you mean here. How do I ship the API of my library without shipping the library?

Sure, if they don't care about performance.

Not only it doesn't work in all platforms, it uses a bare bones C API with unsafe code, and it hasn't been removed yet due to backwards compatibility, as Russ Cox already expressed his opinion that plugin was a mistake from his point of view.

> Plugins are currently supported only on Linux, FreeBSD, and macOS, making them unsuitable for applications intended to be portable.

uh-huh

but, in all seriousness: I wonder why that is? I struggle to think of a technical reason that go would be unable to load and invoke a .dll even if one had to name it .so https://github.com/golang/go/blob/go1.21.1/src/plugin/plugin...

Right, so it feels like Go hasn't solved this problem. It just completely ignores it.