2 ms·

> Rust's obsession with performance above all else confuses me. It's kind of a requirement if they hope to replace C/C++ as a systems language, as those remain

> Rust's obsession with performance above all else confuses me. It's kind of a requirement if they hope to replace C/C++ as a systems language, as those remain the goto answer for "I need maximum control", short of assembly. And they want to replace C/C++ to fix all their safety problems. I work in embedded systems, where C remains a holdout, with all its problems. Rust's performance-oriented direction makes it a viable consideration for us.

dcow 3y ago
I understand the need to compete with C/C++. My understanding of zero cost abstractions is that they predominantly happen at compile time (and thus commonly appear in language semantics or the type system) and literally cost nothing at runtime. This has other costs like semantic complexity, but almost never performance. Regardless, I don't buy that Rust couldn’t present a more opinionated and complete programming experience without allowing the same performance characteristics that it has today. The whole async situation is awful. Lifetimes are a stupid leaky abstraction 99% of the time. My point is that there’s almost never a scenario where you e.g. need to bother with passing around a struct with a reference with a lifetime. 99% of the time you just take ownership of the data or use an Arc<Box<T>> and 99% of the time that’s not a performance problem. What I think is stupid is that Rust elevates and enshrines the 1% use cases and makes the 99% experience worse off for it. I love Rust. But it could do a better job of solving the 99% cases nicely while allowing a “zero cost escape hatch” where you could say “actually I do want a stack allocated reference without atomic reference counting” and pay the semantic price 1% of the time rather than 99% of the time, similar to Swift’s approach. Obviously my experience had been shaped by the projects I’ve worked on. But I also think Swift is an entirely more ergonomic and practical language. If you think Rust is a viable option then, unless you’re anti-Apple, Swift with ownership semantics most certainly is too. Seriously.
- _aavaa_ 3y ago
  But the problem with zero-cost abstractions is that even if the runtime cost is 0, the compile time (and the human time) can become quiet large. E.g. https://www.youtube.com/watch?v=rHIkrotSwcc https://www.youtube.com/watch?v=rHIkrotSwcc

dcow 3y ago

I understand the need to compete with C/C++. My understanding of zero cost abstractions is that they predominantly happen at compile time (and thus commonly appear in language semantics or the type system) and literally cost nothing at runtime. This has other costs like semantic complexity, but almost never performance. Regardless, I don't buy that Rust couldn’t present a more opinionated and complete programming experience without allowing the same performance characteristics that it has today. The whole async situation is awful. Lifetimes are a stupid leaky abstraction 99% of the time. My point is that there’s almost never a scenario where you e.g. need to bother with passing around a struct with a reference with a lifetime. 99% of the time you just take ownership of the data or use an Arc<Box<T>> and 99% of the time that’s not a performance problem. What I think is stupid is that Rust elevates and enshrines the 1% use cases and makes the 99% experience worse off for it. I love Rust. But it could do a better job of solving the 99% cases nicely while allowing a “zero cost escape hatch” where you could say “actually I do want a stack allocated reference without atomic reference counting” and pay the semantic price 1% of the time rather than 99% of the time, similar to Swift’s approach. Obviously my experience had been shaped by the projects I’ve worked on. But I also think Swift is an entirely more ergonomic and practical language. If you think Rust is a viable option then, unless you’re anti-Apple, Swift with ownership semantics most certainly is too. Seriously.

_aavaa_ 3y ago
But the problem with zero-cost abstractions is that even if the runtime cost is 0, the compile time (and the human time) can become quiet large. E.g. https://www.youtube.com/watch?v=rHIkrotSwcc https://www.youtube.com/watch?v=rHIkrotSwcc