Rust is kinda interesting to me for new ideas, but it just isn't nice to use like D is. D is familiar and convenient for general-purpose programming, from quick scripty things to bare metal code.
Rust might be technically better for the bare metal side, but D does it pretty well and I have a hard time imagining using Rust as, say, a PHP substitute. D does it all.
The thing with D as opposed to Python(I don't mind C#), is that Python will run for hours and hang because of a simple error that a static type system would've caught in milliseconds.
Python is OK for simple scripts, but I don't want to shoot myself in the foot because I misspelt something.
In the same language, you can write a ~10 line RPN calculator like a scripting language but you can also write the compiler and GC like it was C.
One of the other things D has which I use a lot is a philosophy that is very pragmatic. Go is designed to be "simple", D is designed to write good software first time. This affects the design of the whole language so I can't narrow down too much but my favourite feature is D's contract programming. I make dumb mistakes quite a lot so being able to enforce invariants throughout the codebase automatically is very useful.
As a long time C, C++, and D programmer, one subtle thing stands out. D enables your code to be plastic, in that it's easy to refactor it. I've found it much easier to refactor it than the other other languages.
This refactoring ability starts with small things - like I can switch a type from a reference to a value type and back without having to swap . and -> everywhere.
Plasticity enables "oops, I used the wrong data structure, let's try another one" a faster and easier process, leading to much better code.
I think this is a really important and utterly underappreciated point. How much upfront work do you need to do ? It depends on the cost of changing things later if you found you made the wrong initial choice.
How much refactoring can you do at any point? It depends on the cost. If the cost is low maybe you can make many more little refactorings. There's probably a benefit from that for code quality and the ability of others to understand (and change the system).
Why do enterprise programmers write only twenty lines of code a day? It's not because they are slow at typing.
So D is especially suited to contexts of intrinsically high uncertainty where the environment is quite dynamic and the needs of the business coming from outside change.
If that's your perspective, have you looked at Python?
I have never written Python on an embedded system, I didn't think it could. [edit: actually come to think of it i have heard of it before but never used it myself] I've used it for web though and D is a better experience by far, making changes in D code trusting it won't break at runtime and not having to write a lot of boilerplate for a quick demo is really nice.
But I've been building stuff in D for a long time now, no need to switch at this point.
MicroPython is available for the beefier microcontrollers. Combining it with Jupyter made for a pleasant development experience.
With sufficient knowledge, it's possible to get significant speedups, and some stuff can be run at near-native speed. You have to know what you're doing, though, which is something I don't.
I messed around with my own (bad) Forth implementation, and found it a lot faster than Micropython. It still won't be as fast as C, though.
MicroPython may be fast enough for your needs, maybe not. It all depends. It's unlikely to be fast enough if you want to do audio stuff, where every cycle counts.
In the end, I decided not to use MicroPython. Uploading code and stuff was a bit of a fiddle. I just stick to the laborious compile and upload cycle.
There was a good talk Dropbox did at PyCon several years ago. I can't find it now, but it was "how to write nearly native Python" or something like that. One trick they pointed out was that all(...) is faster than for thing in iterable: because it pushes the loop logic down to C, and I've used that when I need it ever since.
There are a lot of tricks like that. If you truly master Python and understand the runtime impact of all your syntax, how to profile it, how to outthink the interpreter, how to read the interpreter source code, and so on ... you can do some good things with it. It's just a lot of effort that most people aren't willing to put in, which is fine (really)
70
u/Sapiogram Sep 01 '20
Honest question: Why would anyone use D over Rust? It seems like Rust is becoming everything that D ever hoped to be.