4 ms·

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

by fooker 9mo 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.

LexiMax 9mo ago
> 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.
- fooker 9mo ago
  > 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.
  - adgjlsfhk1 9mo ago
    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).
    - fooker 9mo ago
      > this seems somewhat unlikely to me. Rust is literally the fast stab at making a memory safe systems language. Do you really think we are never going to be able to design a better one?
      - LexiMax 9mo ago
        > Do you really think we are never going to be able to design a better one? I didn't want to learn C++. I learned it anyway because it was the best in the niches I was interested in, as well as there being existing programs that I wanted to contribute to that were written in C++. I can state for a certainty that if I had waited around for the perfect language before making the leap, it would have negatively affected both my career and hobbyist dalliances.
        fooker 9mo ago
        > I had waited around Did I mention waiting around? You should always use the right tool for the job, and right now if you need a memory safe systems programming language for a greenfield project, Rust is the tool. My point is that Rust's ergonomic issues will see it replaced when someone figures out a way to net similar advantages in a friendlier language. It's amusing to see strong beliefs on this being impossible!
      - timschmidt 9mo ago
        > Rust is literally the fast stab at making a memory safe systems language. Graydon started developing Rust in 2006, 20 years ago. The guy is somewhat famously a compiler buff with experience in a half dozen of them. What about that comes across as a "fast stab" to you?
  - vlovich123 9mo ago
    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.
    - fooker 9mo ago
      > That’s a really difficult design space to beat Rust in You are right. My prediction is some new language does it in 5-10 years. > identical to the critiques people have about IPv6 Maybe. With the difference that IPv6 gets out of your way when you do not want the advantages the new tech brings. (Rust? Noo.) Even with that it is barely at 50% adoption after 20 years. https://www.google.com/intl/en/ipv6/statistics.html https://www.google.com/intl/en/ipv6/statistics.html
timschmidt 9mo ago
> 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.
- fooker 9mo ago
  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 :)
  - timschmidt 9mo ago
    > 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.
vacuity 9mo ago
I really like Rust, and I'll gladly accept if a language that advances its benefits appears. Just as Rust is available to avoid using C++, that language would be available to avoid using Rust. It's not a competition; it's pragmatism.
- fooker 9mo ago
  > It's not a competition; it's pragmatism. Exactly right

by fooker 9mo ago

LexiMax 9mo ago

> 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.

fooker 9mo ago
> 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.
- adgjlsfhk1 9mo ago
  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).
  - fooker 9mo ago
    > this seems somewhat unlikely to me. Rust is literally the fast stab at making a memory safe systems language. Do you really think we are never going to be able to design a better one?
    - LexiMax 9mo ago
      > Do you really think we are never going to be able to design a better one? I didn't want to learn C++. I learned it anyway because it was the best in the niches I was interested in, as well as there being existing programs that I wanted to contribute to that were written in C++. I can state for a certainty that if I had waited around for the perfect language before making the leap, it would have negatively affected both my career and hobbyist dalliances.
      - fooker 9mo ago
        > I had waited around Did I mention waiting around? You should always use the right tool for the job, and right now if you need a memory safe systems programming language for a greenfield project, Rust is the tool. My point is that Rust's ergonomic issues will see it replaced when someone figures out a way to net similar advantages in a friendlier language. It's amusing to see strong beliefs on this being impossible!
    - timschmidt 9mo ago
      > Rust is literally the fast stab at making a memory safe systems language. Graydon started developing Rust in 2006, 20 years ago. The guy is somewhat famously a compiler buff with experience in a half dozen of them. What about that comes across as a "fast stab" to you?
- vlovich123 9mo ago
  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.
  - fooker 9mo ago
    > That’s a really difficult design space to beat Rust in You are right. My prediction is some new language does it in 5-10 years. > identical to the critiques people have about IPv6 Maybe. With the difference that IPv6 gets out of your way when you do not want the advantages the new tech brings. (Rust? Noo.) Even with that it is barely at 50% adoption after 20 years. https://www.google.com/intl/en/ipv6/statistics.html https://www.google.com/intl/en/ipv6/statistics.html

timschmidt 9mo ago

> 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.

fooker 9mo ago
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 :)
- timschmidt 9mo ago
  > 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.

vacuity 9mo ago

I really like Rust, and I'll gladly accept if a language that advances its benefits appears. Just as Rust is available to avoid using C++, that language would be available to avoid using Rust. It's not a competition; it's pragmatism.

fooker 9mo ago
> It's not a competition; it's pragmatism. Exactly right