I really like D and want to use D instead of Zig if I can...
But it's difficult to do so! Nothing to do with marketing in my case, at least.
The reasons are :
* `dub` is badly documented and does dumb things like including test code in the generated binary.
* `serve-d` is terrible. It can't handle even my little hello world programs - either crashes or consumes 100% CPU until I manually kill it.
* MacOS support sucks. All the time I have problems: the linker didn't work for years (fixed now). Immediate segmentation faults currently (fixed in nightly AFAIK). C code using the new flat128 doesn't compile (I think it was fixed already?). Just constant frustration.
* Too many features, many broken. It has an experimental borrow-checking feature, I tried to use it but it's largely undocumented. People in the Forum told me to that feature is completely unfinished. It has an allocators package as well, but no idea how I can make use of those like I would in Zig. Would love to see a well written post about that.
Using D in betterC mode is what I am most interested about exactly because it looks more like Zig and C than Java - and performs much better. But currently, that means forgetting about Phobos, the standard library, as that's written exclusively with GC and Exceptions in mind. Maybe that's ok as you can just use all C libraries you want, but would be nice to have some D conveniences to make that worthwhile.
Apart from that, I completely agree that D's comptime and metaprogramming is the best I've seen in any language (except for Lisp of course). All I need to keep using D is much better tooling and clarification about what parts of the language are "half-baked" (especially around DIP1000) and which parts are stable - perhaps "editions" will give us that, will check it out when it's ready. Oh and also top-notch MacOS support... I know that's a moving target but even Zig manages to handle that just fine, why not D?!
Don't use betterC as a global @nogc attribute. This flag does more than just remove the garbage collector and adds extra checks that can sometimes be overly restrictive. If writing GC-free code is important and compiler assistance is really needed, then add @nogc: at the top of every file. But even that is a bit extreme because the @nogc attribute is just a hint to the compiler, telling it to check that called functions also carry that hint. It is not essential for writing GC-free code.
My library for example is not using the GC, but I don't put @nogc on every function because it does not make sense. Here is the link to the library: https://github.com/Kapendev/joka
The borrow checker is there as experimental, it is not an official part of the language. It is unfinished due to lack of interest in it by the D community.
I don't understand the special purpose behind Zig's allocators. It's just an interface. I make custom allocators in D all the time, it's trivial.
Dip1000 is also an experimental feature and is not part of the core language.
On a more pragmatic note, D has a notion of "sinks", aka output ranges. They provide a simple interface that accepts input, which is appended to the output range. Since the user of the sink has no idea what the sink is doing, just that it accepts input. This is a fun and very practical way to move the choice of how to allocate memory to the caller rather than the callee.
gdc and ldc offer top notch D support for the Mac.
> gdc and ldc offer top notch D support for the Mac.
Have you tried using D on Mac? That's almost impossible to do!! You get a segmentation fault immediately when using VS Code because it wants to download its own DCD and that's apparently compiled with DMD?? Everything that gets downloaded in binary doesn't work on MacOS. I only managed to get it working on emacs after building DCD locally with LDC AND making sure emacs does not try to use anything else. But even then, as I said, serve-d barely works (not sure if that's MacOS-specific). D has the worst MacOS experience of several dozen languages I've tried. Even FORTH just works, but D just does not.
I think it would be helpful to make it clearer what's experimental and what's not. Is the `in` keyword experimental? How about `scope`?
There's just a minor note in the docs (https://dlang.org/spec/attribute.html#scope) saying "The -preview=dip1000 switch must also be enabled.". That's really not making it clear if that's an experimental feature, it sounds to me that using the preview flag just does additional checks, but that implies `scope` is NOT experimental?! Which is it?
But it's difficult to do so! Nothing to do with marketing in my case, at least. The reasons are :
* `dub` is badly documented and does dumb things like including test code in the generated binary.
* `serve-d` is terrible. It can't handle even my little hello world programs - either crashes or consumes 100% CPU until I manually kill it.
* MacOS support sucks. All the time I have problems: the linker didn't work for years (fixed now). Immediate segmentation faults currently (fixed in nightly AFAIK). C code using the new flat128 doesn't compile (I think it was fixed already?). Just constant frustration.
* Too many features, many broken. It has an experimental borrow-checking feature, I tried to use it but it's largely undocumented. People in the Forum told me to that feature is completely unfinished. It has an allocators package as well, but no idea how I can make use of those like I would in Zig. Would love to see a well written post about that.
Using D in betterC mode is what I am most interested about exactly because it looks more like Zig and C than Java - and performs much better. But currently, that means forgetting about Phobos, the standard library, as that's written exclusively with GC and Exceptions in mind. Maybe that's ok as you can just use all C libraries you want, but would be nice to have some D conveniences to make that worthwhile.
Apart from that, I completely agree that D's comptime and metaprogramming is the best I've seen in any language (except for Lisp of course). All I need to keep using D is much better tooling and clarification about what parts of the language are "half-baked" (especially around DIP1000) and which parts are stable - perhaps "editions" will give us that, will check it out when it's ready. Oh and also top-notch MacOS support... I know that's a moving target but even Zig manages to handle that just fine, why not D?!