Nim's ORC - Vorsprung durch Algorithmen

[Max Haughton]

On Tuesday, 2 February 2021 at 07:25:21 UTC, Petar Kirov 
[ZombineDev] wrote:
> 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

I would like to get a group going to hash out the future of these 
ideas in D.

The connection with affine and linear type systems is definitely 
the lense to look through rather than merely memory. 1021 is a 
step in the right direction practically in that in catches bugs 
but we have to dream bigger.

For a simple example of somewhere where advanced (substructural) 
type semantics buy you nice things other than memory: @nodiscard 
is effectively a linear type in disguise.

Attacking from both sides is a good idea - we can make GC code 
faster and nogc code safer using the same weaponry.

HOWEVER - all of these changes effectively mean bolting even more 
flow analysis to the compiler which isn't great given the current 
coding styles in dmd (It's very "flat" i.e. not much abstraction, 
and there is a tendency to dump everything in one 10k line file) 
- this is an easily solvable problem, we just need to be more 
forward thinking.