4 ms·

For a few months while I was between jobs, I decided to learn Rust. Because async code is supposed to be better than threaded code, I spent all my time trying t

For a few months while I was between jobs, I decided to learn Rust. Because async code is supposed to be better than threaded code, I spent all my time trying to write async Rust. Big mistake! I never accomplished what I set out to accomplish. Most of my experience is in C#, where the difference between async and threaded code is mostly syntax sugar. (Until you get into the details.) (And async code makes writing UI code much cleaner.) Trying to write async Rust as a novice is downright hostile. The tradeoff of threads makes async code such that it's only worth it if your Rust process will have highly concurrent load; as opposed to C# where refactoring threaded code to async is housekeeping.

sudeepj 6y ago
I am guessing you are a point D/D' in the diagram [1] Although the diagram is for the Rust overall, I think something similar is true for async Rust. All I would say is hang in there. It gets better (from my experience). Rust is not something you can code along as you think. There is a bit a of upfront thinking what the data-structures & data-flow look like. At present, I can know in advance without writing code whether implementation I am thinking in Rust will work or not (work => satisfy Rust compiler) [1] https://imgur.com/kNkV7jm https://imgur.com/kNkV7jm
- orthoxerox 6y ago
  > Rust is not something you can code along as you think. This is my biggest gripe with Rust. I want to write code that produces the right result first and make it safe later.
  - majewsky 6y ago
    We already have too much code that "can be made safe later", but never is.
  - carols10cents 6y ago
    If you're interested in continuing with Rust, I'd suggest that you think about making code that produces the right result first and make it fast later: use `clone` everywhere you run into borrowing problems, use `Rc` or `Arc` instead of references everywhere you run into ownership problems, make the single threaded version work before adding concurrency, etc.
ordu 6y ago
You had chosen the really hard way to learn Rust. The most of problems for a beginner comes from lifetimes and borrowing. Async code by itself is harder topic when it comes to lifetimes and borrowing. When you use object in a concurrent manner, then you need to have two or more references to it, who would own object? When object has his owner, object lives. When object lost his owner, object dropped. Someone must own it. And borrow-checker need to have a way to prove, that owner will live longer than every one of your threads using this object, otherwise borrow-checker would start to complain and refuse to compile your code. If you are trying to get mutable access to object how you are going to ensure that it would be done in a safe manner without data races? How are you going to explain borrow-checker that it is a safe way? I'm trying to say, that mostly you problems was lifetimes and borrowing, like with other beginners, but problems were magnified to a level when beginner have no chances to make it work.
- gwbas1c 6y ago
  And the problem with async in Rust is that it's really hard to prove a single owner across the await gap. In the other languages where I used async, Javascript and C#, there is no penalty for using a variable across the async gap. The async keyword just means that something will block. (And plenty of other details, like your UI can paint itself.)
xiphias2 6y ago
The problem you were trying to solve (safe system level multi-threaded programming) is really really hard, and actually Rust makes it easier. If you enjoy it, learn it and have fun doing high performance work at your new job. If you’re not passionate about it, it’s OK, there are lots of work in other domains.
ragnese 6y ago
I sympathize. As I said in another comment, the issue isn't really caused by async, IMO. It's caused by the complicated and leaky abstraction of traits. I'd be willing to bet that your difficulties were more around dealing with the interactions of async + traits than if you had just written a bunch of async functions and then ran them inside an async main (via tokio's tokio::main attribute). Just a guess.
- gwbas1c 6y ago
  Yup, I don't understand why people downvoted you.

sudeepj 6y ago

I am guessing you are a point D/D' in the diagram [1] Although the diagram is for the Rust overall, I think something similar is true for async Rust. All I would say is hang in there. It gets better (from my experience). Rust is not something you can code along as you think. There is a bit a of upfront thinking what the data-structures & data-flow look like. At present, I can know in advance without writing code whether implementation I am thinking in Rust will work or not (work => satisfy Rust compiler) [1] https://imgur.com/kNkV7jm https://imgur.com/kNkV7jm

orthoxerox 6y ago
> Rust is not something you can code along as you think. This is my biggest gripe with Rust. I want to write code that produces the right result first and make it safe later.
- majewsky 6y ago
  We already have too much code that "can be made safe later", but never is.
- carols10cents 6y ago
  If you're interested in continuing with Rust, I'd suggest that you think about making code that produces the right result first and make it fast later: use `clone` everywhere you run into borrowing problems, use `Rc` or `Arc` instead of references everywhere you run into ownership problems, make the single threaded version work before adding concurrency, etc.

ordu 6y ago

You had chosen the really hard way to learn Rust. The most of problems for a beginner comes from lifetimes and borrowing. Async code by itself is harder topic when it comes to lifetimes and borrowing. When you use object in a concurrent manner, then you need to have two or more references to it, who would own object? When object has his owner, object lives. When object lost his owner, object dropped. Someone must own it. And borrow-checker need to have a way to prove, that owner will live longer than every one of your threads using this object, otherwise borrow-checker would start to complain and refuse to compile your code. If you are trying to get mutable access to object how you are going to ensure that it would be done in a safe manner without data races? How are you going to explain borrow-checker that it is a safe way? I'm trying to say, that mostly you problems was lifetimes and borrowing, like with other beginners, but problems were magnified to a level when beginner have no chances to make it work.

gwbas1c 6y ago
And the problem with async in Rust is that it's really hard to prove a single owner across the await gap. In the other languages where I used async, Javascript and C#, there is no penalty for using a variable across the async gap. The async keyword just means that something will block. (And plenty of other details, like your UI can paint itself.)

xiphias2 6y ago

The problem you were trying to solve (safe system level multi-threaded programming) is really really hard, and actually Rust makes it easier. If you enjoy it, learn it and have fun doing high performance work at your new job. If you’re not passionate about it, it’s OK, there are lots of work in other domains.

ragnese 6y ago

I sympathize. As I said in another comment, the issue isn't really caused by async, IMO. It's caused by the complicated and leaky abstraction of traits. I'd be willing to bet that your difficulties were more around dealing with the interactions of async + traits than if you had just written a bunch of async functions and then ran them inside an async main (via tokio's tokio::main attribute). Just a guess.

gwbas1c 6y ago
Yup, I don't understand why people downvoted you.