4 ms·

This is pretty overblown. I write async rust every day for my job, just fine, with no real problems. Probably because I'm consuming other libraries, I'm not try

by adamch 6y ago

This is pretty overblown. I write async rust every day for my job, just fine, with no real problems. Probably because I'm consuming other libraries, I'm not trying to write my own. I use well-tested libraries like Actix-Web or occasionally Tokio. I've migrated multiple projects from futures to async/await once the syntax came out. ' The problems the author is describing might apply more to library authors, but for the many Rust programmers like me who are trying to solve problems, not write a framework, async is easy and practical.

scoutt 6y ago
> The problems the author is describing might apply more to library authors I don't know much about Rust, but I found the examples in the article kind of simple. As far as I can see, the author is trying to spawn a new thread and share an object between the main thread and the new one. It's seems like an everyday paradigm. Perhaps the problems arise when passing complex objects instead of native types (i.e. u32).
- littlestymaar 6y ago
  > As far as I can see, the author is trying to spawn a new thread and share an object between the main thread and the new one. It's seems like an everyday paradigm. And it works very well in Rust as long as you understand the core concept of the language (ownership). Rust is special, it has this fundamental concept that you need to understand before going on, and that's add some inevitable learning curve. But once you know how it works, it just works exactly as you'd expect and in the kinds of things the author is trying to do[1], it doesn't gets in your way at all. The post just sounds like the author didn't took the time to understand the core concepts, and is trying to brute-force their way through. This way of learning doesn't work very well for Rust, or at least not if you are impatient. (Especially because the error messages when it comes to closures are still far from Rust's overall standards). [1] there are things where Rust's ownership is a constraint (cyclic datastrutures for instance, or shared memory between your program and a C program (io_uring, or wayland)). But those are situational.
  - scoutt 6y ago
    I have no doubt that it works well in Rust (with its core concepts and caveats). I was really referring to the parent comment which said that the author of the article seems to be complaining about something that applies only to a specific area ("The problems the author is describing might apply more to library authors"). I said that to me, the examples in the article seemed more like an everyday paradigm (mundane, creating a thread and sharing an object).
- adamch 6y ago
  My job isn't to write a program that shares objects between threads. My job is to write a program that responds to web requests or stores user data or responds to queries or checks the state of certain services. In some languages and frameworks, I might need to share an object between threads to do this efficiently. In Rust there are other options, e.g. using Arc or a reference or moving the object into a task. In my years of programming Rust I've never wanted to share some object on a thread, because there are frameworks and libraries (Actix-Web, Tokio, Rayon, async-std, others) that give me a higher-level abstraction for doing this. I can understand using this as a point of comparison if you're not very familiar with the language. But I have to confess that in my three years of working with Rust, I've neer had to worry about threads. I've been able to use a library to solve my concurrency or parallelism problems so that I can go back to worrying about design or reliability concerns. This won't be everyone's perspective, after all, someone has to write those libraries. But it is mine, and I think users of such libraries far outnumber authors of such libraries.
__s 6y ago
Agreed, I rewrote a 10k line a js websocket based game server[0] a few months ago into async Rust. It was mostly painless I didn't have to deal with closures much because I'm comfortable writing a 2000 line match 0: https://github.com/serprex/openEtG/tree/master/src/rs/server https://github.com/serprex/openEtG/tree/master/src/rs/server
- adamch 6y ago
  Wow, awesome code. I really respect the 2000 line match, it's a really neat abstraction. Keep some state, have an exhaustive list of everything users can do, and define exactly how each possible user action can change that state. Beautiful.

by adamch 6y ago

scoutt 6y ago

> The problems the author is describing might apply more to library authors I don't know much about Rust, but I found the examples in the article kind of simple. As far as I can see, the author is trying to spawn a new thread and share an object between the main thread and the new one. It's seems like an everyday paradigm. Perhaps the problems arise when passing complex objects instead of native types (i.e. u32).

littlestymaar 6y ago
> As far as I can see, the author is trying to spawn a new thread and share an object between the main thread and the new one. It's seems like an everyday paradigm. And it works very well in Rust as long as you understand the core concept of the language (ownership). Rust is special, it has this fundamental concept that you need to understand before going on, and that's add some inevitable learning curve. But once you know how it works, it just works exactly as you'd expect and in the kinds of things the author is trying to do[1], it doesn't gets in your way at all. The post just sounds like the author didn't took the time to understand the core concepts, and is trying to brute-force their way through. This way of learning doesn't work very well for Rust, or at least not if you are impatient. (Especially because the error messages when it comes to closures are still far from Rust's overall standards). [1] there are things where Rust's ownership is a constraint (cyclic datastrutures for instance, or shared memory between your program and a C program (io_uring, or wayland)). But those are situational.
- scoutt 6y ago
  I have no doubt that it works well in Rust (with its core concepts and caveats). I was really referring to the parent comment which said that the author of the article seems to be complaining about something that applies only to a specific area ("The problems the author is describing might apply more to library authors"). I said that to me, the examples in the article seemed more like an everyday paradigm (mundane, creating a thread and sharing an object).
adamch 6y ago
My job isn't to write a program that shares objects between threads. My job is to write a program that responds to web requests or stores user data or responds to queries or checks the state of certain services. In some languages and frameworks, I might need to share an object between threads to do this efficiently. In Rust there are other options, e.g. using Arc or a reference or moving the object into a task. In my years of programming Rust I've never wanted to share some object on a thread, because there are frameworks and libraries (Actix-Web, Tokio, Rayon, async-std, others) that give me a higher-level abstraction for doing this. I can understand using this as a point of comparison if you're not very familiar with the language. But I have to confess that in my three years of working with Rust, I've neer had to worry about threads. I've been able to use a library to solve my concurrency or parallelism problems so that I can go back to worrying about design or reliability concerns. This won't be everyone's perspective, after all, someone has to write those libraries. But it is mine, and I think users of such libraries far outnumber authors of such libraries.

__s 6y ago

Agreed, I rewrote a 10k line a js websocket based game server[0] a few months ago into async Rust. It was mostly painless I didn't have to deal with closures much because I'm comfortable writing a 2000 line match 0: https://github.com/serprex/openEtG/tree/master/src/rs/server https://github.com/serprex/openEtG/tree/master/src/rs/server

adamch 6y ago
Wow, awesome code. I really respect the 2000 line match, it's a really neat abstraction. Keep some state, have an exhaustive list of everything users can do, and define exactly how each possible user action can change that state. Beautiful.