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