Golang’s most important feature is invisible

Re:Golang’s most important feature is invisible by jeffbee on Saturday January 22, 2022 @10:34PM (#30043374)

Unfortunately the batteries-included runtime of Go effectively forecloses any really high performance server code that scales well to huge machines. What it offers is moderately good and that's all you'll ever get. A Go web server will work OK on 8 cores and it will only go a bit faster on 32 cores and not at all faster, possibly slower, on 256 cores. Meanwhile Java async programs are still scaling up. These results are apparent if you look at the gRPC multi-language benchmarks.

There's only one way to write a server in Go and that has pros and cons.

[ Parent | on HN ]

Re:Golang’s most important feature is invisible by technosamay20 on Sunday January 23, 2022 @03:44AM (#30044639)

Thanks for sharing this insight. Is this a issue with just the web server.

If I have a standalone task, which tires to use 128 cores and manages parallel tasks using goroutines communicating via channels - will I be able to successfully leverage 128 cores.

[ Parent | on HN ]

Re:Golang’s most important feature is invisible by jeffbee on Sunday January 23, 2022 @12:33PM (#30048177)

If your tasks are large enough to dominate, then the non-scalability of the goroutine scheduler and the network stack won’t be an issue. For example, if your task is compressing some huge hunk of a video and it takes a second to do it, then it will scale fine. Then again, you can get this scalability from anything, including `xargs`.

[ Parent | on HN ]

Re:Golang’s most important feature is invisible by rawoke083600 on Sunday January 23, 2022 @10:34AM (#30046876)

Interesting.. Any sources or examples ?

[ Parent | on HN ]