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

421–422 of 422 posts

Re: Tokio 1.0 – async runtime for Rust

#421

Post by volta87 »

tobz wrote: post #400
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. ¯\_(ツ)_/¯

I don't speak on behalf of them, I saw this on Twitter back when it happened, e.g., check Aaron Turon's twitter feed from back then.

Re: Tokio 1.0 – async runtime for Rust

#422

Post by jstrong »

simias wrote: post #405
jstrong wrote: post #323

Earlier quoted context omitted.

> just macro-decorate the main function, sprinkle some async/await around, maybe add a join or a mutex somewhere, and then pretty much forget all about event loops, messaging, threads and whatnot that is ... not how I have experienced it. I work on building highly concurrent systems every day but async drives me insane. to me the fundamental issue is that although the code now reads linearly, it no longer executes li…

You answered jgilias better than I could, I feel exactly the same way. Async is deceptively simple in my opinion, because while it looks arguably even simpler than an explicit state machine, it makes your program flow nonlinear and I find that a lot harder to work with. With blocking code I can mentally step through the code follow causes and consequences easily, with async I feel like I'm watching a scifi movie invo…

agree 100%. it honestly kind of baffles me, "async" is like the programming community's white whale, and all of us get to come along for the chase. meanwhile, I long ago grew accustomed to the paradigm of an "event loop" in my programs. after a certain point it becomes very natural. on the subject of memory, recently there was an issue where the async dyn futures were blowing up stacks because a resolved future was > 2mb - what!? I mean, look at the signatures in the aturon article - we are going from this

    fn read(&mut self, buf: &mut [u8]) -> Result
... to this ...

    fn read>(self, buf: T) ->
        impl Future
is that supposed to be easier?

I recently tried writing a small program that would manually poll a future to get a feel for it - utter disaster. conflicting versions of tokio, compiles but crashes because something is called outside of the tokio runtime context, etc. all the examples have #[tokio::main]-decorated main - it's like, I'm not giving you my #$(&#@(&ing main function! the programs I write have tons of stuff going on! I can't just give some library my entire control flow!

sorry for the rant! felt good to write it though.

Post reply on HN