Illegal relicensing aside, this entire kerfuffle still makes anbad case for Golang.
If it's THAT much easier to make a more efficient server with a fully dynamic language using just coroutines then why should anyone ever use Go in this case?
Saying, "this implementation is bad" might work in another comparison, but given how much of Golang's implementation and engineering philosophy has been driven by an argument of "simplicity" it seems like we keep seeing precious few returns.
No. There was a lot of effort put into things that make no sense in the go version, including using a concurrent, lockfree, snapshot iterating hash array, where they'd most likely have better performance in this case with a map and a mutex.
This was NOT simple. The node.js version is simple. The Go version is overblown in complexity and abusing the language.
Rewrite the go version using just as simple of structures, and using a sqlite, and I'm extremely confident that it'd be more performant.
On the data structure: arguing for locked mutation is pretty an tricky because at low volumes it'll be faster and at higher traffic volumes it will be slower.
And since it's a library, who cares?
Golang isn't a language that's old enough to have accumulated a ton dissonance about the "right" way to do things. Golang encourages that kind of code and you see it all over GitHub. Too bad it's something of a trap.
Go is multithreaded. Paying a small price to use multiple cores vs. only being able to use a single core? I'll take the multicore. It's not like concurrent lock-free datastructures are without cost...
If your workload is primarily I/O then coroutines will lose on the wall clock. And of course parallel workloads are fiddly.
But it's also worth noting Golang's current implementation of channels and messages is (as I've noted) going to be notably slow. Odds are you are going to avoid channels entirely if you care about maximizing multi-core performance.
Which is not to say that Golang "isn't fast". Just that it's not at all surprising that for some workloads NodeJS would outperform it.
If it's THAT much easier to make a more efficient server with a fully dynamic language using just coroutines then why should anyone ever use Go in this case?
Saying, "this implementation is bad" might work in another comparison, but given how much of Golang's implementation and engineering philosophy has been driven by an argument of "simplicity" it seems like we keep seeing precious few returns.