Yes, but at this point the critical piece that made no-GC memory safety possible - linear types - had already been researched and known in the FP community. Rust's critical invention was "what if we modeled heap ownership and borrowing with linear types".

Okay, strictly speaking, Rust types are affine, not linear. Leaking Rust values is a safe operation. In a linear Rust the compiler would have to prove all values do not leak, but this would be incredibly difficult and probably make reference counting illegal.

▲

mananaysiempre 18 hours ago | parent | next [-]

> Rust's critical invention was "what if we modeled heap ownership and borrowing with linear types".

Rust did not invent this (and I don’t believe Rust’s creators claim it did), see e.g. “Linear regions are all you need”[1] (ESOP 2006) and in general the work around Cyclone[2] in the 2000s. There was also Mezzo[3], which did very similar things but described them in a different style (effects instead of affine types), and a fair bit of work that went beyond what Rust can currently express (e.g. fractional capabilities). What Rust did is succeed at bringing a conservative subset of this academic work to production—which is not a small deal, mind you; others (including the Cyclone team) tried and failed.

[1] https://link.springer.com/chapter/10.1007/11693024_2, https://www.cs.cornell.edu/people/fluet/research/substruct-r...

[2] https://gallium.inria.fr/~fpottier/slides/fpottier-2007-05-l...

[3] https://protz.github.io/mezzo/

▲

Xirdus a day ago | parent | prev [-]

Yeah, this makes sense. Although all this affine type stuff was also the basis for the C++ move semantics (although the resulting type system isn't affine at all, the mental model is very much that, with deleted copy constructors and all), which predates Rust project by at least a few years. So by the time Rust 1.0 rolled out, it wasn't a new concept at all even in system programming circles.

The actually innovative thing about Rust is how they made object lifetimes into a H-M-esque type system and used this 50 year old algorithm to detect dangling pointers at compile time.

▲

steveklabnik a day ago | parent [-]

To further this, "destructive move" as C++ calls it almost happened, but ended up not. So it almost had it the same way as Rust too.

▲

kmeisthax a day ago | parent [-]

The funny thing is, Rust doesn't quite have a destructive move either. Or, at the very least, it's not exposed to the type system. The Drop trait that tells you if a value of a type T was destroyed can only give you a &mut T to it. There's no type to represent a value you own stored in memory you don't. So we have the funny situation where if you implement Drop, you can't take values out of the thing that got dropped.

	▲	Xirdus 14 hours ago \| parent [-]
		Destructive move is when the move skips destructor. Rust does have that. What it doesn't have is destructive destructuring - you can't skip the destructor when destructuring a struct. Meaning you can only destructure structs that don't impl Drop.