7 ms·

Rust has had an interesting and probably pretty unique story, moving from a GC’d language with a runtime + green threads[1] to what it is today. They are tread

by orf 3y ago

Rust has had an interesting and probably pretty unique story, moving from a GC’d language with a runtime + green threads[1] to what it is today. They are treading a line that is uniquely difficult to tread, and I think it’s mostly working. Async is still a bit of a mess but it seems that’s because it’s inherent to the constraints they had to impose on themselves. It’s kind of cool that I can use Async stuff in embedded devices[1] and a web app, even if I do get frustrated with mind-numbing Async issues from time to time. 1. https://github.com/rust-lang/rfcs/pull/230 https://github.com/rust-lang/rfcs/pull/230 2. https://embassy.dev/ https://embassy.dev/

rcarr 3y ago
For anyone interested there was a big discussion on async in rust a few days ago. Rust is on todo list to learn but I found reading some of these comments quite interesting: https://news.ycombinator.com/item?id=37435515 https://news.ycombinator.com/item?id=37435515
- mplanchard 3y ago
  Note also this rebuttal: https://news.ycombinator.com/item?id=37448460 https://news.ycombinator.com/item?id=37448460 As someone who works with async rust professionally, I wouldn’t let takes like the one you posted dissuade you. My personal opinion is that async rust is easier to work with than in most other languages because of the extra concurrency guarantees that rust gives you. There are some rough edges, but not nearly as many as the link you posted suggests.
  - littlestymaar 3y ago
    This exactly. Sure Async Rust requires you to learn a few new things, but the blog post is mostly a rant from someone not very familiar with the topic (like what you'd expect from something called “<X> is a bad language” TBH).
  - rcarr 3y ago
    I wasn't, I actually didn't even read the attached article only the HN comments who seemed to mainly disagree with the article and mentioned quite a lot about the different approaches to async in Rust. I really want to learn it but prioritising up-skilling my DevOps capabilities at the minute so it will have to be next year.
    - mplanchard 3y ago
      Glad to hear it! I am ~2.5 years into my professional Rust career, ~4.5 years into working with the language, and it's still my favorite. It's certainly not the only great language out there, but it's definitely one of them.
masklinn 3y ago
> moving from a GC’d language Rust was never actually a GC’d language. It had a smart pointer called Gc (and before that @), but that was only ever implemented as refcounting (according to the changelogs some preliminary work had been done towards a precise GC but AFAIK there was no followup). This is in large part why it was dropped: it was technically redundant with Arc, and could give users the wrong impression, and could always be added back later if that made sense.
- pjmlp 3y ago
  Technically from CS point of view, refcounting is a GC implementation algorithm.
  - masklinn 3y ago
    I fail to see what that has to do with anything, unless you’re asserting that current rust is GC’d on the back of arc existing.
    - pjmlp 3y ago
      It has to do everything with the wording on your comment that kind of makes the usual lay man distinction between GC and refcounting, nothing to do with Arc, as using it is manual work anyway.
    - Zambyte 3y ago
      The point of a garbage connector is to simulate infinite memory[0], which is the point of Arc. So current Rust has GC :) [0] https://octodon.social/@cwebber/110815313802832972 https://octodon.social/@cwebber/110815313802832972
    - bmacho 3y ago
      Rust as a language is not GC'd, but has a refcounted (that is, GC'd) pointer type if you want/need it.
  - ryukoposting 3y ago
    Yes, but does that make circa-2013 Rust a "garbage collected language?" It seems to me that when we talk about GC'ed languages, we're talking about languages where the heap is managed implicitly. If I understand it right, @ is explicitly invoked by the user, but the implementation is embedded within the language. With Arc/Rc, there are Deref/Drop implementations somewhere in the stdlib that do the reference counting.
sbt567 3y ago
Is there any other languages that let you use async on embedded/bare metal? I think Rust could learn from them. Especially on the ergonomics side. Otherwise, what Rust might currently do is blazing a trail through a forest.
- FpUser 3y ago
  >"Is there any other languages that let you use async on embedded/bare metal?" So you do not know if there are and what kind and other important details. >"I think Rust could learn from them." Yet you think
- marcosdumay 3y ago
  There is no other language that does what Rust is trying to do. But that is not "using async on embedded/bare metal", this one is easy, jut use a garbage collector.
  - brabel 3y ago
    Hm, I think Pony did try doing what Rust is doing, with an even more advanced system for "borrows" (there's several types of borrow, not just two): https://www.ponylang.io/ https://www.ponylang.io/ Also, Vale is on the way: https://vale.dev/ https://vale.dev/ And D is also working on it: https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/ https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in...
- kaba0 3y ago
  What should it learn? If you combine async with Rust’s nested lifetimes, you get quite a bit of complexity from the borrowchecker, period. There is not much else to it.
- jamesmunns 3y ago
  From a net-effect standpoint, Rust's implementation of async/await is fairly similar to protothreads, which were used even on smaller AVR and MSP430 targets where rtos threads weren't practical. That being said, protothreads were implemented using wildly cursed C macros, and offered none of the safety guardrails that Rust has, nor the ergonomics, and had some insane constraints, like "you can't use local variables at all, only statics" because like rust, they were stackless coroutines that meant you would have no control of the stack across await points. If you were VERY CAREFUL, you could get the same lightweight concurrency with almost the same fundamental model. Woe be on you if you ever had to debug though. edit - here's a look at how protothreads were expanded: https://dunkels.com/adam/pt/expansion.html https://dunkels.com/adam/pt/expansion.html
ekidd 3y ago
> even if I do get frustrated with mind-numbing Async issues from time to time. A noticeable portion of async issues come from the fact that a lot of people use Tokio's multithreaded async runtime. Tokio allows you to mix async and native theads, which is both a virtuoso technical accomplishment and also a bit ridiculous. If you use Tokio's single-threaded runtime, things get simpler. The remaining async challenges are mostly the usual "Rust tax", turned up to 11. Rust wants you to be painfully aware that memory allocations are expensive and that sharing memory in a complex concurrent system is risky. In sync Rust, the usual advice is "Don't get too tricky with lifetimes. Use `clone` when you need to." In async Rust without native threads, the rules are something like: 1. Boxing your futures only costs you a heap allocation, and it vastly simplifies many things. 2. If you want a future to remain around while you do other stuff, have it take ownership of all its parameters. Where people get in the most trouble is when they say, "I want to mix green threads and OS threads willy-nilly, and I want to go to heroic lengths to never call `malloc`." Rust makes that approach look far too tempting. And worse, it requires you to understand and decide whether you're taking that approach. But if you remember "Box more futures, own more parameters, and consider using a single-threaded runtime" then async Rust offers some pretty unique features in exchange for a pretty manageable amount of pain. Also, seriously, more people should consider Kotlin. It has many Rust-like features, but it has a GC. And you don't need to be constantly aware of the tradeoffs between allocation and sharing, if that's not a thing you actually care about.
- bluejekyll 3y ago
  > Tokio allows you to mix async and native theads, which is both a virtuoso technical accomplishment and also a bit ridiculous. Can you describe what issues you’re referring to? I use the multi-threaded Tokio runtime, I’ve not noticed any overhead with that in terms of development vs. single threaded. Also, multi-threaded async runtimes are generally what you want to make sure you don’t have any single tasks blocking others that could make progress in parallel.
  - danenania 3y ago
    "Also, multi-threaded async runtimes are generally what you want to make sure you don’t have any single tasks blocking others that could make progress in parallel." Is there an advantage to multi-threaded async if you're IO-bound? If you want a bunch of concurrent system calls or network requests it seems like single-threaded async can handle that pretty nicely ala Node.js.

by orf 3y ago

rcarr 3y ago

For anyone interested there was a big discussion on async in rust a few days ago. Rust is on todo list to learn but I found reading some of these comments quite interesting: https://news.ycombinator.com/item?id=37435515 https://news.ycombinator.com/item?id=37435515

mplanchard 3y ago
Note also this rebuttal: https://news.ycombinator.com/item?id=37448460 https://news.ycombinator.com/item?id=37448460 As someone who works with async rust professionally, I wouldn’t let takes like the one you posted dissuade you. My personal opinion is that async rust is easier to work with than in most other languages because of the extra concurrency guarantees that rust gives you. There are some rough edges, but not nearly as many as the link you posted suggests.
- littlestymaar 3y ago
  This exactly. Sure Async Rust requires you to learn a few new things, but the blog post is mostly a rant from someone not very familiar with the topic (like what you'd expect from something called “<X> is a bad language” TBH).
- rcarr 3y ago
  I wasn't, I actually didn't even read the attached article only the HN comments who seemed to mainly disagree with the article and mentioned quite a lot about the different approaches to async in Rust. I really want to learn it but prioritising up-skilling my DevOps capabilities at the minute so it will have to be next year.
  - mplanchard 3y ago
    Glad to hear it! I am ~2.5 years into my professional Rust career, ~4.5 years into working with the language, and it's still my favorite. It's certainly not the only great language out there, but it's definitely one of them.

masklinn 3y ago

> moving from a GC’d language Rust was never actually a GC’d language. It had a smart pointer called Gc (and before that @), but that was only ever implemented as refcounting (according to the changelogs some preliminary work had been done towards a precise GC but AFAIK there was no followup). This is in large part why it was dropped: it was technically redundant with Arc, and could give users the wrong impression, and could always be added back later if that made sense.

pjmlp 3y ago
Technically from CS point of view, refcounting is a GC implementation algorithm.
- masklinn 3y ago
  I fail to see what that has to do with anything, unless you’re asserting that current rust is GC’d on the back of arc existing.
  - pjmlp 3y ago
    It has to do everything with the wording on your comment that kind of makes the usual lay man distinction between GC and refcounting, nothing to do with Arc, as using it is manual work anyway.
  - Zambyte 3y ago
    The point of a garbage connector is to simulate infinite memory[0], which is the point of Arc. So current Rust has GC :) [0] https://octodon.social/@cwebber/110815313802832972 https://octodon.social/@cwebber/110815313802832972
  - bmacho 3y ago
    Rust as a language is not GC'd, but has a refcounted (that is, GC'd) pointer type if you want/need it.
- ryukoposting 3y ago
  Yes, but does that make circa-2013 Rust a "garbage collected language?" It seems to me that when we talk about GC'ed languages, we're talking about languages where the heap is managed implicitly. If I understand it right, @ is explicitly invoked by the user, but the implementation is embedded within the language. With Arc/Rc, there are Deref/Drop implementations somewhere in the stdlib that do the reference counting.

sbt567 3y ago

Is there any other languages that let you use async on embedded/bare metal? I think Rust could learn from them. Especially on the ergonomics side. Otherwise, what Rust might currently do is blazing a trail through a forest.

FpUser 3y ago
>"Is there any other languages that let you use async on embedded/bare metal?" So you do not know if there are and what kind and other important details. >"I think Rust could learn from them." Yet you think
marcosdumay 3y ago
There is no other language that does what Rust is trying to do. But that is not "using async on embedded/bare metal", this one is easy, jut use a garbage collector.
- brabel 3y ago
  Hm, I think Pony did try doing what Rust is doing, with an even more advanced system for "borrows" (there's several types of borrow, not just two): https://www.ponylang.io/ https://www.ponylang.io/ Also, Vale is on the way: https://vale.dev/ https://vale.dev/ And D is also working on it: https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/ https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in...
kaba0 3y ago
What should it learn? If you combine async with Rust’s nested lifetimes, you get quite a bit of complexity from the borrowchecker, period. There is not much else to it.
jamesmunns 3y ago
From a net-effect standpoint, Rust's implementation of async/await is fairly similar to protothreads, which were used even on smaller AVR and MSP430 targets where rtos threads weren't practical. That being said, protothreads were implemented using wildly cursed C macros, and offered none of the safety guardrails that Rust has, nor the ergonomics, and had some insane constraints, like "you can't use local variables at all, only statics" because like rust, they were stackless coroutines that meant you would have no control of the stack across await points. If you were VERY CAREFUL, you could get the same lightweight concurrency with almost the same fundamental model. Woe be on you if you ever had to debug though. edit - here's a look at how protothreads were expanded: https://dunkels.com/adam/pt/expansion.html https://dunkels.com/adam/pt/expansion.html

ekidd 3y ago

> even if I do get frustrated with mind-numbing Async issues from time to time. A noticeable portion of async issues come from the fact that a lot of people use Tokio's multithreaded async runtime. Tokio allows you to mix async and native theads, which is both a virtuoso technical accomplishment and also a bit ridiculous. If you use Tokio's single-threaded runtime, things get simpler. The remaining async challenges are mostly the usual "Rust tax", turned up to 11. Rust wants you to be painfully aware that memory allocations are expensive and that sharing memory in a complex concurrent system is risky. In sync Rust, the usual advice is "Don't get too tricky with lifetimes. Use `clone` when you need to." In async Rust without native threads, the rules are something like: 1. Boxing your futures only costs you a heap allocation, and it vastly simplifies many things. 2. If you want a future to remain around while you do other stuff, have it take ownership of all its parameters. Where people get in the most trouble is when they say, "I want to mix green threads and OS threads willy-nilly, and I want to go to heroic lengths to never call `malloc`." Rust makes that approach look far too tempting. And worse, it requires you to understand and decide whether you're taking that approach. But if you remember "Box more futures, own more parameters, and consider using a single-threaded runtime" then async Rust offers some pretty unique features in exchange for a pretty manageable amount of pain. Also, seriously, more people should consider Kotlin. It has many Rust-like features, but it has a GC. And you don't need to be constantly aware of the tradeoffs between allocation and sharing, if that's not a thing you actually care about.

bluejekyll 3y ago
> Tokio allows you to mix async and native theads, which is both a virtuoso technical accomplishment and also a bit ridiculous. Can you describe what issues you’re referring to? I use the multi-threaded Tokio runtime, I’ve not noticed any overhead with that in terms of development vs. single threaded. Also, multi-threaded async runtimes are generally what you want to make sure you don’t have any single tasks blocking others that could make progress in parallel.
- danenania 3y ago
  "Also, multi-threaded async runtimes are generally what you want to make sure you don’t have any single tasks blocking others that could make progress in parallel." Is there an advantage to multi-threaded async if you're IO-bound? If you want a bunch of concurrent system calls or network requests it seems like single-threaded async can handle that pretty nicely ala Node.js.