3 ms·

Honestly I see no reason why rust is so focused on Async if they’re C++ alternative (that is smaller runtime), having a unique keyword doesn’t seat right with m

by demi56 3y ago

Honestly I see no reason why rust is so focused on Async if they’re C++ alternative (that is smaller runtime), having a unique keyword doesn’t seat right with me, I won’t be surprised if there will one day be a popular GC runtime

steveklabnik 3y ago
Just so you're aware, C++ has three keywords here: co_async, co_await, and co_return, so it feels a bit odd to complain about this aspect, specifically. Also, as I mentioned below, Rust fares even better than C++ on minimizing allocations here. C++ is used in high performing network services all the time, it shouldn't be a shock that Rust gets used for them as well.
- demi56 3y ago
  Wow, so c++ is joining the gang too, looks like rust really is changing the programming ecosystem
  - steveklabnik 3y ago
    Rust was not the impetus for C++ getting this feature, just to be clear about it. Or at least, I never read that in any of the many papers over the years working through the design.
  - Buttons840 3y ago
    C# added async / await keywords first it seems, JavaScript a few years later. Rust is not the leader here.
- kccqzy 3y ago
  C++ strongly depends on the actual implementation quality by leaving a lot of things to implementations. For example, the person leading the coroutine implementation in clang is very inconsistent on minimizing allocations than the GCC implementations. As an example they implemented a generator system using C++ coroutines that eventually compile down to a single instruction (https://godbolt.org/z/nsTjjGbn4 https://godbolt.org/z/nsTjjGbn4). As a counter argument though, clang's support for coroutines is still buggy and not ready for production use.
  - Conscat 3y ago
    Optimistically, the explicit coroutine allocation proposal and the Clang-IR project should both make the situation a lot better in the future.
- saurik 3y ago
  > Just so you're aware, C++ has three keywords here: co_async, co_await, and co_return... This is admittedly an unimportant correction to what you said that doesn't in any way change your point; and yet, I still think it is an important one to keep in mind for people who only might end up with an indirect understanding of the C++ feature: C++ additionally chose to add a specialized co_yield... and specifically does not have co_async! This latter tradeoff then relates to the Rust discussions I have seen come up again recently due to the article "Was async fn a mistake?". https://seanmonstar.com/post/66832922686/was-async-fn-a-mistake https://seanmonstar.com/post/66832922686/was-async-fn-a-mist... https://news.ycombinator.com/item?id=37789057 https://news.ycombinator.com/item?id=37789057 https://old.reddit.com/16ugwuc/ https://old.reddit.com/16ugwuc/
  - deleted 3y ago
    [deleted]

by demi56 3y ago

steveklabnik 3y ago

Just so you're aware, C++ has three keywords here: co_async, co_await, and co_return, so it feels a bit odd to complain about this aspect, specifically. Also, as I mentioned below, Rust fares even better than C++ on minimizing allocations here. C++ is used in high performing network services all the time, it shouldn't be a shock that Rust gets used for them as well.

demi56 3y ago
Wow, so c++ is joining the gang too, looks like rust really is changing the programming ecosystem
- steveklabnik 3y ago
  Rust was not the impetus for C++ getting this feature, just to be clear about it. Or at least, I never read that in any of the many papers over the years working through the design.
- Buttons840 3y ago
  C# added async / await keywords first it seems, JavaScript a few years later. Rust is not the leader here.
kccqzy 3y ago
C++ strongly depends on the actual implementation quality by leaving a lot of things to implementations. For example, the person leading the coroutine implementation in clang is very inconsistent on minimizing allocations than the GCC implementations. As an example they implemented a generator system using C++ coroutines that eventually compile down to a single instruction (https://godbolt.org/z/nsTjjGbn4 https://godbolt.org/z/nsTjjGbn4). As a counter argument though, clang's support for coroutines is still buggy and not ready for production use.
- Conscat 3y ago
  Optimistically, the explicit coroutine allocation proposal and the Clang-IR project should both make the situation a lot better in the future.
saurik 3y ago
> Just so you're aware, C++ has three keywords here: co_async, co_await, and co_return... This is admittedly an unimportant correction to what you said that doesn't in any way change your point; and yet, I still think it is an important one to keep in mind for people who only might end up with an indirect understanding of the C++ feature: C++ additionally chose to add a specialized co_yield... and specifically does not have co_async! This latter tradeoff then relates to the Rust discussions I have seen come up again recently due to the article "Was async fn a mistake?". https://seanmonstar.com/post/66832922686/was-async-fn-a-mistake https://seanmonstar.com/post/66832922686/was-async-fn-a-mist... https://news.ycombinator.com/item?id=37789057 https://news.ycombinator.com/item?id=37789057 https://old.reddit.com/16ugwuc/ https://old.reddit.com/16ugwuc/
- deleted 3y ago
  [deleted]