3 ms·
Note that Go needs those knobs just as much as the JVM does, at least some of them. They just didn't want to expose them.
by tsimionescu 3y ago
Note that Go needs those knobs just as much as the JVM does, at least some of them. They just didn't want to expose them.
- philosopher1234 3y agoWhich knobs does go need?
- tsimionescu 3y agoFine-grained control over various GC phases and decisions (such as the level of parallelism, max pause times). Until Go 1.19, it was even missing a max memory limit, and even now it only has a soft memory limit. Additionally, of course it would be nice to have more GC options, such as choosing between a throughput-oriented GC design and a latency-oriented one, having the option of a compacting GC of some kind to avoid fragmentation, or even having a real time GC option. Go has chosen a very old-fashioned GC design with very few tuning parameters possible, but even so it only exposes a very basic form of control.
- cwbriscoe 3y agoI would rather just write code and trust the existing GC than mess around with knobs all day. I suppose there are < 1% of projects that may see some benefit in messing with the GC.
- kbolino 3y agoI agree with most of your points but how is it "old-fashioned"? To me, that means things like reference counting or long stop-the-world pauses, neither of which are true of Go.