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

201–210 of 624 posts

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

#201

Post by [deleted] »

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…

[deleted]

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

#204

Post by logicchains »

anonymoushn wrote: post #171
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…

It would be swell if functions could be generic over this capability at compile time, so that you could get the same guarantees from the type system without implementing the same protocols more than one time.

Haskell supports this, but right from the start Rust was always wary of trying to add higher kinded types, which are necessary to support this.

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

#205

Post by marcosdumay »

hot_gril wrote: post #139
marcosdumay wrote: post #41

Earlier quoted context omitted.

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.

And yet, people are going to use async in Rust. The feature has already proven itself useful long ago in other languages, beyond the timespan a fad could survive. Everyone started out doing it the other way and got sick of it.

> beyond the timespan a fad could survive

On the voodoo ridden land that is software development, we have plenty of clearly harmful fads that are much older than Rust and yet practiced everywhere.

Up to now, rust async has lasted for less time than the NoSQL craziness. I'm hard pressed to think of any large fad that lasted less than it.

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

#206

Post by neonsunset »

anonymoushn wrote: post #177
neonsunset wrote: post #156

Earlier quoted context omitted.

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…

> Also, non-async/await solutions for concurrency and asynchrony result in a more verbose, complex and bloated syntax I just write the same code that I would write if it were synchronous and it executes asynchronously.

How would your code look like if you wanted to fire off two concurrent requests and then consume their results later on? In C# it is just

var user = service.GetUser(id);

var promos = service.GetPromotions(category);

var eligible = GetEligibility(await user, await promos);

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

#207

Post by fzeindl »

jerf wrote: post #162
mrkline wrote: post #34

Earlier quoted context omitted.

> Async/await was a terrible idea for fixing JavaScript's lack of proper blocked threading that is currently being bolted onto every language. As fun as it is to hate on JavaScript, it's really interesting to go back and watch Ryan Dahl's talk introducing Node.js to the world ( https://www.youtube.com/watch?v=EeYvFl7li9E ). He's pretty ambivalent about it being JavaScript. His main goal was to find an abstraction aro…

If you look around at the other competition at the time, it's worth noting that many other languages that already existed for decades ultimately came up with the same basic solution. In fact one of the weird things about the Node propaganda at the time was precisely that every other major scripting language tended to have not just one event-based library, but choices of event based libraries. Perl even had a metapack…

> Don't scale for millions of concurrent tasks when you're only looking at a couple dozen max, no matter what language or environment you're in. Very common problem for programmers this decade.

And also with fibers/virtual threads (project loom) you can actually have a million threads using blocking hand-off on one machine. So the performance argument is kind of gone.

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

#208

Post by brabel »

nomel wrote: post #187
HippoBaro wrote: post #114

Earlier quoted context omitted.

Virtual threads or green threads, etc., are all names for the same thing: stackful coroutines. I would say yes! If your language/platform/runtime supports them, that should definitely be your starting point.

> that should definitely be your starting point. Could you expand a bit? Why?

Not OP, but synchronous code is much, much easier to understand and write than asynchronous code. What Java is doing is making synchronous code have all the advantages of asynchronous code by making blocking a Thread become a cheap operation (instead of blocking a real OS Thread), making the whole benfit of async code go away while getting rid of async's difficulties, specially in a language that doesn't have async/await (which makes async code "look" synchronous - but in Rust, as this blog post shows, that is not really the case).

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

#209

Post by hot_gril »

marcosdumay wrote: post #205
hot_gril wrote: post #139

Earlier quoted context omitted.

And yet, people are going to use async in Rust. The feature has already proven itself useful long ago in other languages, beyond the timespan a fad could survive. Everyone started out doing it the other way and got sick of it.

> beyond the timespan a fad could survive On the voodoo ridden land that is software development, we have plenty of clearly harmful fads that are much older than Rust and yet practiced everywhere. Up to now, rust async has lasted for less time than the NoSQL craziness. I'm hard pressed to think of any large fad that lasted less than it.

Async is much older in other languages. It's new in Rust, and time will tell, but I don't see it playing out differently this time.

Btw, the turnaround time is longer with a database, which often forms the foundation of a system. NoSQL bandwagoning was so destructive in part because of how long it looked like a good idea each time. Same with ORMs.

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

#210

Post by dgb23 »

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.

To me this kind of sounds like circular reasoning. Without function coloring there's no distinction that you need to know of.

Can you elaborate?

Post reply on HN