Live data from Hacker News

Why asynchronous Rust doesn't work

theta.eu.org

221–230 of 499 posts

Re: Why asynchronous Rust doesn't work

#221
post #6

As I read through the database example, I saw that the compiler just caught a multi-threading bug for the author, and instead of being thankful, he’s complaining that Rust is bad. I think he should use a higher level framework, or wait a few years for them to mature, and use a garbage collected language until then.

He's just pointing out that it isn't very ergonomic, not that Rust is bad (in fact he states the opposite multiple times). Pointing out weaknesses and things that might be done better is what helps something mature, not just praising it.

"Ergonomic" is such a nebulous word as to be nearly useless honestly.

I don't see how it is [unduly] inefficient or uncomfortable for a language at Rust's level to ensure that the programmer actually thinks through the execution of the code they are writing. If one doesn't want to think about such things - and there's absolutely nothing wrong with that! - there are plenty of higher level languages that can do that legwork for them with more than good enough performance.

To me it feels a bit like pointing out that the process of baking a cake from scratch isn't very ergonomic, what with all the careful choosing and measuring of ingredients and combining them in the right order using different techniques (whisking, folding, creaming, etc). That is simply what goes into creating baked goods. If that process doesn't work for you, you can buy cake mix instead and save yourself quite a bit of time and energy - but that doesn't necessarily mean there's anything to be done better about the process of making a cake from scratch.

Re: Why asynchronous Rust doesn't work

#222

Earlier quoted context omitted.

The problems are (1) either you write two versions of almost every function or you can only support one use case (sync or async). If you could write generic functions which work in both cases it would be better. (2) it creates a lot of noise writing async/await. It's like if we had to always write x = call f() in the sync case.

If you write your functions as async, it's trivial to make a sync wrapper out of it.

not in every language (JS)

Re: Why asynchronous Rust doesn't work

#223
post #28

Earlier quoted context omitted.

> caught a multi-threading bug The compiler complained: “error[E0308]: mismatched types”

That’s why it’s amazing, type safe efficient multi-threading without dynamic memory allocation with a nice syntax...it’s the holy grail of server programming.

Why would I want to write a server in a language that requires such awkward approaches to basics like coroutines and dynamic dispatch when I could use kotlin on the JVM and get pauseless GC, ultra fast edit/compile/run cycles, efficient and powerful coroutines, and eventually Loom which will eliminate the whole problem of coloured functions completely and let me just forget about coroutines? Multi threading bugs are not so common in real Java/Kotlin programs to justify this epic set of costs, in my view.

Re: Why asynchronous Rust doesn't work

#224
post #148

Earlier quoted context omitted.

I am curious where you get that impression. From what I could see, recent releases have just been "smoothing over pits" / filling in obvious type holes left over from older changes. Changes in rust edition 2021 are tiny and it seems to only exist in order to establish a regular cadence.

Disclaimer: I've only dabbled in Rust from time to time, but have not written anything serious with it. Those kind of comments are not based on looking at Rust's features on a theoretical level. It's more from the viewpoint of "How hard is it to get something (correctly) done". Those impressions are mostly formed either from using the language and failing (or having severe difficulties) to solve a given problem, or b…

It is hard to stop people perceiving Rust as over-complex if they are motivated to perceive it as over-complex.

Re: Why asynchronous Rust doesn't work

#225
post #219

I started recently learning Rust, and a thing I don't understand is why they decided that threads have to be done this way and not simply wrapping what is available in the OS (I know that at some point, at the core, a Rust thread is the same thing I create with pthread_create ). Like, in both Windows and Linux, threads exist as a callback function (pointer to function) with its own stack, in which a void* parameter i…

What you've described with pthread_create is basically a closure, just implemented within the limitations of C and like many things in C, wildly unsafe. You can of course interact with the underlying implementation if you want (Rust is quite capable of calling into libc directly), but then you're responsible for ensuring safety. Rust provides a safe wrapper over this with a closure which is generally easier to use and harder to misuse than the equivilent C.

Re: Why asynchronous Rust doesn't work

#226
post #219

I started recently learning Rust, and a thing I don't understand is why they decided that threads have to be done this way and not simply wrapping what is available in the OS (I know that at some point, at the core, a Rust thread is the same thing I create with pthread_create ). Like, in both Windows and Linux, threads exist as a callback function (pointer to function) with its own stack, in which a void* parameter i…

Note that you don't need a closure in Rust to start a thread. You can just specify a function to be called (because functions implement FnOnce).

Re: Why asynchronous Rust doesn't work

#227
post #171

Earlier quoted context omitted.

Rust programs can theoretically be fast, but most of the ones I've used are slow. I tried two high profile implementations of the same type of software, one in Rust and one in Java. The Java one was faster and used less memory. Rust programmers tend to do all kinds of little hacks here and there to make the borrow checker happy. It can add up. The borrow checker is perfectly happy when you copy everything. Rust is be…

I can't reduce JVM memory usage below 100MB. It simply is impossible. Meanwhile with rust I can easily write 20 times more memory efficient applications.

Try Graal native image. It precompiles all code ahead of time and drops all metadata that you don't explicitly say you need. The results start as fast as a C program would and uses 5-10x less memory. The trade-off is lower runtime performance: hotspot is using that memory to make your app run faster at peak.

Re: Why asynchronous Rust doesn't work

#228
post #58

Earlier quoted context omitted.

Why is it a problem that custom executors are difficult to implement? Most other languages that I'm aware of they wouldn't even be possible to implement.

It's not really a problem worth caring about. Just if you wanted to gripe about the complexity of async Rust it's the most obvious to me. "But pretty much no one even lets you do that" is a great counter argument. But, it is kind of an anti feature. It's incredible that Rust allows custom async executors and the surface area for them is tiny! That said, it's kind of black magic, even for Rust. I'm willing to bet ther…

Is it really that incredible? Look at how Kotlin implemented coroutines. The language support is tiny - nearly everything is implemented in libraries that you can compete with. In particular the language rejected the async/await model: you still mark functions as async (suspend) but there's no language level equivalent of await. Just lots of library level APIs to compare coroutines in different ways. It's really nice.

Re: Why asynchronous Rust doesn't work

#229

A bigger problem in my opinion is that Rust has chosen to follow the poll-based model (you can say that it was effectively designed around epoll), while the completion-based one (e.g. io-uring and IOCP) with high probability will be the way of doing async in future (especially in the light of Spectre and Meltdown). Instead of carefully weighing advantages and disadvantages of both models, the decision was effectively…

In all this time, maestro Andrei Alexandrescu was right when he said Rust feels like it "skipped leg day" when it comes to concurrency and metaprogramming capabilities. Tim Sweeney was complaining about similar things, saying about Rust that is one step forward, one step backward. These problems will be evident at a later time, when it will be already too late. I will continue experimenting with Rust, but Zig seems t…

In case anyone else was interested in the original sources for the quotes:

> Andrei Alexandrescu was right when he said Rust feels like it "skipped leg day" when it comes to concurrency and metaprogramming capabilities.

https://archive.is/hbBte (the original answer appears to have been deleted [0])

> Tim Sweeney was complaining about similar things, saying about Rust that is one step forward, two steps backward.

https://twitter.com/timsweeneyepic/status/121381423618448588...

(He said "Kind of one step backward and one step forward", but close enough)

[0]: https://www.quora.com/Which-language-has-the-brightest-futur...

Re: Why asynchronous Rust doesn't work

#230

Earlier quoted context omitted.

In all this time, maestro Andrei Alexandrescu was right when he said Rust feels like it "skipped leg day" when it comes to concurrency and metaprogramming capabilities. Tim Sweeney was complaining about similar things, saying about Rust that is one step forward, one step backward. These problems will be evident at a later time, when it will be already too late. I will continue experimenting with Rust, but Zig seems t…

In case anyone else was interested in the original sources for the quotes: > Andrei Alexandrescu was right when he said Rust feels like it "skipped leg day" when it comes to concurrency and metaprogramming capabilities. https://archive.is/hbBte (the original answer appears to have been deleted [0]) > Tim Sweeney was complaining about similar things, saying about Rust that is one step forward, two steps backward. http…

Thanks for the references, indeed, Tim said one step forward, one backward, my bad. He posted long time ago.
Post reply on HN