Earlier quoted context omitted.
To me it's kind of like the event loop of node.js (which I believe comes from libuv)?
Yes, Deno uses it as its internal event loop for JS code.
Fun party fact: long ago, Rust had libuv built in too.
Tokio 1.0 – async runtime for Rust
31–40 of 422 posts
Re: Tokio 1.0 – async runtime for Rust
#32Earlier quoted context omitted.
To provide some more color on why this isn't built in, different runtimes provide different kinds of guarantees and performance profiles. A webapp has very different requirements than an embedded system, and so we don't want to provide a single runtime. The language contains the basic things needed for the ecosystem to exist, and interoperation points, and then leaves the rest to said ecosystem. (Some of those intero…
When learning Rust a few months ago, I built a small client library for a REST API using reqwest (which uses Tokio). I then started writing a web app using Tide ( https://github.com/http-rs/tide ). I eventually realized that it would be difficult to use the library I had built earlier since Tide uses the async-std runtime rather than Tokio. That was very disappointing. Is there any plan to make it easier to write "ru…
Yes, that is what I alluded to at the end. There's a few points here that still need some interop work. The intention is to fix that, but it's non-trivial. We'll get there.
Re: Tokio 1.0 – async runtime for Rust
#33What would be Tokios equivalent in .net/C# ?
C#/.NET has all of this already. You don't have to import anything else to use async/await.
Re: Tokio 1.0 – async runtime for Rust
#34Earlier quoted context omitted.
> rustafarian The community prefers the term "rustacean" to be as inclusive as possible. Please keep that in mind in the future.
TIL, thanks for the correction
(It's a combination of not wanting to trivialize a religion, and that 'RESTafarian' has a long history of use, and that's just confusing)
Re: Tokio 1.0 – async runtime for Rust
#35Re: Tokio 1.0 – async runtime for Rust
#36Congrats! I've fallen off Rust due to pivoting at work plus trying other languages but I'm intrigued again by Tokio's announcement. I'll be trying out your tutorial soon!
what did you pivot to and why, if you don't mind me asking?
Can't speak for the commenter, but I used to work for a team couple years ago that used rust and tokio extensively, and some projects were just not a good fit. At the time, futures were well fleshed out but the community hadn't caught up, so we were lacking a futures-compatible postgres and redis client. We wrote the redis client ourselves, and for the main project using rust that was sufficient. But for postgres, that was a show stopper for any other projects we were working on. So we ended up deciding between typescript and go for those.
Re: Tokio 1.0 – async runtime for Rust
#37It is unfortunate, that libraries have to be coded against specific runtime and not generically. There is tokio and there is smol (likely discontinued, since author left rust), maybe other runtimes will emerge, but whole ecosystem is already tied to tokio.
Re: Tokio 1.0 – async runtime for Rust
#38What would be Tokios equivalent in .net/C# ?
In .NET you have the low-level runtime machinery implemented in the CLR (Common Language Runtime), but the transformation from async-await to state machine code is done completely at compile time.
Basically, just like C# (and VB.NET and C++ .NET task/then) provides syntax and semantics for async-await, Rust provides it at language level too. (And it defines how the compiler transforms it into Future objects.)
But, since Rust doesn't have a mandatory runtime, something needs to implement the low-level stuff that knows what to do with these Future objects. (In Tokio you have a work-stealing threadpool, but maybe in smaller runtimes you don't need all that fancy stuff for high-throughput, you just need small binary size, so there's a runtime/library called "smol" that's main feature is that it's a small async runtime.) In the CLR as far as I know there are Task objects, which basically correspond to Rust's Future objects.
One interesting low-level difference (similarity?) is that in the CLR there's an explicit callback support by the runtime (to wake up Task objects - which can lead to deadlocks if they are scheduled on the UI thread), whereas in Rust Futures pass their own callbacks (called Waker) to a thing called the Reactor (which is basically the low-level implementation of the Executor, which binds to the OS/kernel level primitives, such as epoll or IOCP).
And even though it's a "zero cost" abstraction, it still means there's a state machine, just like in .NET. Except it's built and "deadlock checked" at compile time.
https://tooslowexception.com/wp-content/uploads/2020/05/ther...
https://www.red-gate.com/simple-talk/dotnet/net-framework/th...
Re: Tokio 1.0 – async runtime for Rust
#39It is unfortunate, that libraries have to be coded against specific runtime and not generically. There is tokio and there is smol (likely discontinued, since author left rust), maybe other runtimes will emerge, but whole ecosystem is already tied to tokio.
async-std [0] is pretty widely used as well.
[0]: https://github.com/async-rs/async-std
Most libraries can be used with different runtimes. Hyper for example, which uses Tokio by default, can be configured to use an async-std executor.
Re: Tokio 1.0 – async runtime for Rust
#40It is unfortunate, that libraries have to be coded against specific runtime and not generically. There is tokio and there is smol (likely discontinued, since author left rust), maybe other runtimes will emerge, but whole ecosystem is already tied to tokio.
> and there is smol (likely discontinued, since author left rust)
Whoa. smol is great. Why’d the author leave?