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

Monoio – A thread-per-core Rust async runtime with io_uring

github.com

Post reply on HN
Print view View original

61–70 of 84 posts

Re: Monoio – A thread-per-core Rust async runtime with io_uring

#61

Post by masklinn »

billconan wrote: post #53

I have a stupid question, why isn't an async runtime a language feature of rust? we don't seem to see so many async runtimes in other languages? They seem to have a default way to run async tasks?

> I have a stupid question, why isn't an async runtime a language feature of rust?

Because it was considered inimical to the core values and purpose of the language, which is to be a systems language.

An async runtime being a language feature means a runtime is a language feature, and that is very much undesirable (in fact it used to be part of the language and was removed as it "settled" into its niche from its original design, which was much higher level and more applicative).

Re: Monoio – A thread-per-core Rust async runtime with io_uring

#62

Post by jsty »

staticassertion wrote: post #58
aneutron wrote: post #30

Earlier quoted context omitted.

I think you're being sarcastic, but I'm not totally sure.

I'm honestly not. Desktop platforms like Windows are incredibly niche. How much rust software actually runs on those? Some, of course. But probably an incredible minority. Supporting them is smart because people expect it, and not supporting it would be bad optics, but if a language legitimately only targeted Linux, and was better for it, I'd be fine with that - they target the most popular OS by far .

> How much rust software actually runs on those?

Some of rust's most well-known and widely distributed success stories for a start - Firefox & Dropbox

Re: Monoio – A thread-per-core Rust async runtime with io_uring

#63

Post by steveklabnik »

staticassertion wrote: post #58
aneutron wrote: post #30

Earlier quoted context omitted.

I think you're being sarcastic, but I'm not totally sure.

I'm honestly not. Desktop platforms like Windows are incredibly niche. How much rust software actually runs on those? Some, of course. But probably an incredible minority. Supporting them is smart because people expect it, and not supporting it would be bad optics, but if a language legitimately only targeted Linux, and was better for it, I'd be fine with that - they target the most popular OS by far .

I am a Windows user, so all of the Rust software I use runs on it. And that’s virtually all Rust software. Sometimes you need a small patch or two because someone did something weird with path handling, but 99.99% of it Just Works.

Apparently we haven't published platform statistics since 2019, but according to that years' survey: https://blog.rust-lang.org/images/2020-03-RustSurvey/32-what...

* 55% of Rust users develop on Linux

* 24% develop on Windows

* 23% develop on macOS

So yeah Linux was the most popular, but dropping effectively half of your users isn't always a great idea. Of course, some people will build OS-specific software in Rust, and that's great! But it is a tradeoff you're making.

Re: Monoio – A thread-per-core Rust async runtime with io_uring

#64

Post by seg_lol »

steveklabnik wrote: post #63
staticassertion wrote: post #58

Earlier quoted context omitted.

I'm honestly not. Desktop platforms like Windows are incredibly niche. How much rust software actually runs on those? Some, of course. But probably an incredible minority. Supporting them is smart because people expect it, and not supporting it would be bad optics, but if a language legitimately only targeted Linux, and was better for it, I'd be fine with that - they target the most popular OS by far .

I am a Windows user, so all of the Rust software I use runs on it. And that’s virtually all Rust software. Sometimes you need a small patch or two because someone did something weird with path handling, but 99.99% of it Just Works. Apparently we haven't published platform statistics since 2019, but according to that years' survey: https://blog.rust-lang.org/images/2020-03-RustSurvey/32-what... * 55% of Rust users dev…

Neat! Thanks for admitting you use Windows.

Perhaps MS could pay for crater runs on Windows? Are crater runs done on Windows now?

Looks like yes, https://github.com/rust-lang/crater/blob/master/docs/agent-m...

Re: Monoio – A thread-per-core Rust async runtime with io_uring

#65

Post by steveklabnik »

seg_lol wrote: post #64
steveklabnik wrote: post #63

Earlier quoted context omitted.

I am a Windows user, so all of the Rust software I use runs on it. And that’s virtually all Rust software. Sometimes you need a small patch or two because someone did something weird with path handling, but 99.99% of it Just Works. Apparently we haven't published platform statistics since 2019, but according to that years' survey: https://blog.rust-lang.org/images/2020-03-RustSurvey/32-what... * 55% of Rust users dev…

Neat! Thanks for admitting you use Windows. Perhaps MS could pay for crater runs on Windows? Are crater runs done on Windows now? Looks like yes, https://github.com/rust-lang/crater/blob/master/docs/agent-m...

Not just that, but like, https://github.com/microsoft/windows-rs. Microsoft is a member of the Rust Foundation. etc etc.

Re: Monoio – A thread-per-core Rust async runtime with io_uring

#66

Post by staticassertion »

jsty wrote: post #62
staticassertion wrote: post #58

Earlier quoted context omitted.

I'm honestly not. Desktop platforms like Windows are incredibly niche. How much rust software actually runs on those? Some, of course. But probably an incredible minority. Supporting them is smart because people expect it, and not supporting it would be bad optics, but if a language legitimately only targeted Linux, and was better for it, I'd be fine with that - they target the most popular OS by far .

> How much rust software actually runs on those? Some of rust's most well-known and widely distributed success stories for a start - Firefox & Dropbox

Yeah, obviously. It would be stupid to not support Windows in order for rust to be a healthy language. But I wouldn't care at all, and the vast majority of code - not just the code written, but in terms of it being deployed to N systems - will be Linux.

Re: Monoio – A thread-per-core Rust async runtime with io_uring

#67

Post by staticassertion »

steveklabnik wrote: post #63
staticassertion wrote: post #58

Earlier quoted context omitted.

I'm honestly not. Desktop platforms like Windows are incredibly niche. How much rust software actually runs on those? Some, of course. But probably an incredible minority. Supporting them is smart because people expect it, and not supporting it would be bad optics, but if a language legitimately only targeted Linux, and was better for it, I'd be fine with that - they target the most popular OS by far .

I am a Windows user, so all of the Rust software I use runs on it. And that’s virtually all Rust software. Sometimes you need a small patch or two because someone did something weird with path handling, but 99.99% of it Just Works. Apparently we haven't published platform statistics since 2019, but according to that years' survey: https://blog.rust-lang.org/images/2020-03-RustSurvey/32-what... * 55% of Rust users dev…

I'm only saying it's a tradeoff. Obviously given Rust's origins and goals dropping desktop as a target would make no sense - it was designed explicitly for those platforms.

But if a language said "we're not going to support those" I wouldn't care at all, and a massive number of use cases - the majority, I think - would be solved with that language.

In terms of what you develop on, that's a whole other story. The majority, of course, are on Linux. But I'd be interested to know what platform they target.

Re: Monoio – A thread-per-core Rust async runtime with io_uring

#69

Post by jkelleyrtp »

asymptotic wrote: post #51
jkelleyrtp wrote: post #47

It's exciting to see another thread-per-core async runtime for Rust. It's truly understated how difficult the Send + Sync requirements in Tokio are for writing regular code. It's typically rare for async tasks in Tokio to be used across two threads simultaneously, but now all of your data must be Send+Sync. Plus, Tokio is unique in that it's one of the very few runtimes in existence that's work-stealing (meaning the…

> the best you can do is write a thread pool that spawns a Tokio LocalSet to run !Send futures Can you go into this a bit more or provide a code reference? I'm new to writing async Rust code and am interested in this idea.

Yeah, it's actix-web's runtime.

I brought it up to tide's maintainers and got a bunch relevant links. Feel free to click through the tide issue for more context.

- https://github.com/http-rs/tide/issues/837

- https://github.com/rust-lang/wg-async-foundations/issues/87

- https://github.com/rust-lang/wg-async-foundations/issues/128

Re: Monoio – A thread-per-core Rust async runtime with io_uring

#70

Post by jkelleyrtp »

masklinn wrote: post #57
jkelleyrtp wrote: post #47

It's exciting to see another thread-per-core async runtime for Rust. It's truly understated how difficult the Send + Sync requirements in Tokio are for writing regular code. It's typically rare for async tasks in Tokio to be used across two threads simultaneously, but now all of your data must be Send+Sync. Plus, Tokio is unique in that it's one of the very few runtimes in existence that's work-stealing (meaning the…

> It's truly understated how difficult the Send + Sync requirements in Tokio are for writing regular code. It's typically rare for async tasks in Tokio to be used across two threads simultaneously, but now all of your data must be Send+Sync. https://docs.rs/tokio/1.14.0/tokio/task/fn.spawn_local.html > Plus, Tokio is unique in that it's one of the very few runtimes in existence that's work-stealing (meaning the task…

Quoting from a reply on an issue in the rust async-wg repo:

> Are people doing this? Does it work? :)

> Kind of every single successful async framework since the inception of eventloops :-)

> libevent, libev, libuv, boost asio, GTK, QT, seastar, nginx, javascript + node.js, dpdk, netty, grizzly, dart, etc.

> Besides Rust the main frameworks which tried to do move tasks between executors are Go and C#'s Threadpool executor (although I think the ASP.NET default executor might have fixed threads).

> Therefore the state of the world is actually more that Rust would need to prove that its approach of defaulting to thread-safe is a viable alternative than questioning the effectiveness of single-threaded eventloops. Their effectiveness in terms of reducing context switches and guaranteeeing good cache hit rates was more or less what triggered people to move towards the model, despite the ergonomic challenges of using callbacks.

Post reply on HN