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

151–160 of 624 posts

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

#151

Post by Taek »

Rust made a critical safety mistake when it chose its async paradigm. It gave the code the option to decide when to yield.

What that means is that when I'm writing async code, I have to audit every library I import to make sure that library is guaranteed to yield after a few microseconds of execution, otherwise my own core loops starve. Importing unknown code when using async rust is not safe for any application that needs to know its own threads won't starve.

A safe async language must guarantee that threads will make progress. Rust should change the scheduler so that it can pre-empt any code after that code has hogged a thread for too long.

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

#152

Post by tel »

simias wrote: post #92
tel wrote: post #20

Earlier quoted context omitted.

Waiting asynchronously on multiple channels/signals. Heterogenous select is really nice.

It really is, but I still favour "unsexy" manual poll/select code with a lot of if/elseing if it means not having to deal with async. I fully acknowledge that I'm an "old school" system dev who's coming from the C world and not the JS world, so I probably have a certain bias because of that, but I genuinely can't understand how anybody could look at the mess that's Rust's async and think that it was a good design for…

I think Rust’s async stuff is a little half baked now but I have hope that it will be improved as time goes on.

In the mean time it is a little annoying to use, but I don’t mind designing against it by default. I feel less architecturally constrained if more syntactically constrained.

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

#153

Post by jerf »

vilunov wrote: post #112
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.

I want colored functions. I want to know which code is running synchronously and which doesn't, which raises errors and which doesn't. Color is just a description of the function's properties (and effects) and how it's compatible with other colors. There is also nothing fundamentally bad with cooperative scheduling in scope of a single process.

I got into programming in the 1990s. At that point in time, there was still a large contingent of programmers loudly insisting they needed assembly language to do everything. And to be clear, I mean, everything. Not "Yeah, I can't really bring up an OS without a bit of specialized assembly" but "every programmer should write every program in assembly".

The vast majority of them were already wrong. They only got more wrong.

You may just be used to knowing what code is "synchronous" and what isn't because it's been shoved into your face and you've adapted your thought process to it. In practice, "everything important is doing something 'asynchronously'" turns out to be the vast majority of what you need, and the vast majority of your mental energy you are dedicated to splitting the world in two is a waste. For the little bit that remains, by all means use something specialized, but it's just not something that everyone, everywhere, needs to be doing all the time, any more than everyone everywhere should be manually allocating registers, or any more than programs need to have line numbers because otherwise how can they work? (One of my favorites because I remember having that conception myself.)

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

#154

Post by omnicognate »

assbuttbuttass wrote: post #147
omnicognate wrote: post #103

Earlier quoted context omitted.

Always with the blooming red and blue functions. You can say exactly the same thing about const. The fact that a function can perform asynchronous operations matters to me and I want it reflected in the type system. I want to design my system on such a way that the asynchronous parts are kept where they belong, and I want the type system's help in doing that. "May perform asynchronous operations" is a property a call…

> The fact that a function can perform asynchronous operations matters to me and I want it reflected in the type system. async doesn't tell you whether the function performs asynchronous operations, despite the name. async is an implementation detail about how the function must be invoked. As TFA correctly points out, there's nothing stopping you from calling a blocking function inside a future, and blocking the whol…

I didn't say it tells me whether the function does perform such operations, I said it tells me it can. More importantly it tells me which functions (most) can't.

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

#155

Post by Pauan »

bojo wrote: post #51
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.

I think they are referring to channels, which came with the tagline "share memory by communicating."

Rust has had OS channels since forever, and async channels for 5 years.

Rust has changed a lot in the past 5 years, people just haven't noticed, so they assume that Rust is still an old outdated language.

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

#156

Post by neonsunset »

bitblender wrote: post #96
neonsunset wrote: post #38

I have been using "async/await is bad, use {feature name[0]}" as a litmus test for people who are generally bad at programming, especially so at concurrent flavour of such. Sure, Rust is certainly verbose and very strict how the ownership rules apply in the context of async, but this is a hard constraint of its memory safety model. We could probably do better while retaining all performance but this is by far one of…

Disliking async/await does not make someone "generally bad at programming". This is a childish ad-hominem mindset that has no place in technical debates. Rust's decision to adopt async/await over green threads was intended to keep the runtime lean, not because it is an inherently better abstraction. Java certainly could have async/await syntactic sugar around its existing futures api, but project loom has greater amb…

Sure, it is "childish and ad-hominem", it is also efficient and usually works. Also, non-async/await solutions for concurrency and asynchrony result in a more verbose, complex and bloated syntax, having to invent fancy terms like "structured concurrency" for use cases which in C# are simply expressed by awaiting the task at the point of its consumption and not declaration (no special methods required) or in Rust via simple, albeit for a different scenario, join!().

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

#157

Post by SkiFire13 »

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…

You're conflating the idea of using channels with green threads. They are different, you can easily use channels with async/await and global state/mutexes with green threads.

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

#158

Post by fn-mote »

gavinhoward wrote: post #148
bionhoward wrote: post #140

Admittedly, I’m no expert in async rust, but I’ve written several thousand lines of sync rust this month. One thing I’ve found is when rustc makes a particular approach hard to implement, it usually does so for a good reason (i.e. there is a better way to achieve a similar result). If you’re learning the language, I would suggest starting out with some more vanilla sync code, loops and if statements, get used to the…

If it's not stable, then people shouldn't use it in production either.

People who do not know what they are doing should do research before using it in production.

Edit: Of course, since this is what "unstable" means, right?

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

#159

Post by bluGill »

harpiaharpyja wrote: post #132
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 remember picking up this sort of advice from a professor way back in college. It's a godsend. Structure the problem as data flowing between tasks and connect them up with queues, avoid sharing state. It's just a better way to deal with multithreading no matter what language you use.

There is a time any place for sharing state and data. However it is extremely complex to make that work, and so if at all possible don't. In general the only time I can't use queues is when I'm writing the queue implementation (I've done this several times - turns out there are a number of different special cases in my embedded system where it was worth it to avoid some obscure downside to the queues I already had).

When you need the absolute best performance sharing state is sometimes better - but you need a deep understanding of how your CPUs share state. A mutex or atomic write operation is almost always needed (the exceptions are really weird), and those will kill performance so you better spend a lot of time minimizing where you have them.

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

#160

Post by Pauan »

brundolf wrote: post #121
fnordpiglet wrote: post #102

Earlier quoted context omitted.

Yeah it was a bit of a block for me as well, I don’t know where it came from, but I resisted wrapping things. Reality is breaking things up into crates is encouraged anyway, and just abstracting complexity away is Not That Hard, and can usually be pretty small and concise to boot. I think I’m used to other languages provided a lot of these abstractions or having some framework that manages it all. The frameworks in r…

Well for one- creating abstractions always comes with a tradeoff, so it's good to have some basic skepticism around them. But Rust embraces them, for better and worse. It equips you to write extremely safe and scalable abstractions, but it's also designed in a way that assumes you're going to use those capabilities (mainly, being really low-level and explicit by default), and so you're going to have a harder time if…

Rust embraces abstractions because Rust abstractions are zero-cost. So you can liberally create them and use them without paying a runtime cost.

That makes abstractions far more useful and powerful, since you never need to do a cost-benefit analysis in your head, abstractions are just always a good idea in Rust.

Post reply on HN