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

391–400 of 422 posts

Re: Tokio 1.0 – async runtime for Rust

#391

Post by Animats »

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".

Yes. Rust encourages version pinning. You go to "crates.io", and it gives you a specific version number to put in your "cargo.toml" file. Now you're nailed to that version for your program or crate. Crates have their own "cargo.toml" file, with their own versions, and it's quite possible to pull in multiple versions.

Right now, I'm using the latest version of "reqwest" known to "crates.io." It's pulling in Tokio v0.2.23, not the new tokio v1.0.0. No surprise there, the new version only came out yesterday. So we'll see how the new version works at some time in the future.

It's good to get to version 1. The semantic versioning rules allow breaking changes without changing the first digit when the first digit is 0. Typical complaint on forums: "bignum happens to use rand internally, and it happens to only use version 0.5.0, with restrictions against using a higher version due to breaking changes." Rust still has many low-level crates at version 0.x.x, from "bytes" to "uuid". Reaching 1 indicates greater stability.

Re: Tokio 1.0 – async runtime for Rust

#392

Post by mst »

lumost wrote: post #234
mleo wrote: post #201

Earlier quoted context omitted.

I believe the idea is that within a project that uses async functionality, you should only use non-async functions when the logic does not call blocking functionality. If you are mixing async functionality and synchronous functions with/blocking I would consider the latter a defect unless it is handled properly within an asynchronous context.

I really don't understand the logic of this on a multi-threaded system. The vast majority of functions I write are best executed synchronously, the remainder is usually composed of logic wrapping heavy computations which can be executed in parallel or logic surrounding I/O which can be executed concurrently. An async system which poisons the rest of my code to force async usage doesn't seem like it will scale to code…

> logic surrounding I/O which can be executed concurrently.

That's the bit you'd use an async runtime for, in a (mostly) dedicated thread.

The heavy computations would be in other threads that aren't doing so.

Re: Tokio 1.0 – async runtime for Rust

#393

Post by NMDaniel »

simias wrote: post #77

I 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 tri…

You're talking about the runtime aspects of executing concurrent code (OS threads vs green threads) but these are orthogonal to the idea of async APIs, which are one way of modelling concurrent programming flows.

For example, futures in Rust can be used with both OS threads and lightweight tasks. Tokio is mostly agnostic about the choice of the executor.

It definitely takes some time to grok async Rust (even if you come from C#/JS), but I think it really shines once you get to know it, similar to the benefits you get from learning about iterators & higher level functions as opposed to plain loops.

For instance, I've recently implemented the Raft protocol as part of a distributed algorithms course. Using Tokio and a single threaded executor made the implementation fairly readable, mostly relying on few async constructs(futures, tasks, channels and select loops) to model fairly complex behavior (bidirectional messaging, multiple states, timeouts, etc..) Doing so in a more traditional callback oriented style would've required maintaining a very complex state machine(in addition to the state machine of the algorithm itself)

Also, Async/Await originated in C#, a language which already supports threads(and many other concurrency models), not JavaScript which historically relied on callbacks

Re: Tokio 1.0 – async runtime for Rust

#394

Post by slavik81 »

tijsvd wrote: post #318
slavik81 wrote: post #263

Earlier quoted context omitted.

> A non-async function is "regular logic", it must complete without blocking. What does 'blocking' mean? I would expect the definition of synchronous to be the exact opposite; i.e., a synchronous function must block the caller until the function has finished executing. For that matter, what is "regular logic"? The name implies there is some sort of "irregular logic" to contrast it with. I get the feeling that the wri…

Sorry for the wording, the term blocking is common in network programming. With blocking I mean waiting. For I/O to complete, for time to pass, or for another task to complete something. In event-based programming, functions must not block. Async functions may seem to block, but they don't rely because a state machine is involved.

That does answer my question, but I don't really understand why the distinction is made. To the caller, a function that spends time waiting and a function that spends the same time calculating both look the same, don't they?

Re: Tokio 1.0 – async runtime for Rust

#395

Post by pasabagi »

skohan wrote: post #336
tijsvd wrote: post #332

Earlier quoted context omitted.

But then that is nothing inherent to Rust, it's a choice made by a particular external library. That is probably the worst downside of async, it splits the ecosystem. Reqwest probably tries to offer both choices by hiding one behind the other (although what you describe sounds excessive - running a single task with tokio's single-threaded executor is actually quite lightweight). That split between "sync" and "async"…

> it's a choice made by a particular external library Yeah I think it points to a culture problem. In some ways because dependency management is so easy with Cargo, I think it creates the temptation to just throw in some dependencies to make something work without truly understanding the overall complexity of what you're creating. Something very similar happens in the NodeJS world. > it splits the ecosystem This is s…

I think rust is kind of a perfect language for being profligate with dependencies, because the safety guarantees, typing, etc make it very hard to misuse a library, and relatively easy to design a library that is hard to misuse.

A lot of what is not enjoyable about rust as a user is really nice when it's being imposed on people who are not you, whose work you're interfacing with.

Re: Tokio 1.0 – async runtime for Rust

#396

Post by josephg »

chrismorgan wrote: post #315
josephg wrote: post #192

Earlier quoted context omitted.

There is consensus in some ecosystems. Javascript absolutely maintains that invariant. There are (almost) no blocking functions in the javascript / node standard libraries and we work hard to keep it that way. Go maintains similar discipline at the OS syscall level. I feel like the "what color is your function" thing is incomplete. There are arguably 3 types of functions: - Functions which do all their work synchrono…

I have seen fs.*Sync functions being called deep in async-land more than once or twice in Node.

Those methods were added super early (node 0.2 or something) and can’t be removed because of backwards compatibility. Many of the core node team think they should never have been added - for that exact reason.

Re: Tokio 1.0 – async runtime for Rust

#397

Post by bsaul »

lmm wrote: post #362
sagichmal wrote: post #345

Earlier quoted context omitted.

> Shared-memory concurrency is pretty much always buggy, IME, even if your team thinks they're experts. Writing bug-free shared memory concurrency programs with Go is trivial. Your opinion is based on outdated information.

Go's whole approach to concurrency is about avoiding sharing memory; channels suspend in much the same way as async/await yield points.

I like go, but i don’t understand your point. Go seems to like passing pointers over channels, which is pretty far from avoiding shared memory. Unless you start writing code that looks like actor based concurrency, with channels used to pass messages acrross actors. But this isn’t what i’d call idiomatic go.

Re: Tokio 1.0 – async runtime for Rust

#398

Post by worik »

ibraheemdev wrote: post #15
worik wrote: post #13

The first two paragraphs have a lot of guarantees. About stability of version 1.0, length of support for version 1.0 and how long until version 2.0 (at least). "We "we are committing to providing a stable foundation..." I am curious: Who is "we"? I have no priors, I really have no idea.

The tokio maintainers and contributors

Well obviously, but that is not really an answer.

Perhaps it is not answerable but it is a important question, when guarantees are made, who is making them?

I am not sure it is a important question in that it is not a important guarantee. The software is what it is, it is open and modifiable. But if the guarantee mattered then this would be a crucial question and the answer would describe the organisational structure of the "tokio maintainers and contributors" as a group

Re: Tokio 1.0 – async runtime for Rust

#399

Post by steveklabnik »

mratsim wrote: post #372
timClicks wrote: post #187

Earlier quoted context omitted.

It's still fearless, as in you don't need to worry that you might create data races, but can be clunky to write in some cases.

If the borrow checker has no representation of a memory model, for example relaxed/acquire/release, you can't write a concurrent queue without triple checking for statement ordering, resulting barriers and then formally verify it otherwise you are very likely to introduce data races.

The borrow checker doesn’t understand orderings, as it doesn’t specifically need to. You can get race conditions, but not data races. Yes, you need to be careful when writing this kind of code.

Re: Tokio 1.0 – async runtime for Rust

#400

Post by tobz »

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…

Doesn't seem very productive to speak on behalf of two folks who you clearly don't have the authority to speak on behalf of. ¯\_(ツ)_/¯
Post reply on HN