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

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

bitbashing.io

Post reply on HN
Print view View original

71–80 of 624 posts

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

#71

Post by Cu3PO42 »

radlad wrote: post #33
Cu3PO42 wrote: post #24

Earlier quoted context omitted.

I really like the message passing paradigm. And languages like Erlang have shown that its an excellent choice... for distributed systems. But writing code like that is a very diffferent experience from, say, async JavaScript, which feels more like writing synchronous code with green threads (except you have to deal with function coloring as well). I believe people will try to write code in a way that is already famil…

Go also uses goroutines and channels to facilitate message passing, or as they describe it, "sharing memory by communicating." I imagine Rust to be a language far more similar to Go, in both use cases and functionality, than JS.

> I imagine Rust to be a language far more similar to Go, in both use cases and functionality, than JS.

I mostly agree. But I would wager that for a significant amount of people their first exposure to "async" is JS and not any number of other languages. And when you try to write async Rust the same way as you might write async JS, things just aren't that pretty.

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

#72

Post by brundolf »

fnordpiglet wrote: post #42
lordnacho wrote: post #9

I find myself in this weird corner when it comes to async rust. The guy's got a point in that doing a bunch of Arc, RwLock, and general sharing of state is going to get messy. Especially once you are sprinkling 'static all over the place, it infects everything, much like colored functions. I did this whole thing once back when I was starting off where I would Arc stuff, and try to be smart about borrow lifetimes. Tot…

I find the criticisms a little strange - async doesn’t imply multithreaded, and you don’t need to annotate everything shared with magic keywords if you’re async within the same thread because there’s no sharing. Only one future at a time is running on the thread and they’re within the same context. When moving between threads I do what you suggest here and use channels to send signals rather than having a lot of shar…

> Sometimes there is a crucial global state something that’s easier to just directly access, but I just write struct that manages all the Arc/RwLock or whatever other exclusive access mechanism I need for the access patterns. From the callers point of view everything is just a simple function call. When writing the struct I need to be thoughtful of sharing semantics but it’s a very small struct and I write it once and move on.

This is a recurring pattern I've started to notice with Rust: most things that repeatedly feel clunky, or noisy, or arduous, can be wrapped in an abstraction that allows your business logic to come back into focus. I've started to think this mentality is essential to any significant Rust project.

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

#73

Post by ansible »

tiberriver256 wrote: post #53

Anyone with electrical engineering know if pata vs. sata cables is a good analogy for async vs. sync? I know parallel ATA cables were all the rage. They had a higher theoretical throughput when compared with serial ATA cables but there was too much cross-talk involved to make it actually faster in the end so now we have serial ATA cables everywhere with much higher throughput than parallel ATA cables could ever achie…

We're dealing with fundamental limitations of I/O though, which is causing the delays.

I want to write stuff to disk (SSD these days). I can issue a request, then have to wait tens to hundreds of milliseconds (in the average case, the worst case can be far longer) for that request to finish and let me know that my I/O request succeeded or failed. There's no getting around that with present-day technology.

The situation is worse and even less reliable with network I/O. If you are talking to a server in another continent, the speed of light determines the minimum of time I hear back from it, even if it (and all the intermediary network links) are lightly loaded and functioning perfectly.

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

#74

Post by marcosdumay »

efficax wrote: post #52
stallmanwasrigh wrote: post #39

> At this scale, threads won’t cut it—while they’re pretty cheap, fire up a thread per connection and your computer will grind to a halt. Maybe in the 2000's but I feel this reasoning is no longer valid in 2023 and should be put to rest. 10k problem.. Wouldn't modern computing not work if my Linux box couldn't spin up 10k threads? Htop says I'm currently at 4,000 threads on an 8 core machine.

The context switch for threads remains very expensive. You have 4,000 threads but that's lots of different processes spinning up their own threads. it's still more efficient to have one thread per core for a single computational problem, or at most one per CPU thread (often 2 threads per core now). You can test this by using something like rayon or GNU parallel using more threads than you have cores. It won't go fast…

Since that time, context switching changed from a O(log(n)) operation to an O(1) one.

I have no doubt that having a thread per core and managing the data with only non-blocking operations is much faster. But I'm pretty current machines can manage a thousand or so threads locked almost the entire time just fine.

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

#75

Post by lossolo »

efficax wrote: post #52
stallmanwasrigh wrote: post #39

> At this scale, threads won’t cut it—while they’re pretty cheap, fire up a thread per connection and your computer will grind to a halt. Maybe in the 2000's but I feel this reasoning is no longer valid in 2023 and should be put to rest. 10k problem.. Wouldn't modern computing not work if my Linux box couldn't spin up 10k threads? Htop says I'm currently at 4,000 threads on an 8 core machine.

The context switch for threads remains very expensive. You have 4,000 threads but that's lots of different processes spinning up their own threads. it's still more efficient to have one thread per core for a single computational problem, or at most one per CPU thread (often 2 threads per core now). You can test this by using something like rayon or GNU parallel using more threads than you have cores. It won't go fast…

> The context switch for threads remains very expensive

It got even more expensive in recent years after all the speculative execution vulnerabilities in CPUs, so now you have additional logic on every context switch with mitigations on in kernel.

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

#76

Post by bmacho »

> Maybe Rust isn’t a good tool for massively concurrent, userspace software. We can save it for the 99% of our projects that don’t have to be.

Please make it happen! I want my userspace software to be in Rust!

Although, if it won't happen, then even better, a free real estate for a RustScript.

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

#77

Post by neonsunset »

Aurornis wrote: post #60
mrkline wrote: post #11

Earlier quoted context omitted.

> The lifetime of an Arc isn’t unknowable, it’s determined by where and how you hold it. In the same sense that the lifetime of an object in a GC'd system has a lower bound of, "as long as it's referenced", sure. But that's nearly the opposite of what the borrow checker tries to do by statically bounding objects, at compile time. > maybe the disconnect in this article is that the author is coming at Rust and trying t…

> But that's nearly the opposite of what the borrow checker tries to do by statically bounding objects, at compile time. Arc isn't an end-run around the borrow checker. If you need mutable references to the data inside of Arc, you still need to use something like a Mutex or Atomic types as appropriate. > The degree to which a big language runtime and GC weren't a boogeyman for some problem spaces was really eye-openi…

There's a good chance this is rather a Go issue than a GC one. People get fooled by Go's pretense to be a high level C replacement. It is highly inadequate at performing this role at best.

The reason for that is the compiler quality, the design tradeoffs and Go's GC implementation throughput are simply not there for it to ever be a good general purpose systems-programming-oriented language.

Go receives undeserved hype, for use cases C# and Java are much better at due to their superior GC implementations and codegen quality (with C# offering better lower level features like structs+generics and first-class C interop).

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

#78

Post by marcosdumay »

lionkor wrote: post #26
cmrdporcupine wrote: post #6

Now, I think async is bad syntactic sugar that hides what's really going on under the surface. And I rail against it all the time. Especially the way dropping in async contaminates code bases by building tendrils across call-sites all through the application. ... But the tools that have been built around it are very useful and there's some good stuff there. I have some quibbles with this article: "Rust comes at this…

> It allows for that This is like saying C++ allows for templates, and theres a big community around it. Sure, but its the entire community.

Almost all Rust libraries just don't deal with concurrency at all.

Maybe async is the most popular concurrency construct there (I have no idea). But the entire population here is small.

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

#79

Post by anonymoushn »

jnxx wrote: post #59

> 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. Isn't that already, in this strong generality, an almost always wrong assumption? Sure, one can do massively parallel or embarrassingly parallel computation. Sure, graphic cards are parallel computers. Sure, OS kernels use multiple cores.…

Well, if he wants to get close to using 12% of the machine, he'll need the SIMD intrinsics that are hidden behind `unsafe` :(

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

#80

Post by divyekapoor »

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.

Post reply on HN