Hacker News Reader

Comment by davidhyde | Hacker News Reader

My personal take on this subject is that Rust turns experts back into beginners and some devs react with hatred because of the fear this induces. For me it was the opposite. I was getting bored with my industry and thinking of a move to something else like management. Rust came along 6 yeas ago (for me) and threw me a lifeline. I love getting good at something that is hard, it’s just very satisfying. I do get why some people can’t stand the language. It is ugly to look at with its genetics and lifetime annotations and when a project is so large that it begins to lag rust-analyser then my joy turns to rage too.

View on HN

> My personal take on this subject is that Rust turns experts back into beginners and some devs react with hatred because of the fear this induces.

Those people are probably poor devs. Anyone who doesn't have the attitude and mindset to continue learning in something like software development which keeps advancing isn't cut out for that field.

Maybe it wouldn't be reasonable to say this about people who dislike programming in Malbolge, and maybe there are aspects of Rust that are more like programming in Malbolge and less like the field advancing.

You could have spend that time learning something which is actually useful and helps finding interesting jobs. For example, GPU programming or SIMD intrinsics.

What annoys me about rust is the complexity just for the sake of it, lots of pain for minimal gain compared to alternatives. 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.

"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