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

#301

Post by riku_iki » Fri, Sep 08, 2023, 8:56 PM UTC

marcosdumay wrote: post #41

ilyt wrote: post #28

Promise/Future style of async is just a bad idea regardless of language. It was used because of ineptitude of languages where it become popular, and its far easier to implement into GC-less languages than message-passing-based asynchronous, but it's just misery to write code in. I'd prefer to suffer Go ineptitudes just to use bastardised message passing called channels there rather than any of the Python/JS/Rust asyn…

Yes. That atomized model of concurrency where your state goes everywhere and you somehow collect it back at some point was always (literally) the textbook example of how not to do it. It was created to be an improvement over the Javascript situation, and somehow every language that had a sane structure adopted it as if it was not only good, but the way to do things. This is insane.

> concurrency where your state goes everywhere and you somehow collect it back at some point was always (literally) the textbook example of how not to do it.

can you tell why it is not how not to do it in your opinion? What are the obvious issues with this approach?

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

#302

Post by SpaghettiCthulu » Fri, Sep 08, 2023, 8:56 PM UTC

jeroenhd wrote: post #98

divyekapoor wrote: post #80

We do not want red and blue functions. Any language that implements async / await as coroutines instead of green threads is making a fundamental CS mistake. https://journal.stuffwithstuff.com/2015/02/01/what-color-is-... Concurrency's correct primitive is Hoare's Communicating Sequential Processes mapped onto green threads. Some languages that have it right are Java (since JDK17 - Java Virtual Threads), Go, Kotlin.

Virtual threading is fun and all until you find out SimpleDateFormat and a bunch of other classes built tight into your standard library aren't thread safe and now you need to go through your program and find out what else you missed. Go too has these fancy green threads at the cost of manually locking resources and finding out about race conditions when you forget about them. Futures aren't a fundamental CS mistake,…

> Virtual threading is fun and all until you find out SimpleDateFormat and a bunch of other classes built tight into your standard library aren't thread safe and now you need to go through your program and find out what else you missed. Go too has these fancy green threads at the cost of manually locking resources and finding out about race conditions when you forget about them.

Why would that ever be an issue? Instances of those classes shouldn't be shared between virtual threads just the same as when using regular threads.

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

#303

Post by geodel » Fri, Sep 08, 2023, 8:57 PM UTC

grug_htmx_dev wrote: post #109

HippoBaro wrote: post #89

Earlier quoted context omitted.

The argument here is that Rust chose to implement coroutines the wrong way. It went the route of stackless coroutines that need async/await and colored functions. This creates all the friction the article laments over. But it also praises Go for its implementation, which is also based on a coroutine of a different kind. Stackful coroutines, which do not have any of these problems. Rust considered using those (and, at…

Threads are driven by the OS. Something needs to drive couritines, so there's no way around needing some (even rudimentary, like in embedded) executor. But to be a versatile and universal systems language, Rust can't just build-in executor into a language. I think that stackless coroutines are better than stackfull, in particular for Rust. Everything was done correctly by the Rust team. Again, this is all fair and go…

Well people who jumped on async bandwagon are deeply involved in Rust community. So if they do something, others have to assume they are doing it right.

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

#304

Post by nailer » Fri, Sep 08, 2023, 9:02 PM UTC

> We want to use the whole computer. Code runs on CPUs, and in 2023, even my phone has eight of the damn things. If I want to use more than 12% of the machine, I need several cores.

Er, no. That’s not what those words mean.

“We want to use the whole computer. Code runs on CPU cores, and in 2023, even my phone has eight of the damn things. If I want to use more than 12% of the machine, I need several threads.”

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

#305

Post by jayd16 » Fri, Sep 08, 2023, 9:03 PM UTC

bluGill wrote: post #174

colejohnson66 wrote: post #66

Earlier quoted context omitted.

Or desktop programs. Many GUI frameworks have a main thread that updates the layout (among other things) and various background ones.

Async and GUI threads are different concepts. Of course most GUIs have an event loop which can be used as a form of async, but with async you do your calculations in the main thread, while with GUIs you typically spin your calculations off to a different thread. Most often when doing async you have a small number of tasks repeated many times, then you spin up one thread per CPU, and "randomly" assign each task as it…

Hmm I would say the concepts are intertwined. Lots of GUI frameworks use async/await and the GUI thread is just another concurrency pattern that adds lock free thread exclusivity to async tasks that are pinned to a single thread.

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

#306

Post by winrid » Fri, Sep 08, 2023, 9:06 PM UTC

Animats wrote: post #275

winrid wrote: post #260

Earlier quoted context omitted.

I don't have anything recorded from the past few years. Here's an old video: https://youtu.be/L7XIFC2SawY?si=qN7TNxZi-P05uXVa It's basically a custom 3D multithreaded OSM renderer, and the assets are a custom binary format. Uses very little network bandwidth. Hoping to have an update this year that shows the updated graphics. I wrote a UI framework to improve my productivity (live hot reloading of UI components writt…

Nice. The "many UI" problem is large in Rust. Egui needs far too much Rust code per dialog box. Someone was working on a generator, but I haven't looked in on that project in a while.

I actually quite liked egui. It was Rust that felt too slow to write. Also the egui template project with eframe and no app code yet took 15 seconds for an incremental compile. The entire game so far compiles and starts faster than that in Java, so...

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

#307

Post by brundolf » Fri, Sep 08, 2023, 9:12 PM UTC

Pauan wrote: post #276

brundolf wrote: post #221

Earlier quoted context omitted.

There's always a complexity cost even when there isn't a runtime cost. It just so happens that in Rust, the benefits tend to outweigh the costs

The whole point of an abstraction is to remove complexity for the user. So I assume you mean "implementation complexity" but that's irrelevant, because that cost only needs to be paid once, and then you put the abstraction into a crate, and then millions of people can benefit from that abstraction.

You've got a very narrow view that I'd encourage you to be more open-minded about

No abstraction is perfect. Every abstraction, when encountered by a user, requires them to ask "what does this do?", because they don't have the implementation in front of their eyes

This may be an easy question to answer- maybe it maps very obviously to a pattern or domain concept they already know, or maybe they've seen this exact abstraction before and just have to recall it

It may be slightly harder- a new but well-documented concept, or a concept that's intuitive but complex, or a concept that's simple but poorly-named

Or it may be very hard- a badly-designed abstraction, or one that's impossible to understand without understanding the entire system

But the simplest, most elegant, most intuitive abstraction in the world has nonzero cognitive cost. We abstract despite the cost, when that cost is smaller than the cost of not abstracting.

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

#308

Post by awused » Fri, Sep 08, 2023, 9:16 PM UTC

anonymoushn wrote: post #241

HippoBaro wrote: post #228

Earlier quoted context omitted.

As someone else said, it is not, strictly speaking, a bug. If your server receives a request that requires very computationally expensive work, is it okay to delay every other request on that core? That's probably not okay, and it'll show in your latency distribution. Folks would rather have every future time sliced so that other tasks get some CPU time in a ~fair way (after all, there is no concept of task priority…

Trying to solve the problem by frequently invoking signal handlers will also show in your latency distribution! I guess if someone wants to use futures as if they were goroutines then it's not a bug, but this sort of presupposes that an opinionated runtime is already shooting signals at itself. Fundamentally the language gives you a primitive for switching execution between one context and another, and the premise of…

>Trying to solve the problem by frequently invoking signal handlers will also show in your latency distribution!

So just like any other kind of scheduling? "Frequently" is also very subjective, and there are tradeoffs between throughput, latency, and especially tail latency. You can improve throughput and minimum latency by never preempting tasks, but it's bad for average, median, and tail latency when longer tasks starve others, otherwise SCHED_FIFO would be the default for Linux.

>I read the blog about this situation at https://tokio.rs/blog/2020-04-preemption which is equally baffling

You've misunderstood the problem somehow. There is definitely nothing about tokio (which uses epoll on Linux and can use io_uring) not responding in there. io_uring and epoll have nothing to do with it and can't avoid the problem: the problem is with code that can make progress and doesn't need to poll for anything. The problem isn't unique to Rust either, and it's going to exist in any cooperative multitasking system: if you rely on tasks to yield by themselves, some won't.

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

#309

Post by bboozzoo » Fri, Sep 08, 2023, 9:19 PM UTC

jzelinskie wrote: post #101

ncruces wrote: post #90

Earlier quoted context omitted.

And in the end, almost everything ends up using Mutex, RWMutex, WaitGroup, Once, and some channels that exist only to ever be closed (like Context.Done), and only if you need to select around them. It's great, but message passing it is not.

As a quite senior Go developer, I'd like to +1 this a ton. You're far more likely to have shocking edge cases unaccounted for when using channels. I consider every usage very, very carefully. Just like every other language, I think the ultimate solution is to build higher-level abstractions for concurrency patterns (e.g. errgroup) and, now that Go has generics, it's the right time to start building them. If you haven…

The first one is indeed non-obvious, but the remaining snippets presented as bugs would not pass a review unless hidden inside 1k+ LOC PRs. Some are so blatantly obvious (seriously for loop and not passing current value as variable?) that I'm surprised that authors have listed them as if they're somehow special.

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

#310

Post by Dinux » Fri, Sep 08, 2023, 9:20 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…

We've been building our robotic simulators in Rust for the past 3 years and I have the exact same experience. So far, I think, we've encountered maybe 5 actual runtime bugs over the last 3 years. Sure rust has some problems and yes the async isn't fully there yet, but overal the benefits outweigh the problems.