The mysterious "plugin" package does not yet exist, and won't be in the 1.5 release. I would encourage you to try to implement it and send in the changes. The ideas in the execution modes doc are being steadily filled in by people who need them.
Do you have any pointers as to where do I start? I mean I can see how I can probably do it with a C bridge, but I don't know the runtime well enough to attempt to do it without it. Glad it's written in Go now :)
The fact that it's not necessary to explicitly state which interfaces are implemented by a type is a key design decision in Go. It's not going to change.
Every language decision has pluses and minuses. I think most Go programmers feel that this problem is fairly hypothetical because it doesn't seem to come up for most people in real code. But, you're right, it's possible for it to come up. Every language decision has minuses, including this one.
But the pluses outweigh the minuses, so this is not going to change. Sorry.
I have to credit this as being one of the more original arguments for adding generics to Go: we should do it because it will increase the signal/noise ratio in discussions about Go.
(Personally, I don't mind the ongoing discussions about generics in Go, I just wish they were less repetitive. It's very easy to say "add generics to Go!" It's a little bit harder to actually do it well.)
I think that experienced Go programmers simply write the code using the types they need.
I think the essay is entirely correct: there are certain patterns that are difficult to write in Go. It's hard to write generic code that merges two channels into one. It's hard to write generic code that acts as a future.
But it's easy to write type-specific code to perform those operations. Most Go programs do not need to merge channels of many different types. So people simply write the code they need when they need it.
This is not to say that there is no use for generics. There is clearly a use for generics, and examples using channels are among the strongest use cases. I'm just trying to answer your question about what Go developers actually do.
It's a map[uintptr]unsafe.Pointer. The key is invisible to the collector, but the value is an unsafe.Pointer, which is will be managed for you by the precise collector.
The plugin API uses file names, so discovery would be at a higher level. Go packages impose their own namespace, so there shouldn't be any namespace issues. Introspection is useful, but would be a matter of examining the files using existing packages like debug/elf; it would not be part of the plugin API.
Basically the plugin API is isomorphic to dlopen/dlclose. Everything else is built on top of that.
OK, if true that makes sense. I was interpreting the Name parameter to Open() as being something like a global plugin name rather than a filesystem location.
That combined with the Plugin struct (which hopefully would have something like an iterable Map of exported symbols) resolves the issues I was concerned about. Nice.
The problem is that we hope to move toward a concurrent GC. That means that GC must be able to run concurrently with a long-running cgo call--otherwise a call to some C function that never returns for perfectly valid reasons will block GC forever. And when we have a concurrent moving GC, it is no longer possible to casually pass a Go pointer to C.
In other words, we want to make the Go garbage collector work much better for Go programs, and we don't want calling C to prevent that.
Although the actual plan is not nailed down, I suspect that we will permit passing a Go pointer to C as long as the memory to which that pointer points does not itself contain any Go pointers. The cgo interface will be permitted to either pin the pointer for the duration of the call, or to copy the data to a pinned memory area--your program won't know which will happen.
If you need something more complex to work, you will have to allocate the memory on the C side. It's always OK to pass C pointers to C.
That's a much more reasonable proposal than the prior suggestions of a strict no-Go-pointers-into-C rule, and it'll keep most interfaces working. Some C packages such as qml will still need to change as they allow custom types to travel through C and back into Go, and these pointers may move, but that's certainly not the common case.
You need more than that. You need a server that regularly allocates large amounts of memory and then leaves them unreferenced so that the garbage collector can collect them. Then you also need the program to store data that you control, and to also keep references to that data--after all, if that data is collected, then the faux-pointers no longer pin the other allocations. Overall this does not sound like a common allocation pattern for servers.
When Go gets a precise collector, simple implementations of this will work. Doing this kind of thing in Go requires importing the "unsafe" package, and any memory allocations done by code importing "unsafe" could be marked as possibly a pointer.
However, it would probably be possible to write code involving two packages, one of which does not import "unsafe", to lead to dangling pointers and eventual crashes. That is why you should be careful about code that imports "unsafe".
Actually, the code sample in the grandparent comment obfuscates the memory address by subtracting 1. Even a conservative GC will be confused in this case...
Ah, yes, missed that. Nothing a GC can do about code like that. At least it remains true that this can only happen in Go if you explicitly import "unsafe".
