I love D.
I just wish it had more popular traction - it's much better to program in than Rust, Go or even C# as a language, but the community support is lacking.
I just wish it had more popular traction - it's much better to program in than Rust, Go or even C# as a language, but the community support is lacking.
I look up how to do X, find very few resources, more than half mention D1. Compare that with looking up X in Rust or Python, how many mention Python 2 or Rust before the editions.
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
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.
You can start your D usage with these examples: https://github.com/p0nce/DIID
I don't know the status of https://code.dlang.org/packages/libtcod-d
"Rust seems obstuse" doesn't mean anything. On the other hand, I personally think that Rust is not the most productive language, overall, for game development (I'm familiar with Rust gamedev). This consideration includes the hard truth that as of now, the game libraries are young and buggy.
In an theoretical world, where all the languages have stable and equally functional game libraries/engines, in my opinion, the most productive language is something with deterministic (manual) memory management, but less memory safety (=overhead) than Rust, but that is still safer than C-family languages. I can picture D fitting this characteristics, but also other modern languages. This does not apply to areas where where safety is paramount (e.g. networking).
When I say that Rust seems obtuse, I mean I've been bashing my head against its philosophy and syntax for some time without reaching the magic "hey this works and I'm suddenly productive" summit (or at least plateau).
I've come to the conclusion that it's not for me, but my interest in it stemmed from frustrations with Python and my memories of enjoying writing 'C' in the 90s. I find C++ a language without an underlying philosophy and seems like a horrid patchwork of things; Java is frustrating and verbose. C# is very Windows centric, which I'm not adverse to exactly, but I don't run it. Various other languages I've thought about and discarded.
I was toying with Go as that seems to have many fans, and seems to have wheels, but I'm cautious given some of the criticisms it comes under. D was not on my RADAR, but now I'm quite interested and probing its good and bad points. It looks promising on a casual look.
You're right, of course, "lots of developers who spend time inquiring and researching about game writing platforms (languages, libraries, engines) but end up writing nothing. "
Most people come from the point of view of they enjoy playing games, so they think they would enjoy writing them. Same with reading novels/writing them, and probably many other spheres of human creative endeavor.
I'm not saying I'm immune from this kind of thing, but my ideas are very modest, and if I fail to implement my game, no harm will come from it; the opposite in fact, as the very act of solving programming problems is as productive as solving a crossword puzzle, and will serve, if nothing else, to keep my mind sharp (as my current job requires no programming ability whatsoever).
I don't enjoy playing games, I'm tremendously bad at them and so don't get much positive re-inforcement on them as an enjoyable activity. But programming is fun, and that's what I'm looking for.
Anyways, the strong concurrency story in Go finally bought me over there though.
I still miss the super readable (almost python-like) syntax from D though.
Running functions alone is not that interesting, and neither really is generating code. You can do those (arguably better for some cases) with helper programs as a separate build step. But reflection is non-trivial to do externally, so that's the biggest value add, and using it with all three pieces let you close the loop.
But what I’ve mentioned is also very related to the ergonomics of compile-time metaprogramming, since these techniques are all useless if it severely increases builds times up to the point that developers have to use it sparingly. Only Nim and Jai has fully gone the route of using a bytecode VM for compile-time evaluation, while D had a similar project back in 2017 that was abandoned, and for other languages (C++, Zig, etc.) it’s still in the planning stage.
Unlike some D programmers I don't mind rust but compared to C and C++ the primary difference I'd say is that D has a lot of features that you'd have to emulate with either macros or recursive templates that means that the source files end up much cleaner.
If you want to declare a struct with N members where N is declared at compile time, in C++ it's usually a question of doing a bunch of compile time magic that leaves a roadside picnic of SFINAE everywhere whereas in D it's just a "static foreach" loop inside a template.