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

121–130 of 624 posts

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

#121

Post by brundolf »

fnordpiglet wrote: post #102
brundolf wrote: post #72

Earlier quoted context omitted.

> 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 an…

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 you avoid them

Another thing, for me, was that I came from mostly writing TypeScript, which is the opposite: the base language is breezy without abstractions, and the type system equips you to strongly-type plain data and language features, so you'll have a great time if you stick to those

But yeah, it's been interesting to see how different the answers to these questions can be in different languages!

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

#122

Post by grug_htmx_dev »

Animats wrote: post #115
grug_htmx_dev wrote: post #68

Yes, async is effectively a much harder version of Rust, and it's regrettable how it's been shoved down the throats of everyone, while only 1% of projects using it really need it. Hover, async is also amazing in these 1% of cases when it's useful. If you have a service that handles massive amounts of network calls at the core (think linkerd, nginx, etc.), or you want to have a massive amount of lightweight tasks in y…

> Yes, async is effectively a much harder version of Rust, and it's regrettable how it's been shoved down the throats of everyone, while only 1% of projects using it really need it. Yes. I just noticed that Tokio was pulled into my program as a dependency. Again. It's not being used, but I'm using a crate which has a function I'm not using which imports reqwest, which imports h2, which imports tokio.

Exactly, because something somewhere needs to make one http call, and it's would be impossible if it wasn't done with scalable async executor. /i

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

#123

Post by legohead »

Hopefully this is an appropriate place to ask this question: I don't know what to do about threads/CPU for a game server project I want to write.

I really want to use TypeScript, as I like the language and I want to use this as a way to learn it better. I'm not expecting to have some super successful game, but the programmer part of my mind is upset at not utilizing all the cores of the machine. So, what do people do? Split up the server into multiple independent running components, or is my choice really to just use another language?

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

#124

Post by rapnie »

mike_hearn wrote: post #91
Yoric wrote: post #23

Earlier quoted context omitted.

I've seen one wasm VM for Rust that offered what looked like transparent M:N, which should solve (in that case) most async difficulties. We'll see how that evolves.

Which one? I wonder what its performance is like. A good candidate for this is Graal. It can compile (JIT/AOT) both WASM and also LLVM bitcode directly so Rust programs can have full hardware/OS access without WASM limitations, and in theory it could allow apps to fully benefit from the work done on Loom and async. The pieces are all there. The main issue is you need to virtualize IO so that it goes back into the JVM…

Curious too. I follow Lunatic [0] as a candidate for future use, and also wasmCloud [1].

[0] https://lunatic.solutions/

[1] https://wasmcloud.com

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

#125

Post by vlovich123 »

Async actually doesn’t require sync/send. This only happens if you have a work stealing runtime like tokio. However, single threaded runtimes are possible and do exist. Work stealing is appropriate for some use cases, thread per core designs for other use cases.

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

#126

Post by samsquire »

I think the persons behind Rust are working on a particularly hard and complicated problems, so I don't want to say that async Rust work is bad. I would instead say it is complicated and hard to understand and use casually, instead.

Async Rust is many language features and behaviour all interacting with each other at the same time, to create something more complicatedly than how you would describe the problem you're actually trying to solve (I want to do X when Y happens, and I want to do X when Y happens × the number of hardware threads). When you're using async rust, you are having to think more carefully about:

* memory management (Arc) and safety and performance

* concurrency

* parallelism, arbitrary interleavings

* thread safety

* lifetimes

* function colouring

All interacting together to create a high cognitive load.

Is the assembly equivalent of multithreading and async complicated?

Multithreading, async, coroutines, concurrency and parallelism is my hobby of research I enjoy. I journal about it all the time.

* I think there's a way to design systems to be data intensive (Kleppmann) and data orientated (Mike Acton) with known-to-scale practices.

* I want programming languages to adopt these known-to-scale practices and make them easy.

* I want programs written in the model of the language to scale (linearly) by default. Rama from Red Planet Labs is an example of a model that scales.

* HN user mgaunard [0] told me about "algorithmic skeletons" which might be helpful if you're trying to parallelise. https://en.wikipedia.org/wiki/Algorithmic_skeleton

I think the concurrency primitives in programming languages are sharp edged and low level, which people reach for and build upon primitives that are too low level for the desired outcome.

[0]: https://news.ycombinator.com/item?id=36792796

[1]: https://blog.redplanetlabs.com/2023/08/15/how-we-reduced-the...

Note: You can use async Rust without threading but I assumed you're using multithreading.

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

#127

Post by lowbloodsugar »

miguelmurca wrote: post #5

This is bound to get some criticism (or some tangent-at-best discussion), but it seems like a pretty fair discussion to me. What I'm missing at the end of the article is the author's point: I believe they're advocating for the use of raw threads and manual management of concurrency, and doing away with the async paraphernalia. But, at the same time, earlier in the article they give the example of networking-related t…

I thought his point was async is not good for apps with lots of work to do, and that green threads are a much better idea. IDK.

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

#128

Post by nu11ptr »

adrienthebo wrote: post #99
nu11ptr wrote: post #69

Earlier quoted context omitted.

The challenge is that async colors functions and many of the popular crates will force you to be async, so it isn't always a choice depending on which crates you need.

Please excuse my ignorance, I haven't done a ton of async Rust programming - but if you're trying to call async Rust from sync Rust, can you not just create a task, have that task push a value through a mpsc channel, shove the task on the executor, and wait for the value to be returned? Is the concern that control over the execution of the task is too coarse grained?

There are ways to call both from both for sure, but my point is if you don't want any async in your code at all...that often isn't a choice if you want to use the popular web frameworks for example.

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

#129

Post by fzeindl »

mrkline wrote: post #34
fzeindl wrote: post #22

Async Everything is a bad language. Async/await was a terrible idea for fixing JavaScript's lack of proper blocked threading that is currently being bolted onto every language. It splits every language and every library-ecosystem in half and will cause pains for many years to come. Everyone who worked with multi-threading outside of JavaScript knows that using actors/communicating sequential processes is the best way…

> 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…

> 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

Agreed. JavaScript was actually my first language after TurboPascal in 1996.

I was also there listening to the first podcasts when node came out.

JavaScript is a very interesting language, especially with it's prototype memory model. And the eventloop apart from the language is interesting as well. And it's no coincidence Apple went as far as baking optimizations for JavaScript primitive operations into the M1 microcode.

But I still think multithreading is best done by using blocking operations.

NIO can be implemented on top of blocking IO as far as I know but not the other way round.

Also, sidenote, I think JavaScript's only real failure is the lack of a canonical module/import system. That error lead to countless re-implementations of buildsystems and tens of thousands of hours wasted debugging.

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

#130

Post by macintux »

satvikpendem wrote: post #113
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…

> But then rust also has channels. When you read about it, it talks about "messages", which to me means little objects. Like a few bytes little. This is the solution, pretty much everything I write now is just a few tasks that service some channels. They look at what's arrived and if there's something to output, they will put a message on the appropriate channel for another task to deal with. No sharing objects or an…

Erlang often crops up in these conversations.
Post reply on HN