Is borrow checker the right thing for D?
IGotD-
nise at nise.com
Thu Aug 15 19:53:59 UTC 2019
This is regarding the blog post
https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/
and the associated DIPs.
What I'm worried about here is how this change would change the
aesthetics and usability of D. Right now it is Java like, the
garbage collector takes care of the memory and you can focus on
being productive. Rust is a fad right now with its borrow checker
memory model, but I think it is a fad because it is too limiting.
The irony of the Rust model is that I often see people revert to
reference counted objects when they cannot satisfy the borrow
checker. Satisfying the borrow checker often makes you rethink
the algorithm and sometimes that isn't even possible.
However, if the borrow checker is a step towards transparent and
solid reference counting, then it would be a good thing. Why
isn't reference counting considered as the automatic memory
management in D? It is easy to understand, it fits with nearly
all existing algorithms, it fits well with multi threading, it
has no GC stalls. I would rather use the static analysis for the
reference counting, for example optimizing away unnecessary
increase/decreases of the RC.
There is a reason I use D and not Rust and that is that D is not
Rust. I rather have the more pragmatic Java way of doing memory
management. When I want to think about it, I'll just use manual
memory management.
What do you think about refocusing the memory management efforts
towards solid RC instead?
More information about the Digitalmars-d
mailing list