Discussion: Porting 58000 lines of D and C++ to jai, Part 0: Why and How

[Hipreme]

I'm developing my engine literally on Windows since the start, 
and I'm even doing Xbox development for it, so, I think my 
experience with D should prove useful.


> 90% of times, the this pointer is missing or wrong
- The only time I found `this` missing was in a bug I just sent 
on issues.dlang: when using with anonymous classes inside 
functions, that seems to be a bug on DMD itself.

> variables on function stacks are often partially or completely 
> missing or wrong
- Never here

> values of variables are sometimes reported wrong without any 
> other visible issues
- Nope


> static foreach expansions are not handled well and confuse the 
> debugger
- I haven't actually debugged this kind of code

> mixins (D’s macro equivalent) generate debug info in a way that 
> causes the debugger to not find the correct file (so you step 
> through disassembly)

- Or you can use -mixin=targetFileToMixin.d, which makes it a lot 
easier to understand what is causing that. All the 
metaprogramming facilities in D doesn't work correctly in all its 
tooling such as code-d or VisualD.

> moving the instruction pointer back to the previous line in 
> visual studio often crashes the program on the next instruction
- I would not play with instruction pointer, so unsafe to do in 
any language


> different compiler phases interact in weird ways that lead to 
> surprises in metaprogramming, while generating misleading 
> errors234
- Yes, I actually got a problem like that when dealing with 
libraries, static if + versions.

> ldc2 is awfully slow to compile5, but sometimes the only choice 
> because dmd has bugs6
- Currently for me it is quite the opposite, I can't build DLLs 
correctly with LDC, and when building with LDC, my writeln/printf 
becomes really buggy.


> D offers a betterC mode that among other things disables 
> garbage collection. However, when using this mode, the standard 
> library does not compile and meta programming7 is significantly 
> hampered.
- BetterC bad

> the documentation is lacking
- Which documentation? Most of the time I could not find was when 
I didn't read the documentation correctly and someone was able to 
point to me


> like order independent declaration in global scopes sometimes 
> breaking with mixins ↩︎
- I have documented a bug related to that

> or like namespaced names not resolving in mixins unless you use 
> a special kind of string literal ↩︎
- Never had

> or like static foreach not being able to insert multiple else 
> ifs after an if ↩︎
- Agreed, if you can put `case` with static foreach, you should 
be able to put `else if`


*Summary*:
I can see the guy over there made 58KLoc of pure template, 
metaprogramming and CTFE abuse. 60 seconds of build time is just 
unacceptable. I do believe though that a project like that is a 
nice case study for D to evolve itself.

Unfortunately, it is sad to see that D is quite in that state on 
its unique features, like being advertising with CTFE and not 
being able to actually use CTFE because it can slow the build 
quite a lot (there was a CTFE cache PR somewhere, saying that it 
was able to make it build much faster, unfortunately, it didn't 
go onwards dunno why).


Although I would not switch D for another language, I don't 
completely disagree with what is said in that blog. And that is 
what I and some other people says: adding new features to D 
should not be priority n° 1, cuz there is a lot of other broken 
things over there that just ruins the developer experience.

Having a clear and better compilation flow with version/static 
if/mixin template/mixin, generating better debug information on 
metaprogramming side (which could also help tooling such as 
code-d and visual D), and after that, making CTFE faster (or 
cached) could make D better in what D offers.

If you code D like C or Java, you won't have much pain with it, 
but if you start using mixin template/alias and other features 
such as that, you'll start to be bitten.