More radical ideas about gc and reference counting

[Walter Bright via Digitalmars-d]

On 5/11/2014 1:59 PM, Timon Gehr wrote:
> On 05/11/2014 10:05 PM, Walter Bright wrote:
>> That's clearly an additional benefit of the borrowed pointer notion. But
>> have you examined generated Rust code for the cost of inc/dec? I
>> haven't, but I don't see any way they could avoid this (very expensive)
>> cost without borrowed pointers.
> Sure, but performance is the additional benefit.

One constant theme in this thread, one I find baffling, is the regular dismissal 
of the performance implications of inc/dec. Borrowed pointers are not necessary 
to support raw pointers - this can be (and is in some systems) supported by 
simply wrapping the raw pointer with a dummy reference count.

The reason for borrowed pointers is performance. Rust would be non-viable 
without them.

I strongly suggest writing a snippet in [[insert your favorite proven technology 
RC language here]] and disassembling the result, and have a look at what inc/dec 
entails.


>> The thing is, if the compiler is capable of figuring out these lifetimes
>> by examining the code,
>
> There are explicit lifetime annotations in function signatures.

Yes, because the compiler cannot figure it out itself, so the programmer has to 
annotate.


> It is simply not true that type systems are inherently restricted to checking
> trivial properties. They can be made as strong as mathematical logic without
> much fuss.

Again, Rust would not need borrowed pointers nor the annotations for them if 
this knowledge could be deduced by the compiler. Heck, if the compiler can 
deduce lifetimes accurately, you can get rid of GC and RC, and just have the 
compiler insert malloc/free in the right spots.

Note that there is a Java version that does this partway, sometimes it will 
replace a GC object with a stack allocated one if it is successful in deducing 
that the object lifetime does not exceed the lifetime of the function.


>> Yes, one is & and the other is @.
>
> No, actually currently one is & and the other is RC<T> AFAIK.

Then Rust changed again. The document I read on borrowed pointers was likely out 
of date, though it had no date on it.


> RC<T> is not more general. It cannot refer to stack-allocated data, for instance.

So there is no general pointer type that has an unbounded lifetime?


> Sure, borrowing is very lightweight, but ultimately what is most important is
> that it solves the problem of multiple incompatible pointer types and makes the
> type system more expressive as well.

Adding more pointer types makes a type system more expressive, by definition.


> A function that uses none of the specific pointer capabilities is more general,
> so what other choice of 'default' makes sense?

A function that doesn't have restrictions on what can be done with the pointers 
passed to it. Borrowed pointers have restrictions on their usage - this is 
explicitly stated in the Rust documentation.


> Convenience and reusable functions means using borrowed pointers whenever possible.

Of course. And writing fast code means making your functions fast whenever possible!


>> It seems clear that the decisions of borrow/managed are going to pervade
>> Rust code.
>
> But they are often obvious.

I've written a lot of ref counted code in the past, enough to know that such is 
a pretty optimistic statement. Dealing with was a significant and ongoing drain 
on my time, especially when the programs and data structures got more complex.


> They are using Rust to write a safe and performant web browser while developing
> the language.

Sure. But that browser hasn't been released yet. Consider that I've written safe 
and performant code in D, but others tell me I am unique and that I cannot 
expect average programmers to get it right.

I repeatedly point out to Manu that he can write performant code in D that does 
not suffer from GC stalls, and he repeatedly replies that he has to work with 
average programmers who are not capable of doing this.

So while I have no doubt that the Mozilla team may be very effective at using 
Rust and making it shine, that may not be transferable to the larger community.


> Borrowed pointers are not even superficially similar to near*. They are
> compatible with everything else, because they can store data that was borrowed
> from anywhere else.

As long as those pointers don't escape. Am I right in that one cannot store a 
borrowed pointer into a global data structure? The similarity is that there are 
one way conversions from one to the other, and one of the types is more general. 
I infer from your other statements about Rust that it doesn't actually have a 
general pointer type.