Is borrow checker the right thing for D?

[Russel Winder]

On Thu, 2019-08-15 at 19:53 +0000, IGotD- via Digitalmars-d wrote:
> 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.

Or maybe they switched to using reference counted objects because trying to
use stack based objects was the wrong way of doing what they were trying to
do. I had this problem a year or so ago with part of Me TV in Rust. The
problem was not the borrow checker, the problem was I should have been using
heap objects not stack object for the things the borrow checker was
complaining about.

For managing stack objects, the borrow checker is a huge boon.

> 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.

Aren't the borrow checker and reference counting two separate domains of
memory management? The Rust borrow checker is about stack management,
reference counting is about heap management.

Reference counting works well in Python, garbage collection works well in Go.
I find garbage collection works well in D, why is reference counting needed.
Rust of course uses reference counting (or atomic reference counting).
Reference counting is a runtime activity, is it even feasible to do it at
compile time?

> 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?

Rust chose reference counting for a reason. Go chose garbage collection for a
reason. Java chose garbage collection for a reason. D having garbage
collection seems fine – except that the GC of D seems highly unsophisticated
compared to those of Go and Java, but I am told that this is of necessity.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20190816/589a95d2/attachment.sig>