[amelius]

Meanwhile, GoLang allows thousands of threads without problems.

[avgcorrection]

Meanwhile, a language with completely different design goals does things in a very different manner.

Stop trying to stir shit.

[jedisct1]

And servers such as fasthttp have excellent performance.

[smilekzs]

FTFY: thousands of GREEN threads

[amelius]

Does it matter? The point is that Go has excellent throughput and latency, while using only a single concurrency model.

[jen20]

Yes, it does matter. It has excellent throughput and latency for certain classes of systems, while others are impossible to build. Rust may not impose this constraint while meeting its goals.

[hu3]

Seems like Rust is better in every way right? I can't help but wonder why is it that Go is so much more popular when it comes to language of choice for networked and multi-threaded applications.

[jen20]

It's not better in every way at all - it is more flexible. I regularly bounce between Go and Rust in different contexts.

[hu3]

Interesting. When would you use Go instead of Rust?

[stjohnswarts]

Because it's easy to learn and "good enough". Rust is not easy to learn.

[amelius]

You can say the same about assembly language. Yet it is used only by a very narrow audience.

[mcronce]

I would not describe latency as "excellent" in Go, unless you're measuring average or p90.

[vips7L]

What happens if you need to do computational work on a go routine? Isn’t that going to block the carrier thread and then murder throughput?

[IshKebab]

Yes, you have to manually insert yield points. Exactly the same as with every cooperative threading system, including Lunatic and Rust's native async/await.

Kind of feels like we need user space preemptive threading somehow.

[smasher164]

Go has asynchronous preemption now using signals. Tight loops are preemptible.

[vips7L]

Or just the ability to use native os thread pools for that type of work.