Nim's ORC - Vorsprung durch Algorithmen

[Petar]

On Monday, 1 February 2021 at 17:43:25 UTC, H. S. Teoh wrote:
> On Mon, Feb 01, 2021 at 05:30:30PM +0000, IGotD- via 
> Digitalmars-d wrote: [...]
>> Also, regarding DIP1000 and DIP1021 is going nowhere. I 
>> haven't seen any plan what this would in the end produce and 
>> therefore it is just an unplanned attempt and has nothing to 
>> do with improving the GC.
>
> DIP1000 has nothing to do with the (current) GC.  It is to 
> prepare the ground for implementing some kind of ARC scheme.
>
>
> T

Yes, those DIPs have nothing to do with D's current GC, but ARC, 
ORC, ..., and tracing are just different forms of garbage 
collection (all with different trade offs). As explained by the 
Nim article, their compiler is taking advantage of move 
semantics, escape and other forms of static analysis (basically 
what DIP1000 and DIP1021 are about) to optimize the load on the 
"GC". Go's compiler uses escape analysis to determine when heap 
allocations can be demoted to stack allocations (LDC also have a 
GC2Stack optimization pass, but it's a shame that it's not part 
of the front-end proper).

I wish we as a community would stop with this nonsensical split 
between the "GC" and the "no GC crowd", us versus them, etc. It's 
just different sides of the same coin. As soon as we realize that 
using the GC is not a binary choice but a spectrum of options 
each good for different use cases the better.

#dip1021 (which doesn't even mention "@live" btw) is step in the 
wrong direction IMO. It is a kind of cargo cult version of a 
Rust's move and ownership semantics. Even if Rust was not the 
first language to implement this, it is certainly the language 
which immensely popularized affine types [1]. I think the main 
innovation of Rust's community is the realization that affine 
types are not just about memory management but are about adding a 
level of expressivity to the language that can't be easily 
emulated otherwise and that can be applied to different classes 
of problems [2] [3] [4]. #dip1021 doesn't support safe use of 
both of owned and non-owned/GC memory (or "managed" and 
"unmanaged" pointers) in the same function (since in D there's no 
distinction). But what is worse is that #dip1021 doesn't support 
typestate pattern in @safe code.
IMO affine-like types should distinct types available in @system 
and @safe code alike, not just in some temporal anomaly that is 
@live.

[1]: 
https://gankra.github.io/blah/linear-rust/#adding-proper-must-use-types-to-rust
[2]: http://cliffle.com/blog/rust-typestate/
[3]: https://rust-unofficial.github.io/patterns/intro.html
[4]: https://munksgaard.me/papers/laumann-munksgaard-larsen.pdf