[draw_down]

This article is a bit all over the place, and the basic premise is not very good.

The Andrei guy says that Rust places too much emphasis on "clerical" memory management. This is not like a person who learned PHP from a couple w3schools article deciding that Lisp is "weird". The criticism is not that Rust is "weird" or somehow unintelligible, it's a direct critique of the language designers' choices.

This is the danger of using rules like the Blub paradox, you have to be careful or everyone who doesn't agree with you or doesn't like what you like is a Blub-programming dullard.

I actually do think there is something to the paradox, I would even say I have occupied different parts of that "ladder" myself. (That is, I'd like to think I'm higher on it now than I used to be.) But maybe JS programmers aren't interested in type-checking in their JS precisely because they prefer JS for its dynamically-typed nature. This is as opposed to someone coming to JS from a different language and bringing their preference for strong typing with them.

Then the author goes on to talk about a bunch of stuff that does nothing to explain Rust's apparent emphasis on memory. It's pretty much just a list of why Rust is cooler and better than C++. That's fine but none of it addresses the point made at the outset.

[dbaupp]

> The Andrei guy says that Rust places too much emphasis on "clerical" memory management. This is not like a person who learned PHP from a couple w3schools article deciding that Lisp is "weird". The criticism is not that Rust is "weird" or somehow unintelligible, it's a direct critique of the language designers' choices.

It might be a direct critique, but it's a critique of an incomplete picture of Rust: the rules that allow Rust to avoid a GC offer benefits far beyond just that, such as being a core component of Rust's concurrency story[1], and avoiding problems such as iterator invalidation (not generally a memory safety problem in a GC'd language, but still a semantic one, e.g. Java's ConcurrentModificationException).

(The "Weird feature #3" part of the article is exactly this point, although I think it doesn't go far enough in calling out the incomplete picture of Rust implied by the original quote.)

[1]: http://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.ht...

[pekk]

I have a vague question: how can you avoid putting emphasis on memory management, to the extent Rust does, without introducing mandatory garbage collection?

[tormeh]

My understanding is that Rust is, to be wildly inaccurate, kind of like a language without a heap. Normal languages manage stack memory without GC. Rust kind of does the same: When deleting a stack frame, Rust deletes the objects created when on that stack frame, except when a reference is returned by the scope corresponding to the frame, in which case the "ownership" of the heap object is passed to the frame under the deleted-to-be frame.

Sort of. Don't cite me.

[firebones]

At one extreme, this (???): https://en.wikipedia.org/wiki/Stack_machine