jLuger.de - Go revised: shared libraries

As I have shown in previous posts thanks to gccgo Go programs could use shared libraries with Go code. Finished? Unfortunately not as there are still some issues and glitches to be discussed.

Using shared libraries via gccgo is officially documented and people where successful at creating and using shared libraries. That are great news as it allows to split larger projects into multiple parts so that the amount of source code that needs to be compiled could be kept low.

While this is a great step forward the static heritage of Go is still visible. There are no methods to dynamically load shared libraries in Go itself. You would need them to great plugins for your application. Maybe plugins aren't an issue for you but think about Java web apps. They are a kind of plugin for Application Servers/Servlet Containers and those are a must in larger organizations. You can't handle a large set of applications without a unified administration environment.

Google seems to solve this by using some kind of "code plugin". This means you have to upload your source to the app engine. Probably not a way a company wants to go.

Does this man Go is useless for corporate scale use? No. Look at Google Chrome. Before it every tab was part of one browser process and now every browser creates a separate process for each tab. Also look at gocode. It is used by every editor/IDE to do the auto completion for Go and it is written in Go. Works like a plugin although it isn't a shared library. Also note that shared libraries open a path for attacks.

I don't know what future will bring us but when you bend your mind a little bit you may imagine that the common administration will be compiled to your app and there will be a minor load balancher distributing the requests from one tcp port to many apps. The resource consumption? Maybe large against an optimized C program but as I mentioned in an earlier article there are people running full blown Application Server on individual virtual machines to separate applications. Running multiple apps under different user on the same machines could provide the same security with much lesser overhead.