Maybe Rust isn’t a good tool for massively concurrent, userspace software • Hacker News Board

Re: Maybe Rust isn’t a good tool for massively concurrent, userspace software

#581

Post by imetatroll » Sat, Sep 09, 2023, 10:56 PM UTC

Animats wrote: post #223

OK, I suppose I should write to this. As I've mentioned before, I'm writing a high performance metaverse client. Here's a demo video.[1] It's about 40,000 lines of Rust so far. If you are doing a non-crappy metaverse, which is rare, you need to wrangle a rather excessive amount of data in near real time. In games, there's heavy optimization during game development to prevent overloading the play engine. In a metavers…

Props on doing this work! That being said is it just me or does the video seem to stutter?

Re: Maybe Rust isn’t a good tool for massively concurrent, userspace software

#582

Post by imetatroll » Sat, Sep 09, 2023, 11:01 PM UTC

Pauan wrote: post #213

likeabbas wrote: post #181

Earlier quoted context omitted.

> async doesn’t imply multithreaded Async the keyword doesn’t, but Tokio forces all of your async functions to be multi thread safe. And at the moment, tokio is almost exclusively the only async runtime used today. 95% of async libraries only support tokio. So you’re basically forced to write multi thread safe code even if you’d benefit more from a single thread event loop. Rust async’s set up is horrid and I wish th…

No, tokio does not require your Futures to be thread-safe. Every executor (including tokio) provides a `spawn_local` function that spawns Futures on the current thread, so they don't need to be Send: https://docs.rs/tokio/1.32.0/tokio/task/fn.spawn_local.html I have used Rust async extensively, and it works great. I consider Rust's Future system to be superior to JS Promises.

How is the future system superior? Is this a case of the languages type constraints being better vs non-existent? Saying something is superior doesn't really add much.

I am genuinely asking because I have little formal background in CS so "runtimes" and actual low level differences between , for instance, async and green threads mystifies me. EG What makes them actually different from the "runtime" perspective?

Re: Maybe Rust isn’t a good tool for massively concurrent, userspace software

#583

Post by kprotty » Sat, Sep 09, 2023, 11:08 PM UTC

throw10920 wrote: post #569

kprotty wrote: post #530

Earlier quoted context omitted.

> what prevents it from ensuring that a runtime is present when it does? The runtime being a library instead of a language/compiler level feature. Custom runtimes is necessary for systems languages as they can have specialized constraints. EDIT: Note that it's the presence of a supported runtime for the async operation (e.g. it relies on runtime-specific state like non-blocking IO, timers, priorities, etc.), not only…

Thank you for your explanation of the trade-space around preemptible coroutines, that greatly helped my understanding. I am still unclear on one thing: > The runtime being a library instead of a language/compiler level feature. Custom runtimes is necessary for systems languages as they can have specialized constraints. Compilers link against dynamic libraries all the time. What prevents the compiler from linking agai…

This would imply a single/global runtime along with an unrealistic API surface;

For 1) It's common enough to have multiple runtimes in the same process, each setup possibly differently and running independently of each other. Often known as a "thread-per-core" architecture, this is the scheme used in apps focused on high IO perf like nginx, glommio, actix, etc.

For 2) runtime (libasync.so) implementations would have to cover a lot of aspects they may not need (async compute-focused runtimes like bevy don't need timers, priorities, or even IO) and expose a restrictive API (what's a good generic model for a runtime IO interface? something like io_uring, dpdk, or epoll? what about userspace networking as seen in seastar?). A pluggable runtime mainly works when the language has a smaller scope than "systems programming" like Ponylang or Golang.

As a side note; Rust tries to decouple the scheduling of Futures/tasks using its concept of Waker. This enables async implementations which only concern themselves with scheduling like synchronization primitives or basic sequencers/orchestration to be runtime-agnostic.

Re: Maybe Rust isn’t a good tool for massively concurrent, userspace software

#584

Post by likeabbas » Sat, Sep 09, 2023, 11:14 PM UTC

withoutboats3 wrote: post #577

likeabbas wrote: post #541

Earlier quoted context omitted.

Can you admit that you failed in making it a pleasant experience to write async, especially for library authors? I don’t think it’s too late to admit failure and implement something like May https://github.com/Xudong-Huang/may

no, I don't admit that, and I think you're an enormous asshole

Async await is polluting rust. What was once my favorite language is now a pain in the ass. And I am not the only person who feels this way. There’s no shame in pivoting

Re: Maybe Rust isn’t a good tool for massively concurrent, userspace software

#585

Post by ilyt » Sun, Sep 10, 2023, 12:21 AM UTC

seabrookmx wrote: post #392

marcosdumay wrote: post #317

Earlier quoted context omitted.

The C# implementation is clearly an attempt of putting type-safety over exactly the same implementation JS promises use. Done because MS wanted to port the same behavior.

I honestly can't tell if you're trolling. - the C# implementation predates even Promises in JS, so it is not "the same implementation" and your implication that C# was inspired by JS as opposed to the other way around is false. More background: [0] - Typescript works fine with the JS implementation so any differences aren't for type safety reasons, but largely because C# has a multithreaded event loop unlike JS Also…

You're implying people went from writing C# to JS code willingly and not just wrote it but went on "improving" the ecosystem and I just don't believe there are people insane enough to do it willingly so "it was invented separately in both instances" is far more likely.

Re: Maybe Rust isn’t a good tool for massively concurrent, userspace software

#586

Post by rcxdude » Sun, Sep 10, 2023, 12:47 AM UTC

tgv wrote: post #523

rcxdude wrote: post #504

Earlier quoted context omitted.

There are many such primitives in Rust (including one in the standard library). And it's effectively the default, the only annoying thing is the libraries which use async (it is possible to just wrap the async code in sync code, just a little annoying. But I think it's what most users of the language should do.)

But "most" users can live with a bit of overhead in return for safe parallelism. It's just a handful that wants to squeeze the last bit of power out of a CPU. The other day, Intel revealed a processor with 66 thread support per core. 64 of those threads were called "slow", because there's no prefetching and speculative execution, as they are supposed to be waiting (mainly for memory, but networking could be another o…

That is my point. For most people just using synchronous code with threads is the best option. Async only shines if you really want to push your I/O relative to your compute (which is becoming more of a challenge on modern hardware as I/O bandwidth is rapidly expanding compared to compute), or if you need to keep track of an extremely large number of tasks with low memory overhead. Starting off with "I'm writing a network application, I should use async" is likely already a mistake, especially in Rust.

Re: Maybe Rust isn’t a good tool for massively concurrent, userspace software

#587

Post by jayd16 » Sun, Sep 10, 2023, 2:49 AM UTC

lelanthran wrote: post #578

jayd16 wrote: post #553

Earlier quoted context omitted.

I'm referring to the situation where a synchronous wait consumes the thread pool, preventing any further work. A is sychrounously waiting B which is awaiting C which could complete but never gets scheduled because A is holding onto the only thread. Its a very common situation when you mix sync and async and you're working in a single threaded context, like UI programming with async. Of course it can also cause starva…

That's an implementation problem, not a problem with the concept of asynchronous execution, and it's specifically a problem in only one popular implementation: Javascript in the browser without web-workers. That's specifically why I called it a Leaky Abstraction in my first post on this: too many people are confusing a particular implementation of asynchronous function calls with the concept of asynchronous function…

I don't see how it can be an implementation detail when fundamentally you must yield execution when the programmer has asked to retain execution.

Besides Javascript, its also a common problem in C# when you force synchronous execution of an async Task. I'm fairly sure its a problem in any language that would allow an async call to wait for a thread that could be waiting for it.

I really can't imagine how your proposed syntax could work unless the synchronous calls could be pre-empted, in which case, why even have async/await at all?

But I look forward to your implementation.

Re: Maybe Rust isn’t a good tool for massively concurrent, userspace software

#588

Post by cdelsolar » Sun, Sep 10, 2023, 2:51 AM UTC

Pauan wrote: post #150

dralley wrote: post #36

Earlier quoted context omitted.

In the sense that green threads are easier, sure. But green threads were not and are not the right solution for Rust, so it's kind of beside the point. Async Rust is difficult, but it will eventually be possible to use Async Rust inside the Linux kernel, which is something you can't do with the Go approach.

Rust Futures are essentially green threads, except much lighter-weight, much faster, and implemented in user space instead of being built-in to the language. Basically Rust Futures is what Go wishes it could have. Rust made the right choice in waiting and spending the time to design async right .

ok lol

Re: Maybe Rust isn’t a good tool for massively concurrent, userspace software

#589

Post by kelnos » Sun, Sep 10, 2023, 3:54 AM UTC

jstx1 wrote: post #280

Animats wrote: post #223

OK, I suppose I should write to this. As I've mentioned before, I'm writing a high performance metaverse client. Here's a demo video.[1] It's about 40,000 lines of Rust so far. If you are doing a non-crappy metaverse, which is rare, you need to wrangle a rather excessive amount of data in near real time. In games, there's heavy optimization during game development to prevent overloading the play engine. In a metavers…

> Yes, sometimes you can get stuck for a day, trying to express something within the ownership rules. This is a big problem. Fast iteration time is very valuable. And who likes doing this to themselves anyway? Isn't it a very frustrating experience? How is this the most loved language?

I agree that fast iteration time is valuable, but I don't think this has to hold 100% of the time.

I would much rather bang my head against a compiler for N hours, and then finally have something that compiles -- and thus am fairly confident works properly -- than have something that compiles and runs immediately, but then later I find I have to spend N hours (or, more likely, >N hours) debugging.

Your preferences may differ on this, and that's fine. But in the medium to long term, I find myself much more productive in a language like Rust than, say, Python.

Re: Maybe Rust isn’t a good tool for massively concurrent, userspace software

#590

Post by kelnos » Sun, Sep 10, 2023, 4:00 AM UTC

throw10920 wrote: post #406

jstx1 wrote: post #280

Earlier quoted context omitted.

> Yes, sometimes you can get stuck for a day, trying to express something within the ownership rules. This is a big problem. Fast iteration time is very valuable. And who likes doing this to themselves anyway? Isn't it a very frustrating experience? How is this the most loved language?

> How is this the most loved language? Personal preference and pain tolerance. Just like learning Emacs[1] - there's lots of things that programmers can prioritize, ignore, enjoy, or barely tolerate. Some people are alright with the fact that they're prototyping their code 10x more slowly than in another language because they enjoy performance optimization and seeing their code run fast, and there's nothing wrong wit…

> Some people are alright with the fact that they're prototyping their code 10x more slowly than in another language because they enjoy performance optimization and seeing their code run fast, and there's nothing wrong with that.

I look at it a little differently: I'm fine with the fact that I'm prototyping my code 10x more slowly (usually the slowdown factor is nowhere near that bad, though; I'd say sub-2x is more common) than in another language because I enjoy the fact that when my code compiles successfully, I know there are a bunch of classes of bugs my code just cannot have, and this wouldn't be the case if I used the so-called "faster development" language.

I also hate writing tests; in a language like Rust, I can get away with writing far fewer tests than in a language like Python, but have similar confidence about the correctness of the code.