On Wednesday, 18 July 2012 at 09:59:03 UTC, Marco Leise wrote:
Am Wed, 18 Jul 2012 10:24:36 +0100
schrieb Russel Winder <rus...@winder.org.uk>:
Go solves the problem by refusing all notion of dynamic
linking and
insisting on static linking of all applications.
... not possible? While I learned a while back that system
calls exist and are not dynamically linked, I wonder how Go
goes about:
* basic system libraries (static linking to kernel32.dll?)
* executable bloat from large OO toolkits like Qt
Don't flame me, just giving the typical set of answers in gonuts,
which you can easily find when searching for .so/.dll discussions.
Use strip to reduce executable size.
* increased memory footprint by not allowing shared instances
of DLLs/SOs
* modular development (e.g. separating "server" and "client"
code in games)
Separate code in common packages, while generating separate
executables.
* dynamically loadable plugins/extensions
From the security point of view loadable plugins are not good.
Better make use of IPC to communicate between plugins.
If you need performance, make use of shared memory as IPC
mechanism,
which incidentally invalidates the security reasons.
* security and bug fixes to libraries used in dozens of programs
(-> recompile of all library users ?)
yes
