Has the whole 2-library thing been fixed? Years ago when I got into it, it got really confusing and unsexy.
If you're talking about the whole Tango/Phobos (2 std libs) thing, it's fixed and Phobos won. But now there are optional function attributes such as @nogc (checks that the code doesn't trigger the GC), @safe (memory safety checks) and nothrow that's causing a bit of a problem.
For example, not all libraries are @nogc. So if you want to use some library in your @nogc code and the library is not marked as @nogc, you can't use that library. This is not as bad as the two standard libraries problem but it restricts the libraries you can use.
The attributes are optional like I said, you can just ignore them and write code that uses the GC (not @nogc), code that is not explicitly checked by compiler for memory safety (not @safe) and code that throws exceptions (not nothrow).
Of course this is sort of expected in multi-paradigm languages, like some people disable C++ exceptions. But in D's case it feels like the compiler and library developers' efforts are spread thin.
Write the code first then measure it.
Sort of undecided on the exceptions though. The Result / Option type in Rust is pretty nice to use (and !?*T in Zig, which is nicer if you ask me). It forces you to handle exceptions explicitly which is pretty nice and you can be sure there is no overhead introduced by the compiler for handling exception stuff.
I'd probably wrap all the exception throwing functions in my D codebases with Result type if we had language level support for sum types and match syntax. I know we have it in the standard library, I want it in the language with nicer syntax.
I also want the GC to be replaced with deterministic destruction using RC + ownership analysis and optimizations like Lobster does, but that's wishful thinking territory.
D doesn't return values when an exception is thrown as far as I know. How are exceptions' costs are paid by tricky implementation?
I thought exceptions require allocation and run-time type info and therefore always introduce some cost (this goes for D and C++). I guess returning values and allocating error strings statically can help with that (or maybe allocate some exception buffer on program start -- but that's technically "overhead"). Am I wrong, or missing some important context related to exceptions?
Lots of people do statically allocate their errors now.
Implementing stack unwinding properly is not trivial.
That said though, yeah, I don't think any of them use `@nogc`. I've actually tried to get the gc to interrupt audio code before and couldn't even hear it. I'm sure a bigger heap to scan might cause a problem in some situations, but these fears are really overblown in the popular commentariat.
Will definitely revisit when things settle.
Beyond that D is a good language for writing software in. all language communities have fractures unless the language attracts lots of either new or bad programmers who haven't formed opinions yet