11 ms·
Why not Go? Mandatory GC.
by askimto 13y ago
Why not Go? Mandatory GC.
- nathany 13y agoI suppose if you're writing a Triple-A video game or real-time/firmware? (neither of which are "server") Outside of those cases, Rob Pike has given some discussion on interior pointers and how it's possible to limit the amount of garbage generated: http://talks.golang.org/2012/splash.article#TOC_14 http://talks.golang.org/2012/splash.article#TOC_14. (along with the usual techniques, like object pools, used with good success in JavaScript and Android games).
- kaib 13y agoThis is incorrect. I've written a bunch of ARM firmware in Go and I've seen server applications that use custom allocators for allocation sensitive code.
- pcwalton 13y agoQuoting Ian Lance Taylor: "Ultimately, though, it sounds like you want a language which has no garbage collection, and Go is not that language. Language constructs will allocate memory in ways that are not immediately obvious, so there is no reasonable way for a Go program to completely manage its own memory." https://groups.google.com/d/msg/golang-nuts/LoJJ1bICduA/AQFtD8_VI0sJ https://groups.google.com/d/msg/golang-nuts/LoJJ1bICduA/AQFt... Of course you can write memory pools and free lists—you can write them in any language—but, like other languages, the GC will still trace them during mark time and there is no safety provided by the language if you return an object to the pool that's still in use, or leak objects by forgetting to reuse them, and so on. The fact is that programming in Go, for all practical purposes, requires using a garbage collector.
- kaib 13y agoWhen you manually allocate memory you are naturally responsible for the lifecycle of that memory. In Go you allocate such memory outside the GC to avoid tracing.
- pcwalton 13y agoThe issue, as Ian pointed out, is that it's hard to pinpoint when GC allocations occur. Language constructs allocate in ways that are not immediately obvious.
- thirsteh 13y agoWhich isn't an issue for most people, and most applications. Not all, but most.
- papsosouid 13y agoThat is why it fails as a replacement for C like it was originally marketed to be. But fits nicely as a replacement for python. People can start getting concurrency, limited type safety, and reasonable performance without having to really learn anything. The switch from python to go is pretty much trivial.
- jff 13y agoDo you write kernels? No? Then shut the fuck up with your GC FUD. Lisp somehow managed to get past that and become the golden child of HN; will it take 50 years and pg's blessing before people stop whining about this in every Go thread?
- askimto 13y agoI don't like Lisp either.