6 ms·

My only experience with Rust has been synchronous mostly with little to show for in terms of async. And I liked Rust. When it ran, I was damn sure it was going

by keyle 2y ago

My only experience with Rust has been synchronous mostly with little to show for in terms of async. And I liked Rust. When it ran, I was damn sure it was going to run. There is comfort in that: "Tell me what to fix". The clippy stuff etc. was great too. I read the 3 parts of this website and 'Wowsa'... I'm definitely not going in that direction with Rust. I'll stick to dumb Go code, Swift or Python if I do async heavy stuff. It's hard enough to write good code, I don't see the point of finding walls to smash my head into. Think about it, if you write a lot of async code, chances are you have a ton of latency, waiting on I/O, disk, network etc. Using Rust for this in the first place isn't the wisest since performance isn't as important, most of your performance is wasted 'waiting' on things. Besides Rust wants purity and I/O is gritty little dirt. Sorry my comment turned into a bit of a hot take, feel free to disagree. This async stuff, doesn't look fun at all.

worik 2y ago
> My only experience with Rust has been synchronous It is a shame that the dominance of the "async/await" paradigm has made us think in terms of "synchronous" or "async/await" > Think about it, if you write a lot of async code, chances are you have a ton of latency, waiting on I/O, disk, network etc Yes. For almost all code anyone writes blocking code and threads are perfectly OK Asynchronous programming is more trouble, but if trying to deal with a lot of access to those high latency resources asynchronous code really shines. The trouble is that "async/await" is a really bad fit for rust. Every time you say `await` you start invisible magic happening. (A state machine starts spinning I believe in Rust - I may be mistaken) "No invisible magic" was a promise that Rust made to us. What you say is what you mean, and what you mean is what you get. No more, if you use async/await Rust I really do not understand why people who are comfortable with "invisible magic" are not using a language with a garbage collector - that *really* useful invisible magic. Asynchronous programming is the bees knees. It lets you get so much more from your hardware. I learnt to do it implementing telephone switching systems on MS-DOS. We could run seven telephone lines on a 486, with DOS, in (?) about 1991. Async/await has so poisoned the well in Rust that many Rust people do not understand there is more to asynchronous programming than that
- the__alchemist 2y ago
  I notice this as well; there is a false dichotomy of "Async/Await" or "blocking". I see this in embedded too. I think a lot of rust embedded programmers learned on Embassy, and to them, not using Async means blocking.
  - omani 2y ago
    can you elaborate on this?
    - the__alchemist 2y ago
      Writing programs that perform multiple tasks asynchronously can be done in many ways. It is a broad and important tool in software, and the Async/Await language is only one way to do it. Examples: - Multiple cores - DMA or other dedicated hardware - GPU programming - Distributed systems (e.g. the CAN network in your car) - Threads - Interrupts - Event loops - Coroutines
  - zavec 2y ago
    Is the alternative the more traditional spawning threads and using channels, or is there another paradigm? That's definitely something I'd be interested in learning more about.
    - onjectic 2y ago
      I think they mean that there is more than one asynchronous paradigm. Actors is one alternative I can think of.
      - palata 2y ago
        Where an actor has its own thread and communicates with a channel, right?
        pdimitar 2y ago
mplanchard 2y ago
Having written a lot of asynchronous code in python and in rust, I’d take Rust any day. If it compiles, it works. I also don’t think it’s hard to reason about in practice. Tutorials tend to get much deeper into the weeds than you typically need to go.
- gpderetta 2y ago
  asyncio is its own special kind of hell. I understand there are significantly better async libraries for python, but being built-in it is what you end up reaching to.
  - palata 2y ago
    What is bad with asyncio? Genuinely interested.
    - gpderetta 2y ago
      From the top of my head: lack of structured consistency, error prone , atrocious stack traces, and (and this might be a skill issue on my part) confusing task cancel semantics.
- pdimitar 2y ago
  Maybe Rust has improved in the last 13-14 months but last time I needed to do a lot of async code I ended up with a browser session with at least 12 crates on docs.rs where only a small part of the picture was explained. It was absolutely terrible to track down what's the problem. In the end, very helpful (and hardcore -- like the main author of Tokio) people unblocked me. I am not sure I was left very enlightened though; but I likely didn't stay for long enough for the whole thing to stick firmly into my memory. It's likely that.
  - mplanchard 2y ago
    It has improved a lot, yes. impl in return position in traits makes writing async traits much, much easier, as you can avoid a large number of Boxing and lifetime issues when you don't need a trait object (which is what the async_trait crate does under the hood). I also think you've really got to be willing to be pragmatic when writing async code. If you like to do functional chains, you've got to be willing to let go of that and go for simple imperative code with match statements. Where I find it gets complicated is dealing with streams and stuff, but for most application authoring use-cases, you can just await stuff that other people have written, or throw it into a `join_all` or whatever.
pkolaczk 2y ago
Performance is not only wall clock time. With high latency, I/O bound tasks, the cost will be often determined by how much memory you need. And in the cloud, you can’t pay for memory alone. The more memory you need, the more vcores you have to reserve. You might end up in a situation your cpus are mostly idling, but you can’t use fewer cores because of RAM needed to keep the state of thousands of concurrent sessions. In this case Rust async can bring a tremendous advantage over other languages, particularly Java and Go.
- palata 2y ago
  > you can’t use fewer cores because of RAM needed to keep the state of thousands of concurrent sessions. In this case Rust async can bring a tremendous advantage over other languages, particularly Java and Go. Can you elaborate on that? What about green threads?
  - vlovich123 2y ago
    Green threads can use more memory than async if you have a lot of I/O operations in flight since the stack is not precisely sized at pause points. Similarly, switching in new stacks is a bit more expensive than continuing a paused async task. Implementation details matter of course.
    - palata 2y ago
      Right, that's interesting. Still curious to know if that is "slightly better" or if that qualifies for the "tremendous advantage" mentioned above!
      - vlovich123 2y ago
        It’s hard to say. If you want to use green threads, you may want to look at the may crate [1]. The reason Rust prioritized stackless async just like C++ did is that it fits better the systems programming needs (i.e. it’s syntactic sugar for a state machine you could hand implement) while not preventing things like stackful coroutines. If Rust manages to solve the coloring problem of async (e.g. by adopting effect systems [2] or alternatives), then stackful and stackless coroutines syntactic sugar could conceivably exist within the std language (perhaps leaving out stackless on nostd). The reason you don’t see both stackless and stackful coroutines in a single language like Rust is the coloring problem is made 50% worse. [1] https://crates.io/crates/may https://crates.io/crates/may [2] https://blog.yoshuawuyts.com/extending-rusts-effect-system/ https://blog.yoshuawuyts.com/extending-rusts-effect-system/
tcfhgj 2y ago
Performance isn't wasted. More waiting and less CPU time also means longer battery life / energy efficiency.
DeathArrow 2y ago
>Think about it, if you write a lot of async code, chances are you have a ton of latency, waiting on I/O, disk, network etc. Using Rust for this in the first place isn't the wisest since performance isn't as important, most of your performance is wasted 'waiting' on things. Besides Rust wants purity and I/O is gritty little dirt. But isn't most code going to perform some I/O at some time? Whether is calling an API, writing on disk or writing to a DB?
pdimitar 2y ago
I am mostly in agreement -- I moved to Golang for not-super-complex async programs because I value my time and day-to-day productivity more than the super strictness of Rust (which I love and I wish more languages had it, though in a more approachable manner). Rust was a legendary pain to untangle when learning to do async, though as I admitted in a comment down-thread this was also because I didn't stay for long enough for everything to cement itself in my head. It was still an absolute hell to get into. I needed help from Tokio's author to have some pieces of code even compile because I couldn't for the life of me understand why they didn't. ...BUT, with that being said, Rust has a much smaller memory footprint and that is an actual and measurable advantage on cloud deployments. It could be painful to make it compile and run but then it'll give you your money's worth and then some. So it's worth even only for that (and "that" is a lot!), if you are optimizing for those values. I plan to do that in the future. In the meantime Golang is an amazing compromise between productivity and machine performance.

by keyle 2y ago

worik 2y ago

> My only experience with Rust has been synchronous It is a shame that the dominance of the "async/await" paradigm has made us think in terms of "synchronous" or "async/await" > Think about it, if you write a lot of async code, chances are you have a ton of latency, waiting on I/O, disk, network etc Yes. For almost all code anyone writes blocking code and threads are perfectly OK Asynchronous programming is more trouble, but if trying to deal with a lot of access to those high latency resources asynchronous code really shines. The trouble is that "async/await" is a really bad fit for rust. Every time you say `await` you start invisible magic happening. (A state machine starts spinning I believe in Rust - I may be mistaken) "No invisible magic" was a promise that Rust made to us. What you say is what you mean, and what you mean is what you get. No more, if you use async/await Rust I really do not understand why people who are comfortable with "invisible magic" are not using a language with a garbage collector - that *really* useful invisible magic. Asynchronous programming is the bees knees. It lets you get so much more from your hardware. I learnt to do it implementing telephone switching systems on MS-DOS. We could run seven telephone lines on a 486, with DOS, in (?) about 1991. Async/await has so poisoned the well in Rust that many Rust people do not understand there is more to asynchronous programming than that

the__alchemist 2y ago
I notice this as well; there is a false dichotomy of "Async/Await" or "blocking". I see this in embedded too. I think a lot of rust embedded programmers learned on Embassy, and to them, not using Async means blocking.
- omani 2y ago
  can you elaborate on this?
  - the__alchemist 2y ago
    Writing programs that perform multiple tasks asynchronously can be done in many ways. It is a broad and important tool in software, and the Async/Await language is only one way to do it. Examples: - Multiple cores - DMA or other dedicated hardware - GPU programming - Distributed systems (e.g. the CAN network in your car) - Threads - Interrupts - Event loops - Coroutines
- zavec 2y ago
  Is the alternative the more traditional spawning threads and using channels, or is there another paradigm? That's definitely something I'd be interested in learning more about.
  - onjectic 2y ago
    I think they mean that there is more than one asynchronous paradigm. Actors is one alternative I can think of.
    - palata 2y ago
      Where an actor has its own thread and communicates with a channel, right?
      - pdimitar 2y ago

mplanchard 2y ago

Having written a lot of asynchronous code in python and in rust, I’d take Rust any day. If it compiles, it works. I also don’t think it’s hard to reason about in practice. Tutorials tend to get much deeper into the weeds than you typically need to go.

gpderetta 2y ago
asyncio is its own special kind of hell. I understand there are significantly better async libraries for python, but being built-in it is what you end up reaching to.
- palata 2y ago
  What is bad with asyncio? Genuinely interested.
  - gpderetta 2y ago
    From the top of my head: lack of structured consistency, error prone , atrocious stack traces, and (and this might be a skill issue on my part) confusing task cancel semantics.
pdimitar 2y ago
Maybe Rust has improved in the last 13-14 months but last time I needed to do a lot of async code I ended up with a browser session with at least 12 crates on docs.rs where only a small part of the picture was explained. It was absolutely terrible to track down what's the problem. In the end, very helpful (and hardcore -- like the main author of Tokio) people unblocked me. I am not sure I was left very enlightened though; but I likely didn't stay for long enough for the whole thing to stick firmly into my memory. It's likely that.
- mplanchard 2y ago
  It has improved a lot, yes. impl in return position in traits makes writing async traits much, much easier, as you can avoid a large number of Boxing and lifetime issues when you don't need a trait object (which is what the async_trait crate does under the hood). I also think you've really got to be willing to be pragmatic when writing async code. If you like to do functional chains, you've got to be willing to let go of that and go for simple imperative code with match statements. Where I find it gets complicated is dealing with streams and stuff, but for most application authoring use-cases, you can just await stuff that other people have written, or throw it into a `join_all` or whatever.

pkolaczk 2y ago

Performance is not only wall clock time. With high latency, I/O bound tasks, the cost will be often determined by how much memory you need. And in the cloud, you can’t pay for memory alone. The more memory you need, the more vcores you have to reserve. You might end up in a situation your cpus are mostly idling, but you can’t use fewer cores because of RAM needed to keep the state of thousands of concurrent sessions. In this case Rust async can bring a tremendous advantage over other languages, particularly Java and Go.

palata 2y ago
> you can’t use fewer cores because of RAM needed to keep the state of thousands of concurrent sessions. In this case Rust async can bring a tremendous advantage over other languages, particularly Java and Go. Can you elaborate on that? What about green threads?
- vlovich123 2y ago
  Green threads can use more memory than async if you have a lot of I/O operations in flight since the stack is not precisely sized at pause points. Similarly, switching in new stacks is a bit more expensive than continuing a paused async task. Implementation details matter of course.
  - palata 2y ago
    Right, that's interesting. Still curious to know if that is "slightly better" or if that qualifies for the "tremendous advantage" mentioned above!
    - vlovich123 2y ago
      It’s hard to say. If you want to use green threads, you may want to look at the may crate [1]. The reason Rust prioritized stackless async just like C++ did is that it fits better the systems programming needs (i.e. it’s syntactic sugar for a state machine you could hand implement) while not preventing things like stackful coroutines. If Rust manages to solve the coloring problem of async (e.g. by adopting effect systems [2] or alternatives), then stackful and stackless coroutines syntactic sugar could conceivably exist within the std language (perhaps leaving out stackless on nostd). The reason you don’t see both stackless and stackful coroutines in a single language like Rust is the coloring problem is made 50% worse. [1] https://crates.io/crates/may https://crates.io/crates/may [2] https://blog.yoshuawuyts.com/extending-rusts-effect-system/ https://blog.yoshuawuyts.com/extending-rusts-effect-system/

tcfhgj 2y ago

Performance isn't wasted. More waiting and less CPU time also means longer battery life / energy efficiency.

DeathArrow 2y ago

>Think about it, if you write a lot of async code, chances are you have a ton of latency, waiting on I/O, disk, network etc. Using Rust for this in the first place isn't the wisest since performance isn't as important, most of your performance is wasted 'waiting' on things. Besides Rust wants purity and I/O is gritty little dirt. But isn't most code going to perform some I/O at some time? Whether is calling an API, writing on disk or writing to a DB?

pdimitar 2y ago

I am mostly in agreement -- I moved to Golang for not-super-complex async programs because I value my time and day-to-day productivity more than the super strictness of Rust (which I love and I wish more languages had it, though in a more approachable manner). Rust was a legendary pain to untangle when learning to do async, though as I admitted in a comment down-thread this was also because I didn't stay for long enough for everything to cement itself in my head. It was still an absolute hell to get into. I needed help from Tokio's author to have some pieces of code even compile because I couldn't for the life of me understand why they didn't. ...BUT, with that being said, Rust has a much smaller memory footprint and that is an actual and measurable advantage on cloud deployments. It could be painful to make it compile and run but then it'll give you your money's worth and then some. So it's worth even only for that (and "that" is a lot!), if you are optimizing for those values. I plan to do that in the future. In the meantime Golang is an amazing compromise between productivity and machine performance.