Tokio 1.0 – async runtime for Rust • Hacker News Board

Re: Tokio 1.0 – async runtime for Rust

#371

Post by vips7L » Thu, Dec 24, 2020, 3:49 PM UTC

varajelle wrote: post #343

akvadrako wrote: post #94

Earlier quoted context omitted.

There are some pretty bad usability problems with most async APIs too. One is they make your functions colored; async functions world best with other async functions while normal blocking functions work best with other blocking functions. They also introduce a lot of noise; putting async/await everywhere doesn't tell you anything interesting. Considering a normal-sized Linux server can handle a million threads withou…

> One is they make your functions colored I don't get what's so bad about "colored" function. That color is just about the return type of the function. How do you return an error from a function that does not return a Result? You must call unwrap (panic) or change the colour of your function by changing the return type to Result and fix all the caller. Similarly, if you want to use a future from a non-async function,…

I think you've made me realize why I don't enjoy Rust. Every function is colored.

Re: Tokio 1.0 – async runtime for Rust

#372

Post by mratsim » Thu, Dec 24, 2020, 4:01 PM UTC

timClicks wrote: post #187

btrask wrote: post #179

Earlier quoted context omitted.

Wait, what? What happened to "fearless concurrency"? I thought this was supposed to be one of the borrow checker's selling points! https://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.h...

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.

Re: Tokio 1.0 – async runtime for Rust

#373

Post by dboreham » Thu, Dec 24, 2020, 4:02 PM UTC

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…

> An async system which poisons the rest of my code to force async usage doesn't seem like it will scale to code leveraging multiple libraries and will likely fail at the first lib where the author decided not to bother.

You are quite correct. This happens.

Re: Tokio 1.0 – async runtime for Rust

#374

Post by mratsim » Thu, Dec 24, 2020, 4:04 PM UTC

pvorb wrote: post #190

nialv7 wrote: post #138

Earlier quoted context omitted.

I don't quite understand why one would find async code hard to read. Basically if you just ignore the async/await keyword, the code should read mostly the same as synchronous code (which is the point of the async/await effort). Maybe you have a concrete example of convoluted async code?

While it might not be that hard to read, it can certainly be harder to reason about.

Concurrent code is hard to reason about in general: async or threading included.

Re: Tokio 1.0 – async runtime for Rust

#375

Post by dboreham » Thu, Dec 24, 2020, 4:06 PM UTC

There seems to be some time loop with network application concurrency approaches. I began my career re-writing servers that had a non-blocking socket model with a state machine to use threads, so we could understand and maintain the code now that OS vendors had come around to supporting threading widely. Fast forward a few decades and the world is teeming with smart people who seem to think it's a good idea to go the other way..

Re: Tokio 1.0 – async runtime for Rust

#376

Post by heavenlyblue » Thu, Dec 24, 2020, 4:07 PM UTC

dboreham wrote: post #375

There seems to be some time loop with network application concurrency approaches. I began my career re-writing servers that had a non-blocking socket model with a state machine to use threads, so we could understand and maintain the code now that OS vendors had come around to supporting threading widely. Fast forward a few decades and the world is teeming with smart people who seem to think it's a good idea to go the…

What you were looking though was a syntax to program those things rather than the specific implementation.

Re: Tokio 1.0 – async runtime for Rust

#377

Post by mratsim » Thu, Dec 24, 2020, 4:11 PM UTC

pizza234 wrote: post #67

pfraze wrote: post #8

Can 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?

AFAIK, the major component is the scheduler. Rust can't really implement green threading (imagine Golang) by default, because it requires the runtime to be bundled in the executable, and the code to be compiled in a specific way to be managed by the scheduler. I actually find amusing the thought that _this_ is systems programming. In a low level language one can implement the functionality of a higher level language…

Both Rust and Go used to have green threads i.e. stackful coroutines / fibers that installed their own execution stack and switched to it.

However everyone who ever did green threads ended up having a lot of difficulties with stack optimization: - Go: https://docs.google.com/document/d/1wAaf1rYoM4S4gtnPh0zOlGzW... - Rust: https://mail.mozilla.org/pipermail/rust-dev/2013-November/00... - Same for Java in the past.

Now only Go is left.

More on fibers woes from the C++ point of view: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p136...

Re: Tokio 1.0 – async runtime for Rust

#378

Post by pjmlp » Thu, Dec 24, 2020, 4:15 PM UTC

skohan wrote: post #366

pjmlp wrote: post #363

Earlier quoted context omitted.

Dependencies are relatively easy, actually. Just most don't bother learning how to do it, and do it PHP style with header includes. On UNIX systems just using pkg-config and similar tools, or just adopt either conan or vcpkg, which contrary to cargo also support binary libraries out of the box. Plus vendoring C and C++ libraries is not a dark science, only known by old druids.

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

Re: Tokio 1.0 – async runtime for Rust

#379

Post by mratsim » Thu, Dec 24, 2020, 4:15 PM UTC

olliej wrote: post #281

octoberfranklin wrote: post #278

Earlier quoted context omitted.

Rust doesn't have a runtime. That's part of its awesomeness. That's why it can target microcontrollers. You're probably used to languages with garbage collectors. Having garbage collection forces you to have a "runtime" since that's where the GC code goes. Then more and more stuff accretes onto this unavoidable runtime, and before you know it you're writing Java code...

Um, rust does have a runtime, that's why you don't need to include packages for strings, refcounting, allocation, etc. Anything that has a language keyword should have a default implementation in that runtime, and much like box, ?, !, etc async and await are both language features that I shouldn't need to include from outside of the runtime.

I think you are confusing a standard library with a runtime.

A runtime is something you need to start before being able to use a language (typically a garbage collector, an event loop, a threadpool or a VM)

Re: Tokio 1.0 – async runtime for Rust

#380

Post by megaman821 » Thu, Dec 24, 2020, 4:33 PM UTC

jeff-davis wrote: post #309

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…

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.