Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tokio 1.0 – async runtime for Rust

tokio.rs

Post reply on HN
Print view View original

381–390 of 422 posts

Re: Tokio 1.0 – async runtime for Rust

#381

Post by skohan »

pjmlp wrote: post #378
skohan wrote: post #366

Earlier quoted context omitted.

Maybe I've just missed it, but I have found pkg-config difficult to use and poorly documented. It's fine if you are installing things with a package manager, but I found it took some trail-and-error to figure out how to do this for my own lbraries, or for things built manually from source. Also with c/c++ style system dependencies, I feel like there are a lot of issues with things like version conflicts which are sol…

Cargo also has issues when two crates have incompatible dependencies, or at very least you end with the same crate being compiled a couple of times, as the hashes don't match up. Usually when compiling from source many libraries provide pkg-config configuration files on "make install".

But with Cargo it's scoped to the crate you're compiling right? So it only matters if there's a collision in the dependencies of a given project.

Isn't it the case with pkg-config that everything is stored in a central location?

In any case, I think you can't seriously argue that the c/c++ dependency management solution is anywhere close to running `cargo build`/`cargo run` in terms of simplicity.

Re: Tokio 1.0 – async runtime for Rust

#382

Post by [deleted] »

lmm wrote: post #319
ldng wrote: post #316

Earlier quoted context omitted.

Why WTF ? You are reading something I did not write. I am not obsessed with the nonblocking mantra. Blocking is not inherently bad. Multi-processus is also a perfectly valid concurrency model. Nor am I obsessing about being ultra performant to achieve the revered C10K when I don't need to or can get around it. That was my point. Not everybody is Facebook or Netflix. For the vast majority of small and medium enterpris…

> Why WTF ? Because WTF does using a compiled language have to do with anything? > Nor am I obsessing about being ultra performant to achieve the revered C10K when I don't need to or can get around it. That was my point. Then what is it that you imagine using a compiled language would help with?

[deleted]

Re: Tokio 1.0 – async runtime for Rust

#383

Post by littlestymaar »

johnnycerberus wrote: post #223
pvorb wrote: post #170

Earlier quoted context omitted.

In the Java world, project Loom[1] is hopefully going to end this situation of async code that is hard to use with blocking code. They introduce a concept called Virtual Threads (previously called Fibers, but they are still looking for the perfect name). This will allow for seamless interoperability between blocking and non-blocking code as everything in Java runs on a Thread and Virtual Threads are just a specializa…

Go and Zig already solved the problem. Java will follow soon with Loom, can't wait.

Go “solved the problem” at the expense of being unable to interface with C libraries without a big performance penalty (and that's you'll have Rust in Chromium and not Go)

Re: Tokio 1.0 – async runtime for Rust

#384

Post by Ygg2 »

volta87 wrote: post #370

> Also, Tokio would not have been possible without Aaron Turon's and Alex Crichton's early involvement. This feels like a slap in the face for some reason. Aaron Turon is an extremely talented individual (their PhD thesis was a landmark contributionn). They are super kind and one of the nicest human beings I've ever met. They led the Rust Project until their involvement with Tokio caused them to drop off from Tech. A…

What? Why did they drop from tech?

Are you sure this isn't something else instead?

Re: Tokio 1.0 – async runtime for Rust

#385

Post by tinynation »

This is awesome, congrats on the 1.0!

As a new rustacean it was really difficult to try and use the the async/await syntax with horde of adapters required for tokio 0.1/0.2. I ended up trying out async-std too, but the move to smol had its own issues and I lost interest.

A 1.0 release with stability commitments is exactly what I need to get back into experimenting with Rust.

Re: Tokio 1.0 – async runtime for Rust

#386

Post by matt_kantor »

steveklabnik wrote: post #367
secondcoming wrote: post #358

Earlier quoted context omitted.

Well, I took the phrase 'repeatedly call' to mean pretty much that! What bugs me about it, if I'm understanding it correctly, is that you have two options once an async call is issued: - the calling thread effectively waits for completion. This is fine if a fork/join pattern is useful to you (i.e. issue N async calls and then wait for N completions). This isn't proper asynchrony though. - the future is pushed on to a…

I can't speak to the same level of depth about the C++ model as the Rust one, but, while you could do those things, it's not the usual way that it works, at least, if I'm understanding your terms correctly. I'll admit that I find your terms in the first bullet pretty confusing, and the second, only slightly. Let's back up slightly. You have: * A future. You can call poll on a future, and it will return you either "no…

This is an awesome rundown of the whole stack. It's almost like you've explained this stuff before. ;)

It might sound complicated, but for typical applications almost all of this happens "under the hood". Usually you'll just add an attribute to `main` to start your runtime, then you can compose/await futures without ever needing to think about `poll` and friends.

Here's a small example: https://tokio.rs/tokio/tutorial/hello-tokio.

Re: Tokio 1.0 – async runtime for Rust

#387

Post by jeff-davis »

megaman821 wrote: post #380
jeff-davis wrote: post #309

Earlier quoted context omitted.

Async seperates the concurrency from the runtime completely. You have code that returns a Future, and creates more Futures along the way. None of this imposes any constraint on the runtime, except that you need some runtime to evaluate the future. But that runtime could be quite simple and execute in the current process/thread (cf. the CurrentThread runtime), meaning you don't need support for threads at all. Contras…

That is an interesting positive for async/await that I had not heard before. Why are there so many libraries that depend on Tokio then? If only the edges need to actually use an async runtime, the middle-tier libraries can just be plain futures.

Because the standard library (and a lot of other libraries) are mostly blocking. You can't use blocking code effectively with async.

In other words with async you have to use code that knows how to yield, but the benefit is that you have a lot of flexibility in the runtime. That means you can scale up, scale down, and fit it into weird environments (like in other programs that aren't expecting concurrency).

Threading (or process model) has a lot of upside though, too. For one, it's pre-emptive, so scheduling can be more "fair". For another, it's a lot easier to debug (erlang does a great job here).

I'd generally default to using threads, unless I have a specific reason for async and/or the code is fairly low-level and might be used in a variety of environments.

Disclaimer: don't take my claims as authoritative. I know a few things from seeing what works and not, but I could be wrong on some of the finer points.

Re: Tokio 1.0 – async runtime for Rust

#388

Post by pjmlp »

skohan wrote: post #381
pjmlp wrote: post #378

Earlier quoted context omitted.

Cargo also has issues when two crates have incompatible dependencies, or at very least you end with the same crate being compiled a couple of times, as the hashes don't match up. Usually when compiling from source many libraries provide pkg-config configuration files on "make install".

But with Cargo it's scoped to the crate you're compiling right? So it only matters if there's a collision in the dependencies of a given project. Isn't it the case with pkg-config that everything is stored in a central location? In any case, I think you can't seriously argue that the c/c++ dependency management solution is anywhere close to running `cargo build`/`cargo run` in terms of simplicity.

Yes I surely can, because Conan and vcpkg do exist, and contain all major well known libraries in the C and C++ communities.

Specially the C++ community has seen lack of something like cargo as weaknesses and moved to sort it out.

Re: Tokio 1.0 – async runtime for Rust

#389

Post by bogeholm »

steveklabnik wrote: post #32
olalonde wrote: post #30

Earlier quoted context omitted.

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.

Steve, just want to say thanks for your dedication - I find you’re always around when there’s a Rust thread on HN

Re: Tokio 1.0 – async runtime for Rust

#390

Post by steveklabnik »

bogeholm wrote: post #389
steveklabnik wrote: post #32

Earlier quoted context omitted.

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.

Steve, just want to say thanks for your dedication - I find you’re always around when there’s a Rust thread on HN

You’re welcome!
Post reply on HN