A interesting paper I saw about adding a GC to Rust is this[0] where they made some programming challenges and showed that the ones who used a GC finished the task faster.
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.
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.
I still struggle with lifetimes, but I do understand them better.
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.
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.
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.
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.