Reply to teo,
Jarrett Billingsley Wrote:
On Thu, Jul 16, 2009 at 2:12 AM, teo<[email protected]> wrote:
One major problem is the D's inability to create dynamic libraries.
D is a great language, but without that ability it can only be used
for small programs, tools, etc. and never in production.
For one, I question your logic that without dynamic libraries, D can
never be more than a hobby language.
Would you develop an application (excluding tools) as a huge
monolithic executable?
Unless I has some some compelling reasons not to, yes, I would prefer to.
Aside from reasons like needing to be able to modularly update the app or
huge (like GBs) amounts of executable code or some kind of plug-ins via DLLs
approach, (all of those are exceptions, not the rule) I don't see any compelling
reason to not statically link all of /my/ code together. It has the distinct
advantage that things just work without worrying about finding DLLs and checking
there versions. (OTOH shipping DLLs to be used by other people is a different
story.)
For two, there is *no problem*
with creating D libraries on any platform other than Windows, and it
is entirely through Windows' fault that it has the problems it does
with DLLs.
Well, let us assume that you can create dynamic libraries in D and you
need to include in each of them Phobos (later maybe just the D
Runtime). What is the benefit of that? Can you imagine all your nice
dynamic libraries (DLLs, SOs, etc.) written in D and all of them
including a huge “payload”? Wouldn't it be better just a simple
library only containing the stuff you need?
If I'm understanding the situation correctly, what you just described is
ONLY a problem on Windows and only because of a design flaw in the way DLL's
work. Nobody wants it to work that way and it wouldn't if there were another
way to do it.
If the intention is to replace C/C++ some day, why not just provide
a dynamic D library? (like in this project:
http://www.dsource.org/projects/ddl/) It can contain only compiled D
code accompanied with meta-data like platform, version, etc. and be
used only by D programs. No runtime is needed within the DDL. When
the DDL is loaded it will be managed by the same GC which manages
the program itself. Even Phobos can be a DDL.
Maybe I am missing something and that's why I would like to hear
your opinion.
You're missing something :) DDL doesn't require you to have a D
runtime in the shared library because unlike DLLs, DDLs can have
unresolved externals. That's the main issue: DLLs must have
performed all their symbol resolution at link-time, and cannot
automatically load symbols out of the host. So, you end up with all
the runtime duplicated in the DLL. DDLs, as well as shared libraries
on _every other platform_, allow you to have unresolved externals in
the shared library which are linked at *load-time*, so that there is
one runtime, which is in the host, which all the shared libraries
use.
Perhaps I am missing something else ;) because that is exactly my
point. DDLs need neither runtime nor Phobos statically linked. Have a
look at Java for instance - Java developers create packages (not DLLs)
and that is enough. They deploy just the relevant code - no extra
bytes. And yes, I know that the JVM is behind the scene. Exactly this
is the idea here: the D Runtime can act like the JVM.
This isn't my expertise but I think you aren't proposing anything new. What
you are proposing is the way things work /right now/ on Linux and the way
people wish they would work on Windows.
