5 ms·
> I predict that garbage collectors will become popular in Rust eventually. Not having a GC and not freeing memory by hand is one of the features that makes Ru
by mhaberl 5y ago
> I predict that garbage collectors will become popular in Rust eventually.
Not having a GC and not freeing memory by hand is one of the features that makes Rust special. What would be the point of this?
> I feel like Rust is self-defined as a “systems” language, but it’s being used to write web apps and command-line tools and all sorts of things. This is a little disappointing
Why would using the language for non-system programming be disappointing?
I have a feeeling that it has become popular lately to criticize Rust for whatever reason, I guess that's what happens when more people use the language
- erk__ 5y agoA 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. [0]: https://arxiv.org/abs/2110.01098 https://arxiv.org/abs/2110.01098
- Xylakant 5y agoThe 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.
- alblue 5y agoNote 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.
- Xylakant 5y ago> 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.
- mhaberl 5y ago> 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.
- nefitty 5y agoWhat 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.
- sieabahlpark 5y ago
- wiz21c 5y agoI 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.
- woile 5y agoThe 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.
- linspace 5y agoThe 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.
- meheleventyone 5y agoWould 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.
- DrMeepster 5y agothis study is extremely flawed. It is impossible to tell if these results are from the garbage collection or how bronze violates rust aliasing
- vegai_ 5y ago>Not having a GC and not freeing memory by hand is one of the features that makes Rust special. What would be the point of this? To put it bluntly: to make writing Rust fast and fun. If you think it's fast and fun right now, you're either very good at it or somehow delusional.
- lewantmontreal 5y agoIs GC for Rust possible in the future? I’d love that if it means simpler compiler error messages for e.g. closures.
- alice-i-cecile 5y agoHonestly, if you're working within a well-architected framework, writing Rust is genuinely a joy (except perhaps async). The painful challenges of "how do I design something that plays nice with the borrow checker" can be solved once, and then you just stick to convention and enjoy the expressiveness of the trait system.
- duped 5y agoWhat would garbage collection buy you in a language like Rust?
- DarkCrusader2 5y agoAgree with this. I wrote some non-trivial amount of code in Rust just to give is a proper try. After countless hours spent in understanding borrow checker, life times and waiting for compilation to finish, I still have to constantly fight borrow checker. When working with Rust, I am not "making thing X" but instead "writing Rust which happens to be X". The code is littered with either `unwrap` of `?` which is just exception management done manually with hardly any benefit. On systems programming front, last time I checked there were two options to make system calls (apart from writing inline assembly), the `libc` or the `nix` crate. `libc` is just a wrapper so exposes `unsafe` C like API which doesn't make for idiomatic Rust code. `nix` was incomplete on lots of front, not sure if things have changed now since it has been a while I tried Rust. So much for a systems programming language.
- hawk_ 5y ago“There are only two kinds of programming languages: those people always complain about, and those nobody uses.”
- coldtea 5y ago>Not having a GC and not freeing memory by hand is one of the features that makes Rust special. What would be the point of this? That some people don't care what makes a language "special", but e.g. like its syntax, ergonomics, ecosystem, and so on.