Threads cannot scale at all, because you're limited to the number of threads (which is usually quite small). Async code can scale essentially infinitely, because it can multiplex thousands of Futures onto a single…
> Async traits come to mind immediately, I agree that being able to use `async` inside of traits would be very useful, and hopefully we will get it soon. > generally needing more capability to existentially quantify…
> So you’re stuck choosing a single CPU or having to write send and sync everywhere. There’s a lot of use cases where you would want a thread-per-core model like Glommio to take advantage of multiple cores while still…
Even the costs you are talking about are a one-time cost to read the documentation and learn the abstraction. And the long-term benefits of the abstraction are far greater than the one-time costs. That's why we create…
I never said that ALL abstractions in Rust are zero-cost, though the vast majority of them are, and you actually have to explicitly go out of your way to use non-zero-cost abstractions.
I'm curious what things you consider to be half-baked about Rust async. I've used Rust async extensively for years, and I consider it to be the cleanest and most well designed async system out of any language (and yes,…
I am very aware of the definition of zero-cost. We're talking about the comparison between using an abstraction vs not using an abstraction. When I said "doesn't have a runtime cost", I meant "the abstraction doesn't…
The whole point of an abstraction is to remove complexity for the user. So I assume you mean "implementation complexity" but that's irrelevant, because that cost only needs to be paid once, and then you put the…
Ah, my mistake.
Every executor (including tokio) supports spawning Futures that aren't Send: https://docs.rs/tokio/1.32.0/tokio/task/fn.spawn_local.html There is a lot of misinformation in this thread, with people not knowing what…
No, tokio does not require your Futures to be thread-safe. Every executor (including tokio) provides a `spawn_local` function that spawns Futures on the current thread, so they don't need to be Send:…
Yes, you can do that. You can use `block_on` to convert an async Future into a synchronous blocking call. So it is entirely possible to convert from the async world back into the sync world.
If you choose to use Mutex, that's on you. Rust gives you channels (both synchronous blocking channels and async channels), and they work great, there is nothing stopping you from using them.
Rust embraces abstractions because Rust abstractions are zero-cost. So you can liberally create them and use them without paying a runtime cost. That makes abstractions far more useful and powerful, since you never need…
Rust has had OS channels since forever, and async channels for 5 years. Rust has changed a lot in the past 5 years, people just haven't noticed, so they assume that Rust is still an old outdated language.
Rust Futures are essentially green threads, except much lighter-weight, much faster, and implemented in user space instead of being built-in to the language. Basically Rust Futures is what Go wishes it could have. Rust…
I think there are a couple important details you are missing... First, wasm-pack is not Ashley's personal project, it is an official Rust Wasm project. That means it is owned by the Rust Wasm team, and it is maintained…
I am aware of Dylan, however it did not have any influence on Nulan. Nulan's macro system is very similar to Common Lisp or Arc's macro system, in the sense that a macro is simply a compile-time function that accepts…
Hey guys, I'm the creator of Nulan. There were some bugs in the tutorial, which I fixed just now. If the tutorial wasn't working for you, please try again. ---- This is a pleasant surprise: I honestly was not expecting…
Threads cannot scale at all, because you're limited to the number of threads (which is usually quite small). Async code can scale essentially infinitely, because it can multiplex thousands of Futures onto a single…
> Async traits come to mind immediately, I agree that being able to use `async` inside of traits would be very useful, and hopefully we will get it soon. > generally needing more capability to existentially quantify…
> So you’re stuck choosing a single CPU or having to write send and sync everywhere. There’s a lot of use cases where you would want a thread-per-core model like Glommio to take advantage of multiple cores while still…
Even the costs you are talking about are a one-time cost to read the documentation and learn the abstraction. And the long-term benefits of the abstraction are far greater than the one-time costs. That's why we create…
I never said that ALL abstractions in Rust are zero-cost, though the vast majority of them are, and you actually have to explicitly go out of your way to use non-zero-cost abstractions.
I'm curious what things you consider to be half-baked about Rust async. I've used Rust async extensively for years, and I consider it to be the cleanest and most well designed async system out of any language (and yes,…
I am very aware of the definition of zero-cost. We're talking about the comparison between using an abstraction vs not using an abstraction. When I said "doesn't have a runtime cost", I meant "the abstraction doesn't…
The whole point of an abstraction is to remove complexity for the user. So I assume you mean "implementation complexity" but that's irrelevant, because that cost only needs to be paid once, and then you put the…
Ah, my mistake.
Every executor (including tokio) supports spawning Futures that aren't Send: https://docs.rs/tokio/1.32.0/tokio/task/fn.spawn_local.html There is a lot of misinformation in this thread, with people not knowing what…
No, tokio does not require your Futures to be thread-safe. Every executor (including tokio) provides a `spawn_local` function that spawns Futures on the current thread, so they don't need to be Send:…
Yes, you can do that. You can use `block_on` to convert an async Future into a synchronous blocking call. So it is entirely possible to convert from the async world back into the sync world.
If you choose to use Mutex, that's on you. Rust gives you channels (both synchronous blocking channels and async channels), and they work great, there is nothing stopping you from using them.
Rust embraces abstractions because Rust abstractions are zero-cost. So you can liberally create them and use them without paying a runtime cost. That makes abstractions far more useful and powerful, since you never need…
Rust has had OS channels since forever, and async channels for 5 years. Rust has changed a lot in the past 5 years, people just haven't noticed, so they assume that Rust is still an old outdated language.
Rust Futures are essentially green threads, except much lighter-weight, much faster, and implemented in user space instead of being built-in to the language. Basically Rust Futures is what Go wishes it could have. Rust…
I think there are a couple important details you are missing... First, wasm-pack is not Ashley's personal project, it is an official Rust Wasm project. That means it is owned by the Rust Wasm team, and it is maintained…
I am aware of Dylan, however it did not have any influence on Nulan. Nulan's macro system is very similar to Common Lisp or Arc's macro system, in the sense that a macro is simply a compile-time function that accepts…
Hey guys, I'm the creator of Nulan. There were some bugs in the tutorial, which I fixed just now. If the tutorial wasn't working for you, please try again. ---- This is a pleasant surprise: I honestly was not expecting…