[adgjlsfhk1]

People have. In my opinion, it's a bad idea. I think that to appreciate Rust's design, you pretty much have to be familiar with the awfulness of memory leaks in C/C++ (and it helps if you have experience trying to make a program in a GCed language hit strict latency requirements). I think Rust's design is genius, but I think the first language you learn should be an easy language with a GC (there's enough hard parts of learning your first PL). The next step is to learn C (because it's beautiful but fatally flawed), and only after you have learned why manual allocs and frees suck, should you learn Rust.

[zozbot234]

The easiest way to conceptualize Rust's design at a basic level (suitable for first-time learners) is probably as a glorified functional language, where you initially pass everything by value (courtesy of .clone()) aside from shared immutable data (passed via shared references). Mutable borrowing can then be introduced next, followed by the "cell" patterns/constructs for shared mutable state. Not altogether trivial, but it seems like it could work. And the compiler would protect against many errors along the way, that bite C/C++ coders.

[pornel]

Rust is strict about ownership, which doesn't have equivalent in other popular languages. Users coming from GC languages are surprised Rust can't make things "live long enough". Users coming from OOP languages are surprised that Rust has on-stack objects without a layer of indirection. Users coming from C are surprised that references aren't like pointers.

So I think it would be interesting to teach users Rust's point of view first, before they learn the "misconceptions" from other languages.

But in practice something like JS is better, because students can make something engaging appear on screen before they lose patience.

[zozbot234]

> Users coming from GC languages are surprised Rust can't make things "live long enough".

If you really need a general 'long enough' strategy and can't just pick a sensible place to drop the object statically, that's what Rc<> and Arc<> provide - built from the ground up via refcounting.

> Users coming from C are surprised that references aren't like pointers.

For good reason. General "pointers" don't have a simple, compositional semantics that preserves modularity (Yes, I know about separation logic; that's not practically reasonable in a language like Rust - or C/C++ for that matter - that's not built around expressing complex logical invariants in code); references do. A piece of code that uses pointers in non-reference-like ways must be understood as a unit. Which is why Rust strives to reduce such code to a minimum, marked with a scary "unsafe" keyword.

[CornCobs]

I agree. I think Rust (or at least many tutorials of Rust) paper over ownership as something the compiler deals with for you but I think that's false. You have to think about memory and ownership. Only when I started using C++ where you have to think about the same things but without the static checking do I appreciate the ability to statically check and enforce things like moving and borrowing

[tcfhgj]

> I think that to appreciate Rust's design

Why not take it for granted like you do for C vs ASM?

[adgjlsfhk1]

the C memory model kind of falls out naturally from technical constraints of hardware. the rust model comes from 60 years of accumulated pain of memory bugs, and a realization that humans are fundamentally incapable of correctly using the C memory model.