What 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.
[deleted: man, was that a dumb comment]
Tokio 1.0 – async runtime for Rust
71–80 of 422 posts
Re: Tokio 1.0 – async runtime for Rust
#72Can someone explain to a non-rustacean what Tokio introduces that's not part of Rust? It looks like Rust provides the async/await semantics, so I'm guessing this is an event loop and dispatching system?
Yeah that's exactly right, it's an event loop.
It's hilarious to me that it's hitting "1.0" now. I remember the original release ~4 years ago?? That was way before Rust even had async/await. I imagine there were quite a few refactors. I mean, so much work, to make a library for asynchronous network service programming? If I needed an event loop and a scheduler I think I would just invest in implementing it myself, tailored to the requirements of my project.
Re: Tokio 1.0 – async runtime for Rust
#73Can someone explain to a non-rustacean what Tokio introduces that's not part of Rust? It looks like Rust provides the async/await semantics, so I'm guessing this is an event loop and dispatching system?
In very loose terms: Rust's async/await syntax defines an interface to async programming, not an implementation . Rust leaves the implementation, and thereby choice of concurrency strategy, to libraries. Tokio is such a library. There's at least one other popular one of note.
> There's at least one other popular one of note.
The other popular runtimes are async-std [0] and smol [1].
Re: Tokio 1.0 – async runtime for Rust
#74I have known Tokio for ages and I'm not even a Rust programmer. It seems like a solid project.
Re: Tokio 1.0 – async runtime for Rust
#75I wonder whether there is any ongoing effort to unify the ecosystem between different runtimes. Specially considering that Tokio and futures (by extension async-std) implement their own Async* traits, it seems that it becomes even harder to write runtime agnostic libraries. It would be nice if these fundamental traits were part of rust std library.
Re: Tokio 1.0 – async runtime for Rust
#76Can someone tell me why tokio is so damn big and full of transitive dependencies :D?
Re: Tokio 1.0 – async runtime for Rust
#77I don't really get these modern async APIs. In languages like Javascript I thought they only made sense because JS interpreters are (historically) single-threaded, so you really have no choice but async to express some concepts. Fine.
But in Rust you can just spawn threads, share data through channels or mutexes, use OS-provided async IO primitives to poll file descriptors and do event-driven programming etc...
I tried looking into Tokio a little while ago and I found that it led to some incredibly complicated, abstracted, hard to think about code for stuff I usually implement (IMO) much more simply with a basic event loop and non-blocking IO for instance.
I'm sure async can get the upper hand when you have a huge number of very small tasks running concurrently because that's generally where OS-driven parallelism tends to suffer but is it such a common scenario? That sounds like premature optimization in many situations IMO. Unless you actually think that async code is more expressive and easy to read and write than basic event loops, but then you must be a lot smarter than I am because I have to take an aspirin every time I need to dig into async-heavy code.
I guess I'm trying to understand if it's me who's missing something, or if it's web-oriented developers who are trying to bring their favourite type of proverbial hammer to system development.
Re: Tokio 1.0 – async runtime for Rust
#78Earlier quoted context omitted.
Would it be fair to compare this to Apple's Grand Central Dispatch a.k.a. libdispatch?
It's similar. libdispatch is primarily a task queue to simplify and optimize multithreaded workloads in objc/swift. Tokio uses a similar task queue pattern for scheduling cpu-bound or blocking io, but the main feature is an non-blocking/asynchronous IO runtime. Overall, it's more similar to libuv (the async io library that powers node.js), but with built-in support for Rust's async/await syntax
You mean io-bound
Re: Tokio 1.0 – async runtime for Rust
#79It 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.
If core rust provides an interface for async/await why does usage of it tie you to a specific runtime? Whats the point of that?
Re: Tokio 1.0 – async runtime for Rust
#80Earlier quoted context omitted.
he posted a goodbye issue on a smol repo, but since then deleted it, so maybe he changed his mind
I found the github issue in Google cache. I'm not sure it's really fair of me to post this link here, but equally I think it's better to give the actual text rather than leave it vague. https://webcache.googleusercontent.com/search?q=cache:PRjMyv...
Thanks for the pointer! It's really sad to hear this. I'm using smol in my project and really like it. I didn't know the author left until now. It's a great loss for Rust, in my opinion.