> a randomized controlled trial with volunteers from a 633-person class, collecting data from 428 students in total

If I understand this experiment, college students i.e. in average completely inexperienced programmers, where tested. IMHO, this only points to the fact that Rust has a steep learning curve. I can imagine that using javascript instead of Rust would have them finish their tasks even faster, but doesn't tell us that GC in Rust is a great idea.

What aspect is steep?

From the code I've seen, Rust is intuitive when coming from the classical languages like Java, C or JS. It's not lisp or Haskell.

To clarify, I don't intend to come off dismissive. I'm genuinely curious what the scary parts are so I can better plan my own studies.

The borrow checker and lifetimes have been my pain points. Also understanding Some and Result, which after practicing I understood them, and now they are ok. They were foreign concepts to me.

I still struggle with lifetimes, but I do understand them better.

I personnaly find the ownership thing really hard to get. That's the thing that protexts you from screwing memory in parallel code but the thing is you have to use it even in non parallel code. The other thing is that it's a set of rule which mixes with the type system, so at the beginning, I had hard times understanding if I had issues with my types or with the ownership (eventhough, I know, ownership issues are reported as such by the compiler). So in the end, you have to think about memory safety much more deeply. I get that my code really feels right once it's written with ownership principles but somehow, it makes Rust hard to start with. Now, this ownership part is something really new to me (I have ASM,C++,Python,Java real life experience), it makes me think better about about my programs. So it's a tough but fruitful experience.

The most common issues are with ownership, lifetimes, and the borrow checker.

If the person is an experienced C or C++ programmer they'll probably have an easier time as you need some understanding of ownership and lifetimes to correctly use pointer-likes in those languages. The most likely issue here is that their mental model of ownership and lifetimes does not exactly match the borrow checker's.

If they're coming from a language such as C# or Python, where you don't need to deal with these to anywhere near the same extent, suddenly being forced to reason about it just to pass the compiler can be bit of a hurdle.

Would be interesting to see this repeated with people that had significant Rust experience rather than a class of students mostly coming to the language for the first time.

The interesting part is putting a number to this: 4 vs 12 hours. Just the direction of the inequality is of course unsurprising.

I have looked superficially at Rust since I have no use case for me right now and it's truly complex but people downplay the importance of not having GC. There are plenty of languages with GC, for a reason. People use C, C++ or similar for a reason too, not out of masochism.

this study is extremely flawed. It is impossible to tell if these results are from the garbage collection or how bronze violates rust aliasing

The counterpoint is that using a GC makes the workload unpredictable. The GC may kick in at any time. Rust has a predictable performance profile and that’s important in some applications.

Note that GC makes explicit the costs associated with memory allocation and freeing; languages that use manual memory management (or semi automated memory management as in Swift/Rust) simply un-amortise the cost and distribute it all over the program.

While Rust may have less issues than other languages in this regard, it doesn’t change the fact that destruction of a “thing” can result in a transitive set of “other things” being destroyed as well, and depending on the state of the program, this set could have a pretty high bound.

Even in a “predictable” language like Rust, a data entry containing a map like structure is going to have a different destruction time if the map is empty vs if it is full.

The other aspect of “predictable” delays in a program completely ignores the runtime issues that can happen at the OS layer, such as swapping/page cache invalidations/migrations between cores of numa regions etc. so it is rarely the case that any program in any language is going to have predictable behaviour. Even trivial things, like the number/size of environment variables user at program startup can have a performance delta.

Anyway, the point is that when programmers talk about “predictable” behaviour in a program, what they generally mean is “invisible performance problems” and so it gets swept under the carpet.

That’s not to say that GC doesn’t introduce variance into measurements, but it is not the only thing that causes variance and many of the good GCs are capable of using multiple cores and can avoid interrupting the program runtime without significant overhead, although obviously tracing collectors will increase pressure on a memory system in a way that explicit/automatic memory management does not.

> Note that GC makes explicit the costs associated with memory allocation and freeing; languages that use manual memory management (or semi automated memory management as in Swift/Rust) simply un-amortise the cost and distribute it all over the program

This is generally an interesting feature of garbage collected languages, and it's often more efficient than manual memory management - but it does come with downsides.

> Even in a “predictable” language like Rust, a data entry containing a map like structure is going to have a different destruction time if the map is empty vs if it is full.

"Predictable" does not mean "always the same". It means that given a map with the same size and fill level, destroying it will take the same time. What's more important is that the point in the program where the destruction happens can be controlled - and, if necessary, moved out of the critical path of something that requires response within a certain bound. This may introduces an overall inefficiency in the program, but if you have software that needs to fulfill certain time bounds, that's the tradeoff you choose. Doing so in a garbage collected language is much harder.

And rust targets environments where (near)-realtime behavior and predictable performance is important, or where garbage collection is not truly possible since allocation isn't even possible (think embedded systems).

> Anyway, the point is that when programmers talk about “predictable” behaviour in a program, what they generally mean is “invisible performance problems” and so it gets swept under the carpet.

I don't see how this is a counterpoint to what I said - programmers blaming other things for performance problem has been a thing like forever.