Re-thinking D's modules

[Paulo Pinto]

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 <russel at 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