People who write data structures just give up type-safety when doing so. They don't copy-paste code or write template processors, afaik. A Left-leaning Red-Black Tree, for example: http://gopkgdoc.appspot.com/pkg/github.com/petar/GoLLRB/llrb
Holding up Eclipse as an example citing performance is perhaps not the best idea. And Chromium seems to do just fine (performance-wise) using IPC between renderer processes and the main process.
Go fanboys always cite Chromium as a gold example of process IPC and why dynamic loading is not required for plugins.
What people fail to see is that Chromium is just one use case.
An IDE for example, would explode memory wise if every single plugin would be a separate process. Then all plugins that require real time interaction with source code manipulation would suffer from heavy context switching.
Sure, if you do it stupidly, and have a highlighter process per open document or something, it could add up over time. But if you share highlighter processes between documents, you have 1 process that you keep open for the lifetime of the application. A simple HTTP server in Go takes < 5 MB of RAM in its steady state, a server using domain sockets would probably be comparable. And even better, a bug in the highlighter doesn't mean your main application crashes. If it crashes, the parent merely restarts the process. Even better, its more secure, in the sense that you can run your highlighter with absolutely no OS privileges. Also, this allows for plugins written in any language that supports sockets.
All I'm saying is that there's no evidence that IPC isn't performant enough. And IPC comes with security, compatibility, and isolation advantages, to boot.
Note that I'm definitely not saying that dynamic loading wouldn't be nice. Do I miss it, when working with Go? Not for my use cases. "Plugins" for servers don't really make sense. But dismissing Go because it doesn't target every use-case at the moment is somewhat shortsighted.
Well, if I look at my plugins folder I have around 200 jar files.
Many of those do provide more than one plugin, which puts it way above 200 plugins.
The approach one process per plugin won't scale in such cases.
The lack of IPC performance for heavy communication, like it happens with plugins, is the main reason why microkernel based OS are yet to become mainstream.
Are all of those plugins active all the time? I doubt it.
This discussion is getting a little off track.
I'm simply saying that dismissing Go for not supporting plugins is rather illogical, as there are a lot of use cases that have no need of plugins. Servers being a good example of one of these use cases.
Holding up Eclipse as an example citing performance is perhaps not the best idea. And Chromium seems to do just fine (performance-wise) using IPC between renderer processes and the main process.