Hacker News Reader

Comment by sebstefan | Hacker News Reader

"despite the GC" and "despite the unsafety" is really putting a lot of weight on that "despite"

These are massive problems

I don't think it's so cut and dry. For lots of usecases, using Rust involves writing everything from scratch, because the only libraries available pull in an opinionated async runtime and feel entitled to call the global allocator and various syscalls at times the user cannot control, and these components cannot be swapped out because of fundamental issues that prevent Rust libraries from being composable (unless they go out of their way to adopt a feature that launched late last year?). IME there are relatively few usecases where long stalls due to GC are bad but long stalls due to page faults or open(2) taking a couple seconds to return are fine.

You're replying to me as if the comment was in a vacuum

It's responding to:

> complexity just for the sake of it,

> lots of pain for minimal gain

> If you need async/await you'll do better in modern .NET despite the GC

> if you need the highest CPU performance you'll do better in C++ despite the unsafety

To this I respond, GC is such a massive problem (I guess you can fill in "for some categories of problems" but I think it's obvious) that some people need to avoid it. And those people often turn to C++, where the "unsafety" is a very big problem.

I don't think so? My reply is that if you can't afford to stall for a really long time, like dozens of frames at 60hz at least, then your choices are often to deal with unsafety in C++, to deal with the GC in .NET, or to write everything from scratch in Rust (including many things for which you would typically use libraries) because idiomatic Rust and the associated ecosystem won't solve your tail latency issues. The last option is not obviously more attractive than the approach of working really hard to not make garbage that Unity devs are usually forced into after years of development when they start testing on Switch.

You can deal with that in .NET the "C++" way too, given that you can write abstractions with structs and generics instead of objects, use malloc and stackalloc, and more. You are not married to GC heap, despite some suggesting otherwise.

Generally speaking 60hz is not a problem but it starts to matter more with the popularity of high refresh rates. There are much more extreme cases like 1000hz game loop in OSU!, which pretty much has to use the same techniques as realtime systems that utilize GC-based language: https://github.com/dotnet/runtime/issues/96213#issuecomment-...

That depends a lot on the domain of the code.. just saying they are massive problems is plain wrong. There is a huge percentage of applications that need not care about GC at all.

Reply on news.ycombinator.com