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

351–360 of 624 posts

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

#351

Post by Sharlin »

Someone wrote: post #328
RetpolineDrama wrote: post #272

Earlier quoted context omitted.

>The normal development process is that it's hard to get things to compile, and then it Just Works. That's great! I hate using a debugger, especially on concurrent programs. Yes, sometimes you can get stuck for a day, trying to express something within the ownership rules. Beats debugging. This is a far superior workflow when you factor in outcomes. More up front time to get a "correct"/more-reliable output scales in…

> This is a far superior workflow when you factor in outcomes. I’m a strong-typing enthousiast, too, but still, I’m not fully convinced that’s true. It seems you can’t iterate fast at all in Rust because the code wouldn’t compile, but can iterate fast in C++, except for the fact that the resulting code may be/often is unstable. If you need to try out a lot of things before finding the right solution, the ability to i…

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 clean up the ownership graph later if needed.

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

#352

Post by jayd16 »

lelanthran wrote: post #338
jayd16 wrote: post #311

Earlier quoted context omitted.

Isn't mixing async and sync code like this a recipe for deadlocks? What if your example code is holding onto a thread that foo() is waiting to use? Said another way, explain how you solved the problems of just synchronously waiting for async. If that just worked then we wouldn't need to proliferate the async/await through the stack.

> Said another way, explain how you solved the problems of just synchronously waiting for async. Why? It isn't solved for async functions, is it? Just because the async is propagated up the call-stack doesn't mean that the call can't deadlock, does it? Deadlocks aren't solved for a purely synchronous callstack either - A grabbing a resource, then calling B which calls C which calls A ... Deadlocks are potentially the…

Yes actually it is solved. If you stick to async then it cannot deadlock (in this way) because you yield execution to await.

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

#353

Post by Rochus »

mkl wrote: post #344
Rochus wrote: post #258

Earlier quoted context omitted.

> Because the term was coined by Alan Kay This is pretty unlikely. See https://news.ycombinator.com/item?id=36879311 .

> The term "object-oriented" was applied to a programming language for the first time in the MIT CSG Memo 137 (April 1976) That's publications though. Alan Kay says he used it in conversation in 1967: http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay... There's probably also a distinction to be made between "object-oriented" and "object-oriented programming".

The referenced research also considers the publications by Kay and his team (including his theses and the Smalltalk-72 and 76 manuals) and other uses of the term. I think Kay mixes things up in retrospective; in his 1968 thesis he used the terms "object language" and "object machine", but not "object-oriented"; imagine giving your new breakthrough method a name, but then not using that name anywhere in the publication; that seems unthinkable, especially with an accomplished communicator like Kay. The first time "object-oriented" appears in a publication of his or his team is in 1978.

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

#354

Post by rkangel »

Someone wrote: post #328
RetpolineDrama wrote: post #272

Earlier quoted context omitted.

>The normal development process is that it's hard to get things to compile, and then it Just Works. That's great! I hate using a debugger, especially on concurrent programs. Yes, sometimes you can get stuck for a day, trying to express something within the ownership rules. Beats debugging. This is a far superior workflow when you factor in outcomes. More up front time to get a "correct"/more-reliable output scales in…

> This is a far superior workflow when you factor in outcomes. I’m a strong-typing enthousiast, too, but still, I’m not fully convinced that’s true. It seems you can’t iterate fast at all in Rust because the code wouldn’t compile, but can iterate fast in C++, except for the fact that the resulting code may be/often is unstable. If you need to try out a lot of things before finding the right solution, the ability to i…

In Rust you have the option to Box and/or Rc everything. That gets you out of all the borrowing problems at the cost of rubtime performance (it basically puts you in the C++ world). This is a perfectly reasonable way to program but people forget about it due to the more "purist" approach that's available. But it's a good way to go for iteration and simplicity, and (in my opinion) still miles better than C++, due to the traits, pattern matching, error handling, and tooling.

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

#355

Post by xh-dude »

jzelinskie wrote: post #101
ncruces wrote: post #90

Earlier quoted context omitted.

And in the end, almost everything ends up using Mutex, RWMutex, WaitGroup, Once, and some channels that exist only to ever be closed (like Context.Done), and only if you need to select around them. It's great, but message passing it is not.

As a quite senior Go developer, I'd like to +1 this a ton. You're far more likely to have shocking edge cases unaccounted for when using channels. I consider every usage very, very carefully. Just like every other language, I think the ultimate solution is to build higher-level abstractions for concurrency patterns (e.g. errgroup) and, now that Go has generics, it's the right time to start building them. If you haven…

I still like channels because they may be a net reduction in the number of concurrency primitives in use, which complicates quantification in the paper - their taxonomy is great, though. Channels have some sharp corners.

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

#356

Post by LukaD »

Animats wrote: post #223

OK, I suppose I should write to this. As I've mentioned before, I'm writing a high performance metaverse client. Here's a demo video.[1] It's about 40,000 lines of Rust so far. If you are doing a non-crappy metaverse, which is rare, you need to wrangle a rather excessive amount of data in near real time. In games, there's heavy optimization during game development to prevent overloading the play engine. In a metavers…

Rust is not race condition free, it guarantees no data races though.

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

#357

Post by jvanderbot »

Dinux wrote: post #310
Animats wrote: post #223

OK, I suppose I should write to this. As I've mentioned before, I'm writing a high performance metaverse client. Here's a demo video.[1] It's about 40,000 lines of Rust so far. If you are doing a non-crappy metaverse, which is rare, you need to wrangle a rather excessive amount of data in near real time. In games, there's heavy optimization during game development to prevent overloading the play engine. In a metavers…

We've been building our robotic simulators in Rust for the past 3 years and I have the exact same experience. So far, I think, we've encountered maybe 5 actual runtime bugs over the last 3 years. Sure rust has some problems and yes the async isn't fully there yet, but overal the benefits outweigh the problems.

Async as a paradigm seems so against what GP was discussing. If I understood, and from my experience, we're talking more about concurrent execution with carefully-designed priorities, locks, and timing requirements. This is closer to the embedded / systems-level concurrency, if I understand it right. Are we really expecting a coroutine/ async style to just lift into this world?

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

#358

Post by otikik »

jstx1 wrote: post #280
Animats wrote: post #223

OK, I suppose I should write to this. As I've mentioned before, I'm writing a high performance metaverse client. Here's a demo video.[1] It's about 40,000 lines of Rust so far. If you are doing a non-crappy metaverse, which is rare, you need to wrangle a rather excessive amount of data in near real time. In games, there's heavy optimization during game development to prevent overloading the play engine. In a metavers…

> Yes, sometimes you can get stuck for a day, trying to express something within the ownership rules. This is a big problem. Fast iteration time is very valuable. And who likes doing this to themselves anyway? Isn't it a very frustrating experience? How is this the most loved language?

The “beats debugging” part I took it as meaning “it is better than spending that day debugging”.

I have fought the ownership rules and lost (replaced references by integers to a common vector-ugly stuff, but I was time constrained). But I have seen people spend several weeks debugging a single problem, and that was really soul-crushing.

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

#359

Post by skitter »

colinsane wrote: post #281
half-kh-hacker wrote: post #231

Earlier quoted context omitted.

so it's clear to non-Rust devs, we do have basic primitives for "running async code from sync": https://docs.rs/futures/latest/futures/executor/fn.block_on.... imagine you have an: async fn do_things() -> Something { /* ... */ } you can: use futures::executor::block_on; fn my_normal_code() { let something = block_on(do_things()); } but this does get messy if the async code you're running isn't runtime-agnostic :(

> You can break the chain by commanding the entire runtime to block on the completion of a future, but you probably shouldn’t do this pervasively since it isn’t composable. If a function blocks on a future, and that future calls a function that blocks on a future, congrats! The runtime panics! article says you can panic if you use the pattern you show. specifically, if you call `my_normal_code()` from an async contex…

It's not intrinsic to async functions; you can block on a future inside another future via e.g. pollster or even manual polling.

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

#360

Post by rkangel »

Cu3PO42 wrote: post #24
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 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…

> But writing code like that is a very diffferent experience from, say, async JavaScript,

I write a fair amount of code in Elixir professionally and this isn't how I view it.

There are some specific Elixir/Erlang bits of ceremony you need to do to set up your supervision tree of GenServers, but then once that's done you get to write code that feels like so gle threaded "ignore the rest of the world" code. Some of the function calls you're making might be "send and message and wait for a response" from GenServers etc. but the framework takes care of that.

I wrote some driver code for an NXP tag chip. Driving the inventory process is a bit involved, you have to do a series of things, set up hardware, turn on radio, wait a bit, send data, service the SPI the whole time in parallel. With the right setup for the hardware interface I just wrote the whole thing as a sequence, it was the simplest possible code you could imagine for it. And this at the same time as running a web server, and servicing hardware interrupts that cause it to reload the state of some registers and show them to each connected web session.

Post reply on HN