Hacker News Reader

Comment by logicchains | Hacker News Reader

People talk about C++ suffering from its commitment to zero-cost abstraction, but the same thing applies to Rust async. While async may theoretically be the fastest possible way to write asynchronous code, it feels like an order of magnitude more painful than the CSP/channel-based approached used in languages like Go and Clojure (and the upcoming Java Loom).

Personally if I had to write async code that required anything other than the absolute minimum possible latency, I'd prefer to write Go, and I say that as someone who thinks Go's lack of generics was an absolutely terrible idea.

View on HN

I made the mistake of trying to learn Rust while doing async programming.

IMO, when it comes to concurrent, it's a matter of picking your poison:

Threaded Rust: No overhead of a GC, but overhead of context switches and multiple stacks.

NodeJS: No overhead of context switches and multiple stacks, but the overhead of a highly optimized GC. (And I suspect that the GC can do tricks like run when the process is waiting on all tasks.)

Some real data would be very interesting.

There’s plenty of real world data. I forget the name of the website but web server benchmarks are pretty good at showing the differences.

Maybe this: https://www.techempower.com/benchmarks/

Yes those are the ones I was thinking of, thanks!

Unless you really need the best performance possible there're pretty good alternatives. Mainly C# or Go and soon JVM with Loom.

Some numbers: https://web-frameworks-benchmark.netlify.app/result?l=rust,g...

Why the need to wait for loom when there is Kotlin and coroutines?

> No overhead of a GC, but overhead of context switches and multiple stacks.

Is it really an overhead if it happens in parallel? You have real parallelism, not only concurrency.

Only if your application can limit the number of threads to the number of physical cores.

IE, of you're doing a web server with a thread or process for each incoming web request, you're blocking and context switching. If you have to have locks, you're also blocking and context switching.

This is why async programming models are common, they move the logic of blocking and context switching into the language and runtime, where the compiler can juggle more concurrent tasks in a single thread. It's just harder to do in Rust because, to oversimplify, things that are in stack memory in a threaded environment are now on the heap. In C#/NodeJS, this difference is transparent, but in Rust it's not.

Async in something like C# is much less painful precisely because it doesn't try to be a zero-cost (or at least as low cost as possible) abstraction. When the language can allocate stack frames on the heap implicitly as needed, and there's GC to clean them up, things "just work".

Go now has generics. The performance of using them is hit or miss it seems.

Your opinion is valid, but I would say, if you aren't juicing for the best performance, you can adopt easier patterns to async. There are comments on this post detailing how to go about doing that. Or yea use another language if you want.

>you can adopt easier patterns to async

Can I do this without having to wrap half the libraries in the ecosystem if I want to use them without worrying about async? C# has that issue: the ecosystem buys heavily into async, so it can be hard to avoid it.

Probably depends on what you are using and trying to do. So I'll say 'maybe'.

But Go still doesn't have enuns with data like in Rust.

Reply on news.ycombinator.com