A four year plan for async Rust
without.boats
A four year plan for async Rust
1–10 of 236 posts
Re: A four year plan for async Rust
#2Async is a huge wart and I try and avoid it wherever possible. It's simply not useful in a lot of cases that I encounter. However, if a library uses async, you have little choice but to make your whole project async. This adds to its horrible reputation.
Re: A four year plan for async Rust
#3Async is a huge wart and I try and avoid it wherever possible. It's simply not useful in a lot of cases that I encounter. However, if a library uses async, you have little choice but to make your whole project async. This adds to its horrible reputation.
I'm with you. I feel like an outcast in the Rust OSS embedded circles when I bring this up. They are heavily into async/embassy.
Re: A four year plan for async Rust
#4Async is a huge wart and I try and avoid it wherever possible. It's simply not useful in a lot of cases that I encounter. However, if a library uses async, you have little choice but to make your whole project async. This adds to its horrible reputation.
> However, if a library uses async, you have little choice but to make your whole project async. This adds to its horrible reputation.
No.
This is how yo do: you look what executor your dependency is using (most likely tokio) you add it to your cargo.toml (at zero cost, since it's already there in your dep) and then you wrap the async library calls in `block_on` and call it a day. You don't need to change a single other line in your project.
Re: A four year plan for async Rust
#5Async is a huge wart and I try and avoid it wherever possible. It's simply not useful in a lot of cases that I encounter. However, if a library uses async, you have little choice but to make your whole project async. This adds to its horrible reputation.
What on earth are you talking about? Async is amazing. Super fast servers in Actix with multiple DB connectors performing simultaneous queries is super easy to set up.
So many people complain about Rust being hard. What on earth are you people on about? This isn't at all a hard language.
I'm so sick of this "async is hard" / "Rust is hard" meme. No, it isn't.
Maybe it's inconvenient if you're used to slapping packages together and calling it a day. But I don't think the majority of us do work like that.
And it's not hard.
Re: A four year plan for async Rust
#6[deleted]
Re: A four year plan for async Rust
#7Async is a huge wart and I try and avoid it wherever possible. It's simply not useful in a lot of cases that I encounter. However, if a library uses async, you have little choice but to make your whole project async. This adds to its horrible reputation.
> However, if a library uses async, you have little choice but to make your whole project async. This adds to its horrible reputation. No. This is how yo do: you look what executor your dependency is using (most likely tokio) you add it to your cargo.toml (at zero cost, since it's already there in your dep) and then you wrap the async library calls in `block_on` and call it a day. You don't need to change a single ot…
Another viable strategy is to start a single-threaded tokio executor and treat it like another thread that you communicate with over (flume) channels.
Re: A four year plan for async Rust
#8Earlier quoted context omitted.
> However, if a library uses async, you have little choice but to make your whole project async. This adds to its horrible reputation. No. This is how yo do: you look what executor your dependency is using (most likely tokio) you add it to your cargo.toml (at zero cost, since it's already there in your dep) and then you wrap the async library calls in `block_on` and call it a day. You don't need to change a single ot…
Another viable strategy is to start a single-threaded tokio executor and treat it like another thread that you communicate with over (flume) channels.
Yes this works too. People complaining about async being contaminant are often so much prejudiced against it that that haven't even tried to understand the basics.
Re: A four year plan for async Rust
#9Async is a huge wart and I try and avoid it wherever possible. It's simply not useful in a lot of cases that I encounter. However, if a library uses async, you have little choice but to make your whole project async. This adds to its horrible reputation.
> However, if a library uses async, you have little choice but to make your whole project async. This adds to its horrible reputation. No. This is how yo do: you look what executor your dependency is using (most likely tokio) you add it to your cargo.toml (at zero cost, since it's already there in your dep) and then you wrap the async library calls in `block_on` and call it a day. You don't need to change a single ot…
You breeze over the dependency weight by abusing "zero cost" to mean "sunk cost". They're not the same!
Re: A four year plan for async Rust
#10Async is a huge wart and I try and avoid it wherever possible. It's simply not useful in a lot of cases that I encounter. However, if a library uses async, you have little choice but to make your whole project async. This adds to its horrible reputation.
What on earth are you talking about? Async is amazing. Super fast servers in Actix with multiple DB connectors performing simultaneous queries is super easy to set up. So many people complain about Rust being hard. What on earth are you people on about? This isn't at all a hard language. I'm so sick of this "async is hard" / "Rust is hard" meme. No, it isn't. Maybe it's inconvenient if you're used to slapping package…
The point can be made equally well without the elitist condescension.