4 ms·

I think you focus a lot only on one aspect of thread performance - when you need millions of threads. Yes, I agree, if you need millions of concurrent things ru

I think you focus a lot only on one aspect of thread performance - when you need millions of threads. Yes, I agree, if you need millions of concurrent things running, then you quite likely don't want to use millions of threads. But many apps don't need such a high degree of concurrency, and OS threads are very performant up to a few thousand threads. And in cases where you really want to run millions of concurrent things, and where performance and scalability are the top concern, Rust gives you a plethora of other tools. > Do those use the async/await keywords too, or are they somehow made sync-like? Sure they do, but now you seem to be dismissing a useful feature just because it has slightly different syntax than in your favorite language. But this is essentially the same feature.

paskozdilar 4y ago
I'm sorry if it sounded like I'm dismissing it. Async/await is very useful for massive IO in many programming languages. I've personally worked with a lot of async Python, which can be painful to write. Rust's static typing does make things much better. However, the reason I like Go's approach so much is because it abstracts away all the mundane details about scheduling, and lets us focus on what we want. If we want 1000 threads of execution running concurrently and doing something complex, we can just `go` 1000 functions and pass the corresponding channels to them - the optimal way (MxN coroutine-thread mapping) is already invented and it's been implemented inside the language. Rust will probably always win when it comes to extreme optimizations. Golang's strength is in simplicity and straightforwardness in writing everyday concurrent code.