What ever happened to move semantics?

Don Allen donaldcallen at gmail.com
Wed Feb 28 22:01:39 UTC 2024


As I've said in previous posts, I've written a lot of Rust and 
now a fair amount of D. I prefer D as it is, now that I've solved 
some issues with my own lack of knowledge about the available 
tools.

I want to make a comment about all this chatter about move 
semantics. I freely admit that I have not read the proposal for 
doing this, if there is a fully-fleshed-out proposal, and I 
probably never will.

My issue is this: Rust has led the move semantics charge. 
Grafting move semantics onto feels to me like me-too-ism and just 
cluttering the D environment with yet another wart that it does 
not need. Move semantics in Rust results in the programmer 
becoming an key part of the memory management system, whether 
they realize it or not. Anyone who has wrestled with the borrow 
checker or gotten themselves into lifetime hell with Rust will 
understand (unless they've drunk the Kool-Aid) what I am talking 
about. Rust is a fiendishly difficult language to learn. I've 
been doing this for a very long time and have written code in 
languages most of you have never heard of. None of them were as 
hard to learn as Rust and I include Haskell, which I know well.

And what's the reward for all this diffculty? No GC. The Rust 
community's allergy to garbage collection is totally overblown, 
in my opinion. Yes, garbage collected languages are not good 
choices for embedded and/or real-time code. But ordinary 
applications? On today's multi-Ghz 32 Gb hardware? And the cost 
of avoiding garbage collection is great. You need to hear the 
observations of more people like me who know both Rust and D and 
I think the tune will be much the same -- D is much easier to 
learn and easier to use. The resulting code? D code runs fast, in 
my experience it is as fast as Rust, within a very acceptable 
tolerance. And benchmarks I've seen online confirm this. Why is 
an uninteresting language like Go so much more popular than Rust? 
It's easy to learn, gives acceptable performance, and has a rich 
environment.

So before cluttering the D environment with an unneeded me-too 
effort (my opinion!) and wasting scarce developer resources on 
this when there is so much else to be done that D needs more than 
a borrow-checker, I urge you to think very carefully about this.


More information about the Digitalmars-d mailing list