On 15.11.20 15:11, donallen wrote:
> 
> I don't know exactly how Walter intends to proceed with adding Rust-like move semantics to D, but the little I know suggests that it will be optional. If I'm right, that's very wise. Move semantics and no GC for those who really need it (justifying its cost) and the luxury of the GC for those who don't.

And an unsound interface between the two so you can have your O/B and safety type checks and even get the luxury of some memory corruption anyway.

On Sunday, 15 November 2020 at 14:34:24 UTC, Timon Gehr wrote:
> On 15.11.20 15:11, donallen wrote:
>> 
>> I don't know exactly how Walter intends to proceed with adding Rust-like move semantics to D, but the little I know suggests that it will be optional. If I'm right, that's very wise. Move semantics and no GC for those who really need it (justifying its cost) and the luxury of the GC for those who don't.
>
> And an unsound interface between the two so you can have your O/B and safety type checks and even get the luxury of some memory corruption anyway.

Are you sceptical of introducing O/B principles into current D, or is it just about how it's being discussed/implemented?

On 16.11.20 21:17, M.M. wrote:
> On Sunday, 15 November 2020 at 14:34:24 UTC, Timon Gehr wrote:
>> On 15.11.20 15:11, donallen wrote:
>>>
>>> I don't know exactly how Walter intends to proceed with adding Rust-like move semantics to D, but the little I know suggests that it will be optional. If I'm right, that's very wise. Move semantics and no GC for those who really need it (justifying its cost) and the luxury of the GC for those who don't.
>>
>> And an unsound interface between the two so you can have your O/B and safety type checks and even get the luxury of some memory corruption anyway.
> 
> Are you sceptical of introducing O/B principles into current D, or is it just about how it's being discussed/implemented?

I'm all for it, it's just that the specific approach that has been put forward does not work (in addition to being less expressive than what Rust has). I have suggested alternatives, but no discussion arose from it.

Basically, you can't get useful O/B features that ensure memory safety using a function annotation, you'd need borrowed references and some library features. @live is a function annotation because it is easier to implement; it's not a sound thing to do. At the same time the messaging around @live has been contradictory, Walter on the one side essentially stated that it was just him messing around with new type checker features that may even turn out to be useful as linting hints to someone writing some @system code and on the other side it was already being advertised as bringing Rust-like safety features to D. However, as far as I can tell, there is still no coherent design that would allow for that. (Looking forward to Walter's keynote though.)

On Sunday, 15 November 2020 at 14:11:51 UTC, donallen wrote:
> I can't answer your questions, but I can offer some observations based on my experience porting a personal finance application, originally written in C, to Rust (about 10,000 lines of code).
[...]

Thank you for sharing your experience.

> Rust does what they say it will do -- deliver memory-safety without a garbage collector. But the incremental price you, the programmer, must pay for the absence of a GC is significant.

A really critical point which is often omitted describing Rust's
"memory-safety without a garbage collector" is that you can't
use reference cycles in your data.
(https://medium.com/hackernoon/why-im-dropping-rust-fd1c32986c88)
And according to my (limited) academic knowledge, complete
compile time automatic memory management isn't simply possible.
(You have to use hacks like weak refs and other not fancy staff).

> If you are about to write something that requires absolutely predictable latency, where you would normally reach for something like C or C++, then Rust is probably a better choice

I haven't actually used (and seen) the Rust lang in embedded systems,
but I read a comment from a guy whose complains I think may be correct.
The Rust O/B system results in more usage of heap allocations.
(or even requires it due to borrow checker's limitations).
And in general, heap allocations can cause too high unpredictable delays
(this is also very often ignored).

> I don't know exactly how Walter intends to proceed with adding Rust-like move semantics to D, but the little I know suggests that it will be optional. If I'm right, that's very wise. Move semantics and no GC for those who really need it (justifying its cost) and the luxury of the GC for those who don't.

I hope D will be still getting simpler (not less complex - meaning
less powerful).

Making good API (which boosts developers productivity) is so incredibly
difficult that I appreciate more and more D developers' contributions
to those all great libraries.

Cheers,
Piotrek

On Monday, 16 November 2020 at 22:39:14 UTC, Piotrek wrote:
> And according to my (limited) academic knowledge, complete
> compile time automatic memory management isn't simply possible.
> (You have to use hacks like weak refs and other not fancy staff).

In the general case no, because then the compiler would have to predict all relevant execution patterns.

If you can deduce/impose an invariant order then it could, in theory.

On Monday, 16 November 2020 at 22:39:14 UTC, Piotrek wrote:
>
> And according to my (limited) academic knowledge, complete
> compile time automatic memory management isn't simply possible.
> (You have to use hacks like weak refs and other not fancy staff).

Correct and Rust itself is a proof of that. Rust has to often rely on reference counting where the compiler cannot determine the lifetime, typically when multiple ownership is required. Furthermore, the compiler cannot even always determine the borrow checker at compile time and programmer must use RefCell. RefCell basically inserts runtime checks that the compiler would otherwise be capable to infer at compile time. Rust try to market itself as a silver bullet for lifetimes and how safe it is but the reality is different.

Rust started something interesting but I think that the Rust object lifetime model will be unique for Rust only. Pieces of the knowledge will be used in future compilers.

On Tuesday, 17 November 2020 at 10:54:20 UTC, IGotD- wrote:
> On Monday, 16 November 2020 at 22:39:14 UTC, Piotrek wrote:
>>
>> And according to my (limited) academic knowledge, complete
>> compile time automatic memory management isn't simply possible.
>> (You have to use hacks like weak refs and other not fancy staff).
>
> Correct and Rust itself is a proof of that.

Rust is not proof of that. However, it is often difficult to prove properties of a graph that is transformed.

On Tuesday, 17 November 2020 at 10:54:20 UTC, IGotD- wrote:
> On Monday, 16 November 2020 at 22:39:14 UTC, Piotrek wrote:
>>
>> And according to my (limited) academic knowledge, complete
>> compile time automatic memory management isn't simply possible.
>> (You have to use hacks like weak refs and other not fancy staff).
>
> Correct and Rust itself is a proof of that. Rust has to often rely on reference counting where the compiler cannot determine the lifetime, typically when multiple ownership is required. Furthermore, the compiler cannot even always determine the borrow checker at compile time and programmer must use RefCell. RefCell basically inserts runtime checks that the compiler would otherwise be capable to infer at compile time. Rust try to market itself as a silver bullet for lifetimes and how safe it is but the reality is different.
>
> Rust started something interesting but I think that the Rust object lifetime model will be unique for Rust only. Pieces of the knowledge will be used in future compilers.

Rust got the ball rolling for the ideas prototyped in Cyclone and Linear Lisp.

Even if the language dies tomorrow, it has already made a mark on Swift, D, Chapel, ParaSail, C++, Haskell, Idris(2), F*, Dafny and probably others.

This is where I see the evolution of systems languages, some form of GC (yes it includes RC as algorithm) alongside some kind of support for linear/affine types for those critical code sections.

It doesn't need to be perfect, just good enough.

> Even if the language dies tomorrow, it has already made a mark on Swift, D, Chapel, ParaSail, C++, Haskell, Idris(2), F*, Dafny and probably others.
>

I'd be very interested in knowing where you think Rust has influenced Haskell. There is certainly a lot of influence in the other direction, e.g., Haskell classes -> Rust traits.

On Tuesday, 17 November 2020 at 11:34:01 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 17 November 2020 at 10:54:20 UTC, IGotD- wrote:
>> On Monday, 16 November 2020 at 22:39:14 UTC, Piotrek wrote:
>>>
>>> And according to my (limited) academic knowledge, complete
>>> compile time automatic memory management isn't simply possible.
>>> (You have to use hacks like weak refs and other not fancy staff).
>>
>> Correct and Rust itself is a proof of that.
>
> Rust is not proof of that. However, it is often difficult to prove properties of a graph that is transformed.

Rice's theorem means you can't just let the compiler do it for you, however rust doesn't do that. What Rust shows us that a conservative approach (i.e. annotations from the programmer and the exact rules the borrow checker allows) is more than enough to guarantee safety and manage memory productively.

D is already going in the right direction, the only issue really is that (as they are now) pointers are insufficiently expressive to be both safe and (say) act like C++ smart pointers and work with their de/allocators automatically. Ideally we would use structs but Rusts move by default semantics are an advantage we don't have.