3 ms·
> The only problem GC is subject to is allocating more data than you have physical memory for... On the contrary, the big issue with the GC is what happens whe
by gwd 4y ago
> The only problem GC is subject to is allocating more data than you have physical memory for...
On the contrary, the big issue with the GC is what happens when the actual collection happens. There's an apocryphal story about a research team that was making a table-tennis playing robot; but every 5 minutes the robot would randomly pause; in then end they discovered it was the Java garbage collector pausing the entire thing to run. Much less apocryphal, and more recently, Discord rewrote one of their services from Golang to Rust specifically because of the garbage collector [1].
Yes, misusing pointers is a potential problem; but when you're talking about situations where precise timing of maneuvering thrusters or stepper motors can make or break your mission, a garbage collector is arguably a much bigger problem if you don't have a way to make it predictable.
[1] https://discord.com/blog/why-discord-is-switching-from-go-to-rust https://discord.com/blog/why-discord-is-switching-from-go-to...
- cestith 4y agoThere are predictable garbage collectors, though. Not every GC is a stop-the-world type. A good reference-counting system with the ability to weak-reference a variable can be pretty predictable and avoid loops as just one example.
- panick21_ 4y agoGo GC is still pretty immature compared to the best Java systems. And there were really quite good GC developed in the 90s. GC systems with predictable pause times (if you know the load) very much exist. So if you are not loading arbitrary code you can do a lot with a memory safe GC system. However I do think more could have been done in that space in the last 20 years instead of having so much C code everywhere.