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?

On Thursday, 15 August 2019 at 19:53:59 UTC, IGotD- 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.

I don't think the GC will ever be removed. My understanding is that the option would be available for those that want the whole OB thing. I'd immediately move to another language if D wasn't a GC language.

> What do you think about refocusing the memory management efforts towards solid RC instead?

There have been many lengthy threads on this topic. To my knowledge, they have never arrived at a satisfactory solution, but I can't say I've followed every detail of the discussions.

On Thursday, 15 August 2019 at 20:34:03 UTC, bachmeier wrote:
>
> I don't think the GC will ever be removed. My understanding is that the option would be available for those that want the whole OB thing. I'd immediately move to another language if D wasn't a GC language.

Isn't there a risk that would fragment the language like C++ where there are 11 ways to do the same thing. The preferred way seems change every year or so.

Also wouldn't it lead to incompatibility issues when it comes libraries?

On Thursday, 15 August 2019 at 19:53:59 UTC, IGotD- 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.

Yes. And no.

Java only has primitives as value types, and you can't take their address. Everything else is on the heap (not necessarily in practice, but conceptually, yes), so the GC is enough for safety. D has structs, pointers, global variables: lots of ways to screw up that the GC can't help with. That's where DIP1000 et al come in.

I agree that D should be easier to use than Rust (it already is), and that the GC should be the default way of handling memory. We don't have any plans to change that. But, right now, it's possible to corrupt memory in D without the compiler telling you, and that's not a thing we want.

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

On 16.08.19 11:34, Atila Neves wrote:
> But, right now, it's possible to corrupt memory in D without the compiler telling you,

It's important to note that the reason why this happens is that there is @trusted code that doesn't account for all ways @safe code can access its interface. I.e., it's bad @trusted code, and inexpressive type system, not unsound type system. The only ways to fix this are

1) add more runtime checking to @trusted code and don't directly expose mutable references where this is problematic.
2) give more type system tools to @trusted code to restrict how @safe code may access its interface, so exposing mutable references directly is valid in more circumstances.

> and that's not a thing we want.

None of the borrow/ownership proposals in the pipeline do anything that would allow @trusted code to restrict the set of possible access patterns from @safe code. They are a form of Rust cargo cult.

On Saturday, 17 August 2019 at 12:09:19 UTC, Timon Gehr wrote:
> 
> [...]
>
> None of the borrow/ownership proposals in the pipeline do anything that would allow @trusted code to restrict the set of possible access patterns from @safe code. They are a form of Rust cargo cult.

As someone who likes Rust, I like the idea of having just one mutable reference to a strict. I'm no language designer but it makes sense to try to borrow a model that already works in another language. I do think that Rust has a lot more than just one mutable reference that contributes to the safety and maybe it does not makes sense for D to do that.

The problem is that I can't think any way besides returning a refcounted pointer in opIndex to make a safe Vector that has a reserve method or a insert that reallocate.

If you have a better way that does not involve copying Rust I think you could let us know.

On 17.08.19 14:36, victoroak wrote:
> On Saturday, 17 August 2019 at 12:09:19 UTC, Timon Gehr wrote:
>>
>> [...]
>>
>> None of the borrow/ownership proposals in the pipeline do anything that would allow @trusted code to restrict the set of possible access patterns from @safe code. They are a form of Rust cargo cult.
> 
> As someone who likes Rust,

Rust is a fine language.

> I like the idea of having just one mutable reference to a strict. I'm no language designer but it makes sense to try to borrow a model that already works in another language.

Not without understanding what it does and why it works, and what features it may not be (easily) compatible with.

https://en.wikipedia.org/wiki/Cargo_cult

E.g., this "plane" will not fly:
http://erwin.bernhardt.net.nz/oceania/images/vanuatutannacargocult02.jpg

It superficially looks like a plane, but it does not actually have the same function.

> I do think that Rust has a lot more than just one mutable reference that contributes to the safety and maybe it does not makes sense for D to do that.
> ...

If any of the proposals would in fact guarantee that at any time there was either one mutable access path or an arbitrary amount of non-mutable access paths to each value, I wouldn't call them a cargo cult. But that still wouldn't necessarily make sense, because @safe D code can access raw pointers, while safe Rust code can't. (This is because D has a built-in garbage collector. In Rust, GC is not entirely trivial to make safe, useful and efficient at the same time, and they haven't settled on a solution.)

> The problem is that I can't think any way besides returning a refcounted pointer in opIndex to make a safe Vector that has a reserve method or a insert that reallocate.
> ...

As I said, there is no actual proposal in the pipeline that allows making a safe vector of the kind that Rust has, even though there are proposals that superficially make the D type system look more similar to Rust's to a casual observer. I keep pointing it out but so far this has not been acknowledged as a fatal flaw of those proposals.

> If you have a better way that does not involve copying Rust

(To get a _copy_ of Rust, download rustc. Anything else requires some language design expertise.)

I don't understand why you think I think using Rust for inspiration is a bad thing. I'm not opposed to doing what Rust does. Rust _actually does some version of what I suggested in my last post_. The problem is that it seems that very few people actively participating on this forum actually understand what it is that Rust does. (E.g., a very common misconception is that Rust unsafe is like D @system. Rust unsafe is actually like D @trusted. Another misconception is that Rust ensures that raw mutable pointers don't alias.)

> I think you could let us know.
We first need to agree on what the actual problem is before discussing solutions. And once we do, I don't care whether we (actually!) do what Rust does or whether we instead settle for fractional permissions implemented in a super-general dependently-typed typestate system. The only thing that's important to me is that the solution works and doesn't have obvious design flaws. There are existing proposals being considered that fail those criteria, and that just shouldn't happen. Pointing that out is a meaningful contribution, but it takes away some of my spare time from more useful contributions such as participating in a working group that designs solutions that actually work. However, such more useful endeavors can't be fruitful (and I'm not betting my precious spare time on them) unless decision makers actually acquire _some_ expertise on this subject matter.

On Sat, 2019-08-17 at 22:42 +0200, Timon Gehr via Digitalmars-d wrote:
> On 17.08.19 14:36, victoroak wrote:
> > On Saturday, 17 August 2019 at 12:09:19 UTC, Timon Gehr wrote:
> > > [...]
> > > 
> > > None of the borrow/ownership proposals in the pipeline do anything that would allow @trusted code to restrict the set of possible access patterns from @safe code. They are a form of Rust cargo cult.
> > 
> > As someone who likes Rust,
> 
> Rust is a fine language.

I spend most of my programming time using Rust. As with any other programming language it has its pluses and minuses, but overall I like it. But you do have to admit that Rust programming is a Cargo cult: https://doc.rust-lang.org/cargo/

Just as many would have D programming be a Dub cult: https://en.wikipedia.org/wiki/Dub_music oh sorry, of course I meant: https://dub.pm/getting_started

:-)

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

On Saturday, 17 August 2019 at 20:42:46 UTC, Timon Gehr wrote:
>
> I don't understand why you think I think using Rust for inspiration is a bad thing. I'm not opposed to doing what Rust does. Rust _actually does some version of what I suggested in my last post_. The problem is that it seems that very few people actively participating on this forum actually understand what it is that Rust does. (E.g., a very common misconception is that Rust unsafe is like D @system. Rust unsafe is actually like D @trusted. Another misconception is that Rust ensures that raw mutable pointers don't alias.)
>

Rust do have unsafe functions that can only be called inside unsafe blocks so it's like @system functions in D. But I agree with what you are saying, we need a better understanding on the subject before trying to push it into D. Sorry for misunderstanding what you said before.