I didn't get that at all. I read two main criticisms, both of which aren't explicit in the Go implementors' claims but are strongly implied by the language and style:
1) they've solved for Go
2) this is comparatively better (almost mockingly so) than other VMs because of the advanced nature of their implemtation
The post suggest that 1) is overreaching and misleading: GC is always about trade-offs. It suggests that 2) is also false, because their implementation is not particularly advanced and just follows from the trade-offs they made in 1).
It does rather seem like over-marketing what they've done, regardless of whether it useful in many Go use-cases.
Article has lot of guess work about Go's GC. However in comments section some shortcomings of his claims are pointed out including one by Go GC implementer, he added more guesses about his assumptions. This may all be very valid but there are no numbers for that in this piece.
There's not "a lot" of guess work. It's quite clear to read that it is mostly about GC trade-offs and technologies in the general sense, not especially critical of Go's implementation. There are very few absolute claims of good/bad, if any. A poster on a Go forum admits that the latency improvement cost 20% CPU usage, and the article doesn't call this necessarily bad.
You're making a very uncharitable interpretation, and unjustifyably calling them guesses only makes it more so.
It is lot of guess because there are no memory usage numbers or throughput numbers to get general sense of how Go GC is worse for applications.
Even in the thread about 20% CPU usage increase mentions that Go implementer considers this much higher than expected and is likely a bug. But author make it sound in article as Go guys are calling it reasonable tradeoff for low latency.
1) they've solved for Go 2) this is comparatively better (almost mockingly so) than other VMs because of the advanced nature of their implemtation
The post suggest that 1) is overreaching and misleading: GC is always about trade-offs. It suggests that 2) is also false, because their implementation is not particularly advanced and just follows from the trade-offs they made in 1).
It does rather seem like over-marketing what they've done, regardless of whether it useful in many Go use-cases.