5 ms·

zero cost abstraction and no gc

pjmlp 5y ago
Same could be said for C++, and yet while C++20 also doesn't have an official runtime on std (C++23 will fix that assuming executors land), the vocabulary types required for interoperability across runtimes are part of the co-routines design.
- varajelle 5y ago
  Rust also has the vocabulary types required for interoperability, such as Future and Waker. Or what exactly make C++ more interoperable?
  - pjmlp 5y ago
    Does it? https://book.async.rs/overview/std-and-library-futures.html https://book.async.rs/overview/std-and-library-futures.html C++ ones can interoperate with any type that plugs into the compiler magic expected by the co-routines code rewrite. If you want to deep dive into how Visual C++ does it, and how WinRT gets plugged into C++ co-routines, here is a very lengthy set of blog posts. https://devblogs.microsoft.com/oldnewthing/20210504-01/?p=105178 https://devblogs.microsoft.com/oldnewthing/20210504-01/?p=10... Now back to Rust, how can I interoperate across tokio, async-std, smol and fuchsia-std, as easy as I can between WinRT, and others?
    - varajelle 5y ago
      The std::future::Future from the rust standard library works with every runtime. Not sure I understand, what kind of interoperability you are talking about. What kinds of code works in C++ across runtimes, for which the equivalent in Rust doesn't?
      - pjmlp 5y ago
        In C++ you don't have the scenario like in Rust, where one is forced to use a specific async runtime for library xyz, because it depends on having tokio as runtime. Or has that situation been sorted out by now?
        varajelle 5y ago
        In Rust you only are forced to use a specific runtime if you want to use its API. For example to spawn new tasks, or to block on a future. I believe that would be the same in C++. In Rust, you don't need to use a specific runtime if you just want to use async function in your library.
mseepgood 5y ago
All design trade-offs have a cost. In this case the costs are reduced usability and async struggles.
- carlmr 5y ago
  Zero-cost abstractions is used to mean zero runtime cost (in release builds), so if an abstraction would break that it wouldn't be suitable for this goal. Like adding a GC for the async feature.

Same could be said for C++, and yet while C++20 also doesn't have an official runtime on std (C++23 will fix that assuming executors land), the vocabulary types required for interoperability across runtimes are part of the co-routines design.

varajelle 5y ago
Rust also has the vocabulary types required for interoperability, such as Future and Waker. Or what exactly make C++ more interoperable?
- pjmlp 5y ago
  Does it? https://book.async.rs/overview/std-and-library-futures.html https://book.async.rs/overview/std-and-library-futures.html C++ ones can interoperate with any type that plugs into the compiler magic expected by the co-routines code rewrite. If you want to deep dive into how Visual C++ does it, and how WinRT gets plugged into C++ co-routines, here is a very lengthy set of blog posts. https://devblogs.microsoft.com/oldnewthing/20210504-01/?p=105178 https://devblogs.microsoft.com/oldnewthing/20210504-01/?p=10... Now back to Rust, how can I interoperate across tokio, async-std, smol and fuchsia-std, as easy as I can between WinRT, and others?
  - varajelle 5y ago
    The std::future::Future from the rust standard library works with every runtime. Not sure I understand, what kind of interoperability you are talking about. What kinds of code works in C++ across runtimes, for which the equivalent in Rust doesn't?
    - pjmlp 5y ago
      In C++ you don't have the scenario like in Rust, where one is forced to use a specific async runtime for library xyz, because it depends on having tokio as runtime. Or has that situation been sorted out by now?
      - varajelle 5y ago
        In Rust you only are forced to use a specific runtime if you want to use its API. For example to spawn new tasks, or to block on a future. I believe that would be the same in C++. In Rust, you don't need to use a specific runtime if you just want to use async function in your library.

mseepgood 5y ago

All design trade-offs have a cost. In this case the costs are reduced usability and async struggles.

carlmr 5y ago
Zero-cost abstractions is used to mean zero runtime cost (in release builds), so if an abstraction would break that it wouldn't be suitable for this goal. Like adding a GC for the async feature.