For some time I’ve been looking around for a new goto language as I’ve been unhappy with the direction Java is heading, I did have a good play with C (C++ I just discounted because of its ascii soup) but the lack of some kind of decent memory management can lead to very obscure and difficult to track down bugs. Go was another contender as its expressive and has robust (and clever) memory management, alas however there isn’t a great ecosystem, which leads you to want to wrap C libraries and Go’s FFI isn’t without penalty.
In marked contrast is D which is memory managed in a very flexible manner, and will only collect on allocation and only if needed, imagine a scenario where you happily rely on the GC while loading your resources and have a system of object pooling, the pooling minimises the need for the GC and the GC is there just in case you missed something…. fast and robust…
Even better is the fact C libraries are a first class citizen, you can directly link and call them without need for a FFI, there is some light wrapping needed sometimes, but by and large many C libraries can just directly be used without issue, indeed you can code in D almost as if you are writing C code, and this hints at one of the nice features of D, like C it appears to be a stable platform! This is not to say that there isn’t a wide range of language paradigms to choose from, but crucially D doesn’t force you into using any particular one. So unlike Go’s crippled object oriented idea and the redonkulous memory management in Rust you are not forced to program in any particular way.
Frankly D’s approach is great a real breath of fresh air, I do not think that it is a compilers job to strong arm a programmer into someone elses view of what good practice is, its up to every programmer to cultivate good habits but crucially also be able to know when to break the rules and why – something compilers ain’t so good at.
Initially I tested out a GLFW3 and OpenGL wrapper, and if truth be known I’ve only coded in a very C like manner, which has lead to some initial observations, import can be embedded in a function, this means only that function has access to the module, coupled with selective importing (you can very simply cherry pick which functionality you want to import) and you can have a very unpolluted namespace.
The compiler seem sensibly strict (I generally have warnings as error in both C and Java) and you do need to actually read what the error message says! for example I’d missed “nothrow” off a callback function and spent too long fiddling with parameters till I noticed that the error message was showing me that the function needed nothrow ….
The “standard” library looks extensive some of the stuff seems a little spread around but it terms of reducing boilerplate it really is worth looking through the standard libraries before you embark on implementing some basic algorithm yourself. The ecosystem connected to “dub” the build system that comes with the reference implementation of the D compiler, seems quite extensive and even included the sweet trinity of OpenGL, GLFW3 and OpenDE so that’s me happy for a while!
I’ve been reading up on D’s handling of Object Oriented programming and it’s no surprise like much else in the D world it looks both pragmatic and flexible. While I only really need light OO features, a GC and a good C interface, I can’t wait to dig into some of the more advanced features of the language, all in all I’m kicking myself for not properly investigating D years ago!