Go performance from version 1.2 to 1.18

Re:Go performance from version 1.2 to 1.18 by IshKebab on Friday February 04, 2022 @03:19AM (#30204165)

I do like Go, but I have to say I rewrote a small (500 line) Go file I'd written into Rust and was constantly thinking "this is better in Rust". And I suspect that Rust performance would have started pretty much where Go 1.18 is now.

But I definitely agree that reading other people's Go code is a lot easier than Rust. Especially async code. I don't understand why so many people use async outside of web servers which AFAIK is the only place you really need it.

[ Parent | on HN ]

Re:Go performance from version 1.2 to 1.18 by Matthias247 on Saturday February 05, 2022 @12:48AM (#30218074)

not even necessarily in web servers. If one writes a frontend proxy server which needs to work on > 10k concurrent connections it's likely the way to go. But for an application server which sees much less concurrency it might not matter that much.

[ Parent | on HN ]

Re:Go performance from version 1.2 to 1.18 by quickthrower2 on Friday February 04, 2022 @05:42AM (#30205129)

Web servers and web browsers, which is a lot of todays dev work.

[ Parent | on HN ]

Re:Go performance from version 1.2 to 1.18 by IshKebab on Saturday February 05, 2022 @10:33AM (#30222042)

Why would a web browser need async? It can use threads.

[ Parent | on HN ]

Re:Go performance from version 1.2 to 1.18 by quickthrower2 on Saturday February 05, 2022 @10:45PM (#30229188)

Well nothing needs async, you can use threads anywhere. But it is the predominant model for JS

[ Parent | on HN ]

Re:Go performance from version 1.2 to 1.18 by IshKebab on Sunday February 06, 2022 @05:19AM (#30231126)

It's the model in JS because JS does not really support threading (web workers are more like separate processes) so it's the only way to do it.

The actual browser doesn't need async.

When I say "need" I mean that it provides a decent performance increase.

[ Parent | on HN ]