Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why asynchronous Rust doesn't work

theta.eu.org

Post reply on HN
Print view View original

31–40 of 499 posts

Re: Why asynchronous Rust doesn't work

#31

Post by de6u99er »

ironmagma wrote: post #8

> The thing I really want to try and get across here is that *Rust is not a language where first-class functions are ergonomic.* So... don’t use first-class functions so much? It’s a systems language, not a functional language for describing algorithms in CS whitepapers. Or use `move` (the article does mention this). There are easy paths in most programming languages, and harder paths. Rust is no exception. The fact…

Wanted to write something similar, just not as elaborate as you did (native German speaker here).

Another good example is Java, and languages running on top of the JVM.

Re: Why asynchronous Rust doesn't work

#33

Post by [deleted] »

lmm wrote: post #13

Async isn't really the problem - the same issue pops up with error handling, with resource management, with anything where you want to pass functions around. The real problem is that Rust's ownership semantics and limited abstractions mean it doesn't really have first-class functions: there are three different function types and the language lacks the power to abstract over them, so you can't generally take an expres…

[deleted]

Re: Why asynchronous Rust doesn't work

#34

Post by Animats »

justicezyx wrote: post #5
socialdemocrat wrote: post #3

Earlier quoted context omitted.

Isn’t the Go solution green threads on top of hardware threads? Lots of green threads get load balanced on top of a thread pool. Isn’t that the whole unique aspect of Go? So in essence they do both.

I think the idea is that they do not present as competing paradigms. Go green threads or go routine are the only visible constructs to users. Whereas the hardware threads are not usable to users. Edit: From the perspective of mutli-paradigm, C++ is truely a unique language. It not only has multiple paradigms, and largely contains them in a relatively harmony state.

Right. The key point being that in Go, you can block or use some compute time without stalling out the async system.

Re: Why asynchronous Rust doesn't work

#35

Post by hctaw »

lmm wrote: post #13

Async isn't really the problem - the same issue pops up with error handling, with resource management, with anything where you want to pass functions around. The real problem is that Rust's ownership semantics and limited abstractions mean it doesn't really have first-class functions: there are three different function types and the language lacks the power to abstract over them, so you can't generally take an expres…

Nit, you can already abstract over lifetimes. But I really agree with the HKT comment, in principle. In practice it's not so bad. Abstracting over async, mutability, and borrows would be more important to smooth over a few of these issues (there are ways around both, but it's not always obvious).

Most of these issues arise for library authors. I think a lot of folks in the ecosystem today are writing libraries instead of applications, which is why we get these blog posts lamenting the lack of HKTs or difficult syntax for doing difficult things that other languages hide from you. I don't think users have the same experience when building things with the libraries.

That said, there's a bit of leakage of complexity. Sometimes it's really hard to write a convenient API (like abstracting over closures) and that leads to gnarly errors for users of those APIs. Closures are particularly bad about this (which some, including myself, would say is good and also easy to work around), and there's always room for improvement. I don't think a lack of HKTs is really holding anything essential back right now.

Re: Why asynchronous Rust doesn't work

#36

Post by xiphias2 »

_zhqs wrote: post #28
xiphias2 wrote: 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.

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

Re: Why asynchronous Rust doesn't work

#37

Post by newpavlov »

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 made on the ground of "we want to ship async support as soon as possible" [1]. Unfortunately, because of this rush, Rust got stuck with a poll-based model with a whole bunch of problems without a clear solution in sight (async drop anyone?). And instead of a proper solution for self-referencing structs (yes, a really hard problem), we did end up with the hack-ish Pin solution, which has already caused a number of problems since stabilization and now may block enabling of noalias by default [2].

Many believe that Rust async story was unnecessarily rushed. While it may have helped to increase Rust adoption in the mid term, I believe it will cause serious issues in the longer term.

[1]: https://github.com/rust-lang/rust/issues/62149#issuecomment-... [2]: https://github.com/rust-lang/rust/issues/63818

Re: Why asynchronous Rust doesn't work

#38

Post by redis_mlc »

_zhqs wrote: post #28
xiphias2 wrote: 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.

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

Everything is "mismatched types" in Rust, literally it doesn't do any automatic type conversion (casting), so it's not the right language for most people.

Re: Why asynchronous Rust doesn't work

#39

Post by noncoml »

> And, as I said at the start, that makes me kinda sad, because I do actually like Rust.

I think that’s the most important part of the article. People like Rust but it’s becoming more complex than C++. But unlike C++ it’s more difficult to pick and choose what you use.

Rust’s death will be one by thousand cuts. “I really like the language but can’t justify all that complexity in my new small and simpke project” is what will cause the popularity to drop.

Re: Why asynchronous Rust doesn't work

#40

Post by literallyWTF »

xiphias2 wrote: post #36
_zhqs wrote: 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.

Yeah I don’t get it either. We’re supposed to be upset that it did it’s job? Lol?
Post reply on HN