21–30 of 59 posts
I can't tell when this was written, am I missing something?
Line for line Go will be faster it is compiled. It is the only thing that matters line for line.
The article talks about IO, but then benchmarks sha256. The node program doesn't work well because he's synchronously doing this: for (var i = 0; i He should be using crypto and the async versions. This benchmark actually is just measuring the speed of your sha256 implementation, which I would guess is equal on all 4 platforms if you actually do them correctly.
I do find it hilarious that the article talks IO and then benchmarks a CPU bound app.
So he acknowledges that has not benchmarked the best options for Java and then selects Go as a winner, what a joke.
Pet peeve: tech articles/blogs which do not prominently display when the article was written. This is the single most important fact I search for before reading time sensitive tech info. I can't tell when this was written, am I missing something?
Earlier quoted context omitted.
Yeah that perplexed me as well. There's no reason you can't get a modern Java app server to do async io coupled with thread pools and achieve performance close to Go. Maybe Go's coroutines vs Java native threads may give Go a little advantage but it shouldn't be a great difference for sanely designed applications.
Netty would be one possible option, but he selectively left out everything that could jeopardize Go's victory.
Yes, it shows...
Earlier quoted context omitted.
Yeah that perplexed me as well. There's no reason you can't get a modern Java app server to do async io coupled with thread pools and achieve performance close to Go. Maybe Go's coroutines vs Java native threads may give Go a little advantage but it shouldn't be a great difference for sanely designed applications.
Netty would be one possible option, but he selectively left out everything that could jeopardize Go's victory.
I'm curious, which Java servers are creating a new Thread per request? Tomcat uses acceptors threads and a request executor pool. And, if available on your platform (which it probably is), it defaults to using non-blocking IO instead of polling. EDIT: It looks like he does acknowledge the executor threads are pooled. His main criticism is that "too many blocked threads are bad for a scheduler". But if Tomcat is using…
A more comprehensive benchmark is done here. https://www.techempower.com/benchmarks/#section=data-r14&hw=...
So he acknowledges that has not benchmarked the best options for Java and then selects Go as a winner, what a joke.