5 ms·
you can turn off the gc in Go and run it manually. you can also write cache-aligned arrays of structs in Go if you want to. you can allocate a slab and pull fro
by zemo 7y ago
you can turn off the gc in Go and run it manually. you can also write cache-aligned arrays of structs in Go if you want to. you can allocate a slab and pull from it if you want to. the existence of a GC doesn't preclude these possibilities.
- inimino 7y agoWhy pick a language that has a feature you need to immediately turn off? Some people probably want to, but ... why?
- vnorilo 7y agoMany programmers are very emotional about their language of choice, especially if it is their only one.
- fileeditview 7y agoI guess you use every feature (insert any language here) offers for every program you write with it? The answer to your question is probably: because they like the language, are productive in it, know the libraries and the feature can be turned off so it's an option.
- inimino 7y agoIf I consistently don't use all the features, I pretty quickly start looking at simpler languages.
- h0l0cube 7y ago>you can turn off the gc in Go and run it manually And if you run the GC manually, you really don't know how long it will take - read: determinism. > you can also write cache-aligned arrays of structs in Go if you want to Wasn't this thread about why people don't use GC, not about go? I don't remember. If you're using an object pool, you're dodging garbage collection, as you don't need to deallocate from that pool, you could just maintain a free-list. > you can allocate a slab and pull from it if you want to. the existence of a GC doesn't preclude these possibilities To take it further, you could just allocate one large chunk of memory from a garbage collected allocator and use a custom allocator - you can do this with any language. But you're not using the GC then.
- gameswithgo 7y agoThe existence of a GC, even when it can be turned off, does preclude a great many other possibilities, in practice. One issue which is nearly universe, and extra bad in Go, is the extra cost of FFI with C libs, which is necessary in games to talk to opengl, or sdl2, or similar. If you aren't going to use the GC, then you open up a lot of other performance opportunities by just using a language that didn't have one in the first place.