On Friday, 14 November 2014 at 14:59:39 UTC, Araq wrote:
I think it make sense to have something for ownership. The
error of rust wasn't going that road, but going in that road
100%, which come at a cost at interface level which is too
important. A simpler ownership system, that fallback on the GC
or unsafe feature when it fall short.
I'm confident at this point that we can get most of the
benefit of an ownership system with something way simpler than
rust's system if you accept to not cover 100% of the scenarios.
Do you happen to have any concrete reasons for that? An example
maybe? Maybe start with explaining how in detail Rust's system
is
too complex? I'm sure the Rust people will be interested in how
you can simplify a (most likely sound) type system that took
years to come up with and refine.
I'm not sure we understand rust type system to be too complicated
the same way.
Let's be clear: There is no accidental complexity in Rust's type
system. It is sound and very powerful. There is no way I can
think of you could make it simpler.
That being said, there are cases where Rust's type system shine,
for instance tree like datastructures with same lifetime, passing
down immutable objects to pure functions and so on.
But there are also cases when it become truly infamous like a
digraph of object with disparate lifetime.
Rust made the choice to have this safe memory management that do
not rely on the GC, so they have to handle the infamous cases.
This require a rich and complex type system.
My point is that we can support the nice cases with something
much simpler, while delegating the infamous ones to the GC or
unsafe constructs. The good news is that the nice cases are more
common that the hard ones (or Rust would be absolutely unusable)
so we can reap most of the benefices of a rust like approach
while introducing much less complexity in the language.
From a cost benefice perspective, this seems like the right way
forward to me.
To quote the guy from the PL for video games video serie, a 85%
solution often is preferable.
