Hacker News Reader

Comment by gwbas1c | Hacker News Reader

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.

View on HN

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.

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

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

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

We already have too much code that "can be made safe later", but never is.

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.

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.

Yup, I don't understand why people downvoted you.

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.

Reply on news.ycombinator.com