Any time you see something like this. Similar to typescript or es6 transpilers it's a signal something with the original language is off.
Perhaps it's the lack of Generics in golang.
Perhaps it's the lack of Generics in golang.
Not sure what your point about the runtimes is? We shouldn't use or build highly optimized runtimes? Go's original runtime sucked and there's been a lot of work put into making it better too, I guess they should have just stuck with it?
https://www.techempower.com/benchmarks/#section=data-r17&hw=...
I consider a good number of modern platforms fast enough for most uses. When tight requirements arise, which is rare, I resort to PoC implementations rather than microbenchmarks. There's a lot to more to consider than raw performance.
And there are plenty of variations to chose from.
Here are some more microbenchmarks that show Go and Java at about the same performance, and the rules of the game prohibit idiomatic Go optimizations (hence the poor performance on binary-tree; regex-redux is slow because Go's regex library is famously unoptimized).
For real-world programs, Go and Java are in the same ballpark.
Could you elaborate on what the shortcomings of the original runtime were? Might you have any link regarding this? Thanks.
Nothing that surprising, really.
If you look at Go's release note history: https://golang.org/doc/devel/release.html look towards the first few releases for the bugs they mention. For instance, here's a 1.1 fix: https://github.com/golang/go/commit/d72c550f1c7e13c323f4507b...
One of the advantages of not mutating the language too much is that there aren't very many things like this in the last few releases. I would expect the first 2.0 release to have a few rough edges even in the first non-beta release.
Besides the fact that generics is a up and coming feature in go 2 basically proves my point.