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

411–420 of 624 posts

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

#411

Post by wrapperup »

Klonoar wrote: post #255
Animats wrote: post #115

Earlier quoted context omitted.

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

PR them to use ureq. ;)

I recently did this in a relatively small crate, and it halved the dependencies. Highly recommended if you don't need async.

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

#412

Post by buildartefact »

throw10920 wrote: post #405
pshc wrote: post #313

Earlier quoted context omitted.

Debugging rare crashes and heisenbugs is more frustrating, and in non-safe languages, a chronic problem. Whereas after you prove the safety of a design once, it stays with you.

So you use a safe, garbage-collected language like Python, and iterate 5x as fast as Rust. Problem solved. It's 2023 - there are at least a dozen production-quality safe languages.

You’re seriously suggesting writing a game engine in Python?

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

#413

Post by vacuity »

wvenable wrote: post #397
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).

I still use inheritance in C# although it is only used for is-a relationships and those aren't that common. But when you need it for that, it's usually pretty important. I also think it's much more common to see it in library / framework code and not in application code.

UI in Rust without inheritance is tricky. There's still no great UI framework written in Rust yet, though not for lack of trying! I'm interested to see how Bevy's UI turns out. They're currently exploring the design space and requirements for production-grade UI, actually.

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

#414

Post by buildartefact »

throw10920 wrote: post #403
Someone wrote: post #328

Earlier quoted context omitted.

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

> It seems you can’t iterate fast at all in Rust because the code wouldn’t compile Yup, this is correct - and the reason is because Rust forces you to care about efficiency concerns (lifetimes) everywhere . There's no option to "turn the borrow checker off" - which means that when you're in prototyping mode, you pay this huge productivity penalty for no benefit. A language that was designed to be good at iteration wo…

>There's no option to "turn the borrow checker off" - which means that when you're in prototyping mode, you pay this huge productivity penalty for no benefit

That’s not really true. The standard workaround for this is just to .clone() or Rc> to unblock yourself, then come back later and fix it.

It is true that this needs to be done with some care otherwise you can end up infecting your whole codebase with the “workaround”. That comes with experience.

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

#415

Post by wrsh07 »

JoshTriplett wrote: post #326
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 race condition free, but not deadlock free. It needs a static deadlock analyzer, one that tracks through the call chain and finds that lock A is locked before lock B on path X, while lock B is locked before path A on path Y. That sounds like a great idea. Something in the style of lockdep, that (when enabled) analyzes what locks are currently held while any other lock is taken, and reports any potential dea…

Google has acquired before: https://abseil.io/docs/cpp/guides/synchronization#thread-ann...

It's quite nice, but for cpp not rust

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

#416

Post by mrkline »

dilippkumar wrote: post #321
riku_iki wrote: post #273

Earlier quoted context omitted.

> In terms of performance, ARC offers massive benefits but it also has big disadvantage, that it communicates to actual malloc for memory management, which is usually much less performant than GC from various reasons.

> which is usually much less performant than GC from various reasons. Can you elaborate? I've seen a couple of malloc implementations, and in all of them, free() is a cheap operation. It usually involves setting a bit somewhere and potentially merging with an adjacent free block if available/appropriate. malloc() is the expensive call, but I don't see how a GC system can get around the same costs for similar reasons.…

- Like others have said, both malloc()/free() touch a lot of global state, so you either have contention between threads, or do as jemalloc does and keep thread-local pools that you occasionally reconcile.

- A moving (and ideally, generational) GC means that you can recompact the heap, making malloc() little more than a pointer bump.

- This also suggests subsequent allocations will have good locality, helping cache performance.

Manual memory management isn't magically pause-free, you just get to express some opinion about where you take the pauses. And I'll contend that (A) most programmers aren't especially good at choosing when that should be, and (B) lots (most?) software cares about overall throughput, so long as max latency stays under some sane bound.

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

#417

Post by kprotty »

throw10920 wrote: post #410
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…

> Async contamination I've always wondered why the "color" of a function can't be a property of its call site instead of its definition . That would completely solve this problem - you declare your functions once , colorlessly, and then can invoke them as async anywhere you want.

If a function calls something that does something async, that can't be evaluated synchronously due to 1) no setup; could be async IO and require being called in the context of an async runtime (library feature, not language feature) and 2) blocking synchronously on an async task in an async runtime can result in deadlocks from task waiting on runtime IO polling but the waiting preventing the runtime from being polled.

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

#418

Post by jjnoakes »

throw10920 wrote: post #404
ghosty141 wrote: post #334

Earlier quoted context omitted.

> And who likes doing this to themselves anyway? Isn't it a very frustrating experience? How is this the most loved language? The thing is, these dependencies do exist no matter what language you use if they stem from an underlying concept. In that case rust just makes you explicitly write them which is a good thing since in C++ all these dependencies would be more or less implicit and everytime somebody edits the co…

> So what I'm saying, you need to put in this work no matter which language you choose This is very false. Managed-memory languages don't require you to even think about lifetimes, let alone write them down. Yes, I understand that this is for efficiency - but claiming that you have to think about lifetimes everywhere is just wrong, and irrelevant when discussing topics (prototyping/design work/scripting) where you do…

Lifetimes are still important in managed languages. You just have to track them in your head, which is fallible. The difference is that if you get it wrong in a managed language, you get leaks or stale objects or other logic bugs. In rust you get compile time errors.

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

#419

Post by throw10920 »

buildartefact wrote: post #412
throw10920 wrote: post #405

Earlier quoted context omitted.

So you use a safe, garbage-collected language like Python, and iterate 5x as fast as Rust. Problem solved. It's 2023 - there are at least a dozen production-quality safe languages.

You’re seriously suggesting writing a game engine in Python?

You accidentally responded to the wrong comment. I never mentioned a game engine.

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

#420

Post by throw10920 »

jjnoakes wrote: post #418
throw10920 wrote: post #404

Earlier quoted context omitted.

> So what I'm saying, you need to put in this work no matter which language you choose This is very false. Managed-memory languages don't require you to even think about lifetimes, let alone write them down. Yes, I understand that this is for efficiency - but claiming that you have to think about lifetimes everywhere is just wrong, and irrelevant when discussing topics (prototyping/design work/scripting) where you do…

Lifetimes are still important in managed languages. You just have to track them in your head, which is fallible. The difference is that if you get it wrong in a managed language, you get leaks or stale objects or other logic bugs. In rust you get compile time errors.

> The difference is that if you get it wrong in a managed language, you get leaks or stale objects or other logic bugs.

Can you provide concrete examples of this? I've literally never had a bug due to the nature of a memory-managed language.

Post reply on HN