On Wednesday, 10 May 2017 at 22:13:29 UTC, Lewis wrote:
On Wednesday, 10 May 2017 at 12:52:34 UTC, JN wrote:
PROS
The Rust article mentions build times as a downside. In
contrast, that has been one of the upsides of D for me. My
build time is ~1.75s for a usual-case rebuild (all the game
files), and ~4.5s for a full rebuild (the game, plus all heavy
templates (like regexes), and all library glue code (like
derelict)). Rapid build times are one of the killer features of
DMD, and it makes me happy to know it will continue to be a
focus as development continues.
I have played recently with one D game engine and result was
frustrating. My compile time was about 45 sec! Engine split in
core and actual game module, every time i build game module it
recompiles the engine. Great compile times, yay! The engine
itself is just ~12k LOC, "game" roughly 200 lines. For example
UE4 project with same line count compiles within 50 secs! Of
cource whole D engine takes just 20 secs on single core, while
C++ project takes all my 8 cores. (and for example building whole
UE4 takes almost hour on SSD)
Every changed line of code triggers full rebuild in D (remember,
it does this twice, one for engine, second for game). As C++ user
I find it unacceptable, simply because with PCH such changes is
usually takes 2-3 secs if one don't touch the headers (well okay,
more like 10 secs, still twice faster than D on edit-build-debug
runs).
CONS
The debugger. Rainers is doing great work with Mago, I suspect
it simply needs more developers giving it some love. It's
currently a far cry from the MSVC debugger.
There is no sane x64 debugging on Windows. structs doesn't shows
at all, that just top of the list... But I remember what's was
back in 2011, now we at least can do full debug for x86! And last
time I used OS X(in 2013) that was... well I prefer not to
comment, there was simply no debugging at all.
DLL support. I've made a handful of hacks to druntime to allow
me to implement hot-reloading via a DLL (a la Handmade Hero).
My problems all stem from the fact that a D DLL has its own
copy of the runtime and GC. I use the GC proxy to redirect
calls from the DLL's GC to the EXE's GC, and have hacked
together a similar solution for redirecting the spawning of
threads. On top of that I had to completely disable finalizers,
and pretty much avoid using classes altogether (at least any
that might need to outlive a frame or survive a hot reload).
I'll bet it's no easy task to implement, but if D supported
"light" DLLs (ie DLLs that just work out of the executable's
druntime), probably 2/3 my hacks to
D would evaporate. This all being said, the hot reloading works
marvellously with these changes, and it combined with a <2s
build time makes day-to-day development far more of a joy than
at work.
How did you managed using classes from DLL? I mean in its current
state D unable to cast anything that comes through process/shared
lib boundaries(except on Linux) due to missing type info, right?
And this is serious issue, this is really blocks D from
commercial usage, simply because there is no way to add plugin
support (from user's point of view).
And realistically this is also not so trivial, this requires
making special 'core' library with common classes and interfaces
to include in every DLL and app itself, because one would need to
use both .d and compiled module .obj (for type info, that
annoying unresolved _ClassZ and others) and current build systems
doesn't helps with that all, so all by hand it seems...
Overall, I really like D, but its like feeding on cactus...
