2 ms·

I can't fathom deploying anything critical WITHOUT GC. It's far too easy with malloc/free to make errors such as replacing a pointer with a pointer to another

I can't fathom deploying anything critical WITHOUT GC. It's far too easy with malloc/free to make errors such as replacing a pointer with a pointer to another object and forgetting to free the original, freeing something that is still referred to somewhere else and then the other place using it and corrupting any new object allocated in that space, or freeing something that has already been freed, again potentially corrupting a new object reusing that memory. None of those is possible with GC. The only problem GC is subject to is allocating more data than you have physical memory for, and that is equally as much a problem with malloc/free so GC is no worse for that error, and better for the others.

deleted 4y ago
[deleted]
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 ago
  There 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 ago
  Go 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.

deleted 4y ago

[deleted]

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 ago
There 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 ago
Go 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.