Comment by Subsentient | Hacker News Reader

Comment by Subsentient | Hacker News Reader

Rust is a good language overall, but it has some serious flaws that it seems those in control of Rust have no interest in fixing.

For example, it is possible to make the borrow checker accept self-referential structures, but nobody has done the immovable type etc work required for that. Which means, for non-trivial data structures, you need to either reach for unsafe or Rc/Arc. I write a lot of very multithreaded code, so for me it's almost always Arc, which means paying for atomics. And since the Drop trait takes an exclusive &mut reference, you must use fugly nested structs to prevent UB if you have shared mutable pointers you need deleted automatically.

I'd recommend learning Rust, but I'd also strongly recommend that you willfully push the limits of the language. Rust needs to be stretched out to accommodate more contemporary programming constructs, and you can help with that. Also, stay away from the core team and organization, they're poisonous as hell. I'd recommend donating to gccrs to help alternate implementations.

On the positive side, you do still end up with an awful lot of zero-cost safe code, and Rust is pretty nice to work in once you actually understand it.

> Arc, which means paying for atomics

As far as I understand, that should be practically zero-cost on x86, and quite cheap also on ARM - and it's also only paid during acquisition and destruction. I haven't yet caught refcounting in profiling as being the cause of unacceptable performance.

> that should be practically zero-cost on x86

It’s practically zero cost when uncontested. When contested, the instructions with that `lock` prefix are concurrently accessing a single cache line from multiple cores at the same time.

These cache coherency protocols are relatively slow. On some processors, reading a cache line recently modified by another core can cost 300-500 cycles, way more expensive than a cache miss and roundtrip to off-chip memory.

That is also true. But as said, I haven't yet personally run into a case where refcounting was contested to a point of making it an optimisation priority.

I think one the main use-cases for RCU in kernel is to alleviate the need for atomic reference counting in places where it would significantly impact performance. What you are saying might be indicative of one of the points that author raised: People mostly use Rust in non-system contexts where they don't really care that much about performance and would be better served by GC-ed language with runtime.

I'm not sure what counts as a non-system context these days. Most of my experience with using Rust in production was with a message queue type of service, where the desire was to minimize latency and to have consistent performance over prolonged use. I did make an initial prototype with C#, but things were much easier to make work well on both counts with Rust and Tokio.

> a message queue type of service, where the desire was to minimize latency and to have consistent performance over prolonged use.

Your requirements are probably similar to this C# queues class: https://github.com/Const-me/Vrmac/blob/master/VrmacVideo/Aud... That library decodes and plays realtime video + audio, both low latency and consistent performance over prolonged use were rather important. BTW that code runs on Raspberry Pi4, CPU performance is a fraction of what you’d expect on modern desktops or servers.

Reply on news.ycombinator.com