Comment by fooker
9 hours ago
Great, if you are right everyone is going to be using Rust eventually.
I like the concepts proposed by Rust but do not like fighting with the borrow checker or sprinkling code with box, ref, cell, rc, refcell, etc.
At some point there’s going to be a better designed language that makes these pain point go away.
> I like the concepts proposed by Rust but do not like fighting with the borrow checker or sprinkling code with box, ref, cell, rc, refcell, etc.
I'm not sure why this would be confusing or disliked by a C++ dev.
Rust's Box<T> is similar to C++'s std::unique_ptr<T>.
Rust's Rc<T>, Arc<T>, and Rc<RefCell<T>> serve similar uses to C++'s std::shared_ptr<T>.
Rust's Weak<T> is similar to C++'s std::weak_ptr<T>.
Verbosity of both is nearly identical. The big difference is that Rust enforces the rules around aliasing and mutability at compile time, whereas with C++ I get to find out I've made a mistake when my running code crashes.
Reminds me of “A monad is a monoid in the category of endofunctors, what's the problem?”
As you write this, do you not start to see why this would be confusing?
Yes, C++ is pretty bad at this too.
The fact that these exist and the programmer has to always be consciously be aware of it is an indication that something has gone wrong in the language design.
Imagine if you were to write C code in 1970, but you always had to keep track of which registers each variable corresponded to. That is how I look at these.
(There were, indeed, early 'high level' languages that required you to do this :)
> The facts that these exist and the programmer has to always be consciously be aware of it
This is what separates a systems programming language suitable for OS and embedded development from managed languages, which are not.
The complexity ultimately stems from unavoidable details of the hardware. Languages which do not offer similar representations will be incapable of making full use of the underlying hardware, including writing certain projects like bootloaders, firmwares, OSes, etc. Rust is pretty close to state-of-the-art in terms of providing reasonable abstractions over the hardware.
It sounds to me like you're used to managed languages with a runtime which are great for certain applications, but unable to be specific enough about memory layout, how data is formatted in memory, etc. for some tasks. Those choices were made for you by the language runtime's authors and necessarily limit the language's applicability to some problems. Rust, C++, and other systems programming languages don't have such limitations, but require you to understand more of the complexity of what the system is actually doing.
Any language which provides adequate representations for taking full advantage of the hardware is going to be on a similar order of complexity as Rust, C++, or other systems programming languages, because the hardware is complex. Managed languages can be nice for introducing folks to programming, precisely because much of the complexity is hidden in the runtime, but that can be a double edged sword when it comes time to approach a systems level task.
Instead of wishing the language didn't offer those representations, it may be more productive to ask why C++ and Rust converged on such similar ones. Exploration of that question will be enlightening.
10 replies →
> Great, if you are right everyone is going to be using Rust eventually.
Every task does not need speed and safety. Therefore, "everyone" doesn't need Rust.
But I could easily see a future where C++ is relegated to legacy language status. It has already had decades of garbage-collected languages chipping away at most of its general-purpose uses, but Rust seems capable and in a position to take away most of its remaining niches.
It's kind of why the old C++ programmer that I am decided to learn Rust in the first place - seemed like a good idea at the time to skate where the puck is heading.
> But I could easily see a future where C++ is relegated to legacy language status.
Yes, agreed. My prediction is that the replacement is a friendly language that makes Rust's ideas ergonomic to use.
I hope you realize how your critique is identical to the critiques people have about IPv6
Is your claim that the borrow checker is the problem? That’s a really difficult design space to beat Rust in:
1. Shared mutable data structures to allow high performance code
2. No GC to allow high performance code
3. Non lexical lifetimes to allow flexibility in memory ownership for expressivity and performance (ie you can’t restrict allocations to never escape a lexical lifetime)
Capability based systems might avoid the Rust borrow checker but they’re even more verbose with annotations and complex than Rust.
Effects systems show some promise but not yet proven they can actually be a general purpose language like Rust (ie do the ideas scale well to multiple different problem domains).
Anyway, there’s lots of alternative ways of designing languages but they all come with undesirable tradeoffs. Would be better if you actually made some concrete proposals that Rust gets wrong rather than “it’s too complex - they should have made it simpler” without taking any position - always easier to critique from the sidelines without making a proposal of your own that can be critiqued.
this seems somewhat unlikely to me. My guess is that we'll see a continued split where Rust takes the low level like OS kernels and cryptography that need time consistency and adversarial security guarantees, while most higher level programs (apps/databases etc) are written in fast garage collected languages (e.g C#/Julia).