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

611–620 of 624 posts

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

#611

Post by dfawcus »

JonChesterfield wrote: post #167
mrkline wrote: post #16

Earlier quoted context omitted.

Hoare Was Right. (But if you're only firing up a few tasks, why not just use threads? To get a nice wrapper around an I/O event loop?)

He didn't say queues though. CSP isn't processes streaming data to each other through buffered channels, it's one process synchronously passing one message to another. Whichever one gets the the communication point waits for the other.

It is both.

Hoare's later paper introduced buffered channels to CSP.

So one can use it as synchronous passing, or queued passing.

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

#612

Post by jayd16 »

lelanthran wrote: post #602
jayd16 wrote: post #587

Earlier quoted context omitted.

I don't see how it can be an implementation detail when fundamentally you must yield execution when the programmer has asked to retain execution. Besides Javascript, its also a common problem in C# when you force synchronous execution of an async Task. I'm fairly sure its a problem in any language that would allow an async call to wait for a thread that could be waiting for it. I really can't imagine how your propose…

> I don't see how it can be an implementation detail when fundamentally you must yield execution when the programmer has asked to retain execution. It's an implementation issue, because "running on only a single thread" is an artificial constraint imposed by the implementation. There is nothing in the concept of async functions, coroutines, etc that has the constraint "must run on the same thread as the sync waiting…

That sounds interesting indeed.

I think the major disconnect is that I'm mostly familiar with UI and game programming. In these async discussions I see a lot of disregard for the use cases that async C# and JavaScript were built around. These languages have complex thread contexts so it's possible to run continuations on a UI thread or a specific native thread with a bound GL context that can communicate with the GPU.

I suppose supporting this use case is an implementation detail but I would suggest you dig into the challenge. I feel like this is a major friction point with using Go more widely, for example.

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

#613

Post by jonstewart »

Animats wrote: post #465
jonstewart wrote: post #449

Earlier quoted context omitted.

This is very interesting. How do you manage latency of events coming over the network? Do... you... wind up having to set TCP_NODELAY? •͡˘㇁•͡˘

Embarrassingly, yes, because I can't turn off delayed ACKs from Rust.

I learned about nagling 20 years ago when I helped write a networked game server and had to turn it off so that input packets would be sent quickly. Thank you for your response to my troll, easily a top 5 career highlight.

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

#614

Post by pdimitar »

nitwit005 wrote: post #295

> Some problems demand a lot of concurrency. The canonical example, described by Dan Kagel as the C10K problem back in 1999, is a web server connected to tens of thousands of concurrent users. At this scale, threads won’t cut it—while they’re pretty cheap,5 fire up a thread per connection and your computer will grind to a halt. Try it. It'll probably work fine. It may be very expensive, memory wise, but it's easy to…

It's not just that. As you increase OS thread active count, each thread starts to respond slower and slower.

It's been tried, periodically. Still sucks.

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

#615

Post by pdimitar »

mrkline wrote: post #186
Veliladon wrote: post #63

> You might say this isn’t a fair comparison—after all, those languages hide the difference between blocking and non-blocking code behind fat runtimes, and lifetimes are handwaved with garbage collection. But that’s exactly the point! These are pure wins when we’re doing this sort of programming. Until all the work you're trying to push is generating so many allocations that your GC goes to shit once every two minute…

Go's GC is hardly state of the art.

I got no horse in this race -- I like both Golang and Rust and use them for different things -- but as far as I can tell, Golang's GC has improved a lot.

Not sure where does it stand on a global competition rating board (if there's even such a thing) but it's pretty good. I've never seen it crap the bed, though I also never worked at the scale of Twitch and Discord.

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

#616

Post by pdimitar »

reacharavindh wrote: post #503

Is it possible to use Rust and all the important 3rd party crates without using async? Out of curiosity, could Rust be limited to a language subset to mimic the simplicity of Golang (with channels and message passing) and trade-off some of the powerful features that seem to be causing pain? Pardon a naïve question. I’m a systems engineer who occasionally dabbles with simple cli tools in all languages for fun, but don…

I'd really like something like this! I would also love a Cargo switch / config that disables all panicky Rust API like `expect` and `unwrap`.

From what I can gather, such projects will never happen though. That's why I moved part of my work to Golang itself.

Rust is an amazing language. Though the team really takes the "system language" thing very seriously and they're making decisions and tradeoffs based on that, so it seems us its users should adapt and not use Rust for everything. That's what I ended up doing.

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

#617

Post by Sharlin »

throw10920 wrote: post #401
Sharlin wrote: post #351

Earlier quoted context omitted.

I think mostly you just need less iteration with Rust because the language seems to guide you towards nice, clean solutions once you learn not to fight the borrow checker. Rust programmers don't iterate using unsafe because every single line of unsafe gives you more to think and worry about, not less. But they might iterate using more copying/cloning/state-sharing-with-ref-counting-and-RefCell than necessary, and cle…

> I think mostly you just need less iteration with Rust because the language seems to guide you towards nice, clean solutions once you learn not to fight the borrow checker. That's not iteration. That's debugging. "Iteration" includes design work. Rust's requirement to consider memory management and lifetimes actively interferes with design work with effectively zero contributions towards functional correctness (unli…

No, I was not talking about debugging or correctness. The point was that Rust does not merely guide you towards correct code, it tends to guide you towards good code.

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

#618

Post by Sharlin »

tsimionescu wrote: post #496
Sharlin wrote: post #351

Earlier quoted context omitted.

I think mostly you just need less iteration with Rust because the language seems to guide you towards nice, clean solutions once you learn not to fight the borrow checker. Rust programmers don't iterate using unsafe because every single line of unsafe gives you more to think and worry about, not less. But they might iterate using more copying/cloning/state-sharing-with-ref-counting-and-RefCell than necessary, and cle…

The point of iteration is not typically to find the best implementation for a given algorithm, it's to find the best algorithm for solving a given problem. I can see the argument that Rust encourages by its design a clean implementation to any given algorithm. But no language's design can guide you to finding a good algorithm for solving a given problem - you often need to quickly try out many different algorithms an…

I don't think iteration is usually about testing different algorithms – it's much more about finding out what the problem is in the first place (that is, attaining a good enough understanding of the problem to solve it), and secondarily about finding out a solution to the problem that satisfies any relevant boundary conditions.

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

#619

Post by radicalbyte »

Turskarama wrote: post #442
radicalbyte wrote: post #300

Earlier quoted context omitted.

I'm from the C# world and am working through learning Rust... in C# we've largely moved away from using inheritance. Not sure that it's a good thing but "best practise" results in serialisation being implemented differently (serialisers which use attributes, or for more advanced teams serialisation wired in at compile time targeted by attributes - advantage here being that the state doesn't have to be public).

It's "prefer composition over inheritance" though, not "never use inheritance". There is a time and a place for it.

Which, as I said, results in you *usually* using composition :)

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

#620

Post by hot_gril »

ilyt wrote: post #539
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.

"Many people use it so it is good" is an idiotic argument

Yes it is. "Many people have been using it for a long time without regrets" is a better reason.
Post reply on HN