[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?

[jen20]

Primarily things like web services where memory and CPU footprint matter less than raw performance or correctness, but also tooling which needs to operate on cloud APIs which often have no Rust SDKs available.

[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.