9 ms·
> I don't agree with Go marketing their GC as if it magically provides no trade offs. I don't believe this to be true. They always point out painstakingly, tha
by Merovius 10y ago
> I don't agree with Go marketing their GC as if it magically provides no trade offs.
I don't believe this to be true. They always point out painstakingly, that the advances made on pause times come with less throughput, for example.
What the go people are doing (and with which I tend to agree and I believe it's hard to argue against the success they're having), is to say that they believe it's possible to build a GC which is good enough for most modern use cases and doesn't come with a lot of tuneables.
(However, even that comes with tradeoffs; it limits the use cases that go can be used for. For large enterprises, being able to minutely tune a GC might be an important thing)
- refulgentis 10y agoApologies for the brusque contrarianism, but this simply isn't true. I spent hours pouring over all the material they published when starting on this journey, because I was astounded that a team with a reputation for purposely avoiding groundbreaking work in favor of productivity today, had done something truly groundbreaking. It wasn't remotely clear that the advancement here was "We don't provide settings, because we're guesstimating your workload matches the standard Go use case!", and all the histrionics further masked this truth. At this point I'm just repeating the article, though. :)
- deleted 10y ago[deleted]