D for Game Development

Sat Aug 8 22:31:42 PDT 2015

On 8/8/2015 7:40 PM, Manu via Digitalmars-d wrote:
> 1. DMD has unsatisfactory codegen for anything other than debug builds.

Do you mean the codegen is slower? But consider that the bottleneck in most 
programs is a small section of code. Taking a good look at the generated code 
for that and comparing with another compiler can often hint at an easy 
improvement to dmd that can address that bottleneck.

But waiting for someone else to discover the same thing on some other piece of 
code means you'll be waiting a long time.

> 2. DMD generates x87 code, and uses real everywhere.

Less so now than it used to. For float and double, it uses SIMD.

> We can't be
> generating new x87+real instructions in 2015. It's deprecated
> hardware!

x87 works on every x86 CPU, and I doubt it will ever go away, deprecated or not. 
Why was it a problem for you?

> 2. LDC has a lot more bugs than DMD (which still has quite a few
> bugs), and the Windows build is new and even more immature still.
> 3. LDC has no debuginfo. **biggest practical issue by far!**
> 4. LDC/GDC are always a few versions behind DMD. This creates an
> awkward/almost-impossible situation when you rely on DMD to build
> debug code, and LDC to build releasable code. Depending on 2 flaky
> compilers is even less fun than one.
> 5. DLL's were really flakey at the time, I'm not sure how they are
> now, but I'm concerned they may not be much better.
> 6. Shared druntime; we were loading D code from DLL's, lots of them.
> It's not really reasonable for each DLL to have it's own druntime
> instance, they need to share one provided by the host app.

I agree, and now we ship a Phobos DLL, resolving that issue.

> 7. D binaries are *gigantic*, I don't know why. D seems to link the
> world, and I'm certain that most of the crap that's linked is never
> referenced or executed... it just makes gigantic binaries for some
> reason, even with line-for-line translations of C/C++ code. That's not
> real good on games consoles where icache is king.

Yes, that's an ongoing problem. I need to spend some time on that one.

> I tried to use D in my current workplace on 3 occasions now, and ran
> into a different set of problems.
> In the first attempt I tried to write a simple vibe.d webserver app,
> but it kept crashing randomly when I was using the API's exactly as
> intended (apparently a client was posting `/n` instead of `/r/n`, or
> maybe the inverse of that, and it didn't like it).

Were these bugs reported?

> In my second attempt, progress was interrupted by some ICE's, linking
> with some C++ code caused various problems.

ICE's in what? What problems?

> A final recent attempt was basically a non-starter on account of no Qt
> bindings that work &&/|| are up to date.

Bindings aren't too hard to update.

> I'm getting pretty close to calling it a day. Is 6 years enough time
> to repeatedly prove to myself that I'm chasing a fantasy?
> People keep talking about Rust, I'm thinking of giving it a shot.
>
> I think D needs a budget, and paid programmers employed to do boring
> shit that makes the whole thing more stable and robust. Mozilla seems
> to have this(?)
> D seems to consistently offer 95% solutions to problems. 95% is not a
> solution, it's just another problem.
>
> Oops, I ranted. Sorry! :)

I think what stalled Remedy's use of D is you left Remedy. Note that while you 
were there I went to Finland largely at my own expense to help make it work for 
Remedy. After you left, there wasn't much interest from Remedy.

I note that I rarely know just what is blocking you. For example, you say above 
you got some ICEs. What ICEs? We cannot fix bugs we don't know about. I would 
also very much appreciate if you would pitch in to help with things that are 
blocking you, like updated Qt bindings. Generally, people around here tend to 
contribute fixes for things that personally interest or block them. Priorities 
for you aren't priorities for others.

D doesn't have a community so large that you can sit back and assume many others 
will run into the same issues you have and will fix them. You have to be more 
proactive.

Looking at open bugzilla issues you've commented on:

https://issues.dlang.org/show_bug.cgi?id=5227
https://issues.dlang.org/show_bug.cgi?id=6343
https://issues.dlang.org/show_bug.cgi?id=8845
https://issues.dlang.org/show_bug.cgi?id=9065
https://issues.dlang.org/show_bug.cgi?id=9137
https://issues.dlang.org/show_bug.cgi?id=10203
https://issues.dlang.org/show_bug.cgi?id=10959
https://issues.dlang.org/show_bug.cgi?id=11541
https://issues.dlang.org/show_bug.cgi?id=12440
https://issues.dlang.org/show_bug.cgi?id=13265
https://issues.dlang.org/show_bug.cgi?id=14260

That's it. None of them seem to be ones you brought up in your post. To get 
attention for issues that are blocking you you absolutely have to file bugzilla 
reports. That doesn't guarantee they will be fixed, but if you do not file them, 
it DOES guarantee that they will NOT be addressed, and you'll get frustrated.