5 ms·

your final assertion implies that any new language that is a significant paradigm shift from c++ must be flawed.

coldtea 8y ago
I do qualify that I speak about languages that are still "Algol-derived". Rust is not some significant paradigm shift (like e.g. Scheme vs C vs Prolog vs Haskell, etc). It's the same concepts and programming styles as C, C++ etc, plus fighting the borrow checker.
- gameswithgo 8y ago
  i think the borrow checker may indeed be a rather large paradigm shift, and im super interested to know if you can get used to it and be as productive as you are in c++ or if it is innately harder. to me it is still hard to work woth but i habe 30 years of being ised to C or garbage collection
  - nicoburns 8y ago
    As someone from a JS background, I am far more productive in Rust than C++. C++ makes it really easy to accidentally break something that then takes ages to debug. And using libraries is a massive pain. However, if you have already learnt to be productive in C++, then I suspect Rust would end up being slightly slower to write the initial code, but not much. And it'd make up for it in ease of refactoring.
- nicoburns 8y ago
  Actually, a lot of the issues that C/C++ programmers have when they are new to Rust seem to be precisely because idiomatic Rust code (which can help to avoid borrow checker issues) is often in a more functional Scheme/OCaml style. Rust is both algol-derived, and ocaml-derived. And arguably the borrow checker creates a new paradigm entirely.
  - mrfredward 8y ago
    >The borrow checker creates a new paradigm entirely I don't think this can be emphasized enough. You can get deceivingly far in rust with an OOP style, only to come to the disheartening conclusion that it's impossible to do what you want with the architecture you spent months of work setting up. For example, how would you architect a simple single threaded emulator? The CPU is an object, RAM is an object, easy enough. Okay, the CPU needs mutable access to RAM at all times, so we'll make the CPU own the RAM, sure why not? Okay now we want to implement a graphics device that can mutably access RAM, so we just...put the ram out on it's own and make it a Rc<RefCell<T>>?!? Now it takes three lines of code to unwrap all the smart pointers to write a single byte of memory?!? And it's slower because we have to pay for runtime borrow checking! I went down exactly this road. I still use rust and love many things about it, but I've come to the conclusion that writing typical single threaded object oriented code in rust only looks like it works; it's an awful idea in practice. I think the reason C++ people have so much trouble with rust is the syntax makes it easy to do the things you've always done, but the mysterious borrowchecker tells you no later on.
    - Retra 8y ago
      It is hard to think about program architecture. Most languages don't make you think about it at all, they just let you jam code together however you want and give you the tools to make it work. That was the biggest shock I had moving to Rust: I couldn't just do what I wanted, I had to figure out how to do what Rust wanted. But I also wanted to learn how to design systems better, so the fact that Rust makes me think deeper about it is an advantage for me. In an OO language, I'd just lazily cobble things together. The code would work, but I would learn nothing. And some people would rather do things that way. It is very hard to break habits, and Rust basically forces you to do that.
    - v_lisivka 8y ago
      It's hard to implement unsafe patterns in safe language. It's hard like using ASM with Java, because Java is platform independent language, while ASM is platform dependent language. This impedance mismatch causes problems, which can solved by wrappers. If we are talking about emulator, why not just make clear communication between CPU, RAM, and graphic device? Memory can be split into rows (e.g. by split_at()), so graphic device can take ownership of a single scan line at a time, leaving majority of the memory unlocked. We cannot avoid problem, but we can make scale of the problem much smaller by splitting memory into pages, so CPU can take ownership of pages, it works with right now, while graphical device can work with it own pages.
- xfer 8y ago
  Rust has lambdas, ADTs, pattern-matching and typeclasses(although not as powerful without kinds). These things alone makes a significant paradigm shift than programming in algol style languages. You can just use ARC<T> for every heap-allocated value and rust will still offer a significant advantage compared to C/C++.
  - pjmlp 8y ago
    C++20 has all those things as well, except for pattern-matching expected to arrive by C++23. :) So if it wasn't for the copy-paste compatibility with unsafe C code, there is already quite a few modern features available in the language.
- baq 8y ago
  s/fighting the borrow checker/enforcing rules of data ownership/

I do qualify that I speak about languages that are still "Algol-derived". Rust is not some significant paradigm shift (like e.g. Scheme vs C vs Prolog vs Haskell, etc). It's the same concepts and programming styles as C, C++ etc, plus fighting the borrow checker.

gameswithgo 8y ago
i think the borrow checker may indeed be a rather large paradigm shift, and im super interested to know if you can get used to it and be as productive as you are in c++ or if it is innately harder. to me it is still hard to work woth but i habe 30 years of being ised to C or garbage collection
- nicoburns 8y ago
  As someone from a JS background, I am far more productive in Rust than C++. C++ makes it really easy to accidentally break something that then takes ages to debug. And using libraries is a massive pain. However, if you have already learnt to be productive in C++, then I suspect Rust would end up being slightly slower to write the initial code, but not much. And it'd make up for it in ease of refactoring.
nicoburns 8y ago
Actually, a lot of the issues that C/C++ programmers have when they are new to Rust seem to be precisely because idiomatic Rust code (which can help to avoid borrow checker issues) is often in a more functional Scheme/OCaml style. Rust is both algol-derived, and ocaml-derived. And arguably the borrow checker creates a new paradigm entirely.
- mrfredward 8y ago
  >The borrow checker creates a new paradigm entirely I don't think this can be emphasized enough. You can get deceivingly far in rust with an OOP style, only to come to the disheartening conclusion that it's impossible to do what you want with the architecture you spent months of work setting up. For example, how would you architect a simple single threaded emulator? The CPU is an object, RAM is an object, easy enough. Okay, the CPU needs mutable access to RAM at all times, so we'll make the CPU own the RAM, sure why not? Okay now we want to implement a graphics device that can mutably access RAM, so we just...put the ram out on it's own and make it a Rc<RefCell<T>>?!? Now it takes three lines of code to unwrap all the smart pointers to write a single byte of memory?!? And it's slower because we have to pay for runtime borrow checking! I went down exactly this road. I still use rust and love many things about it, but I've come to the conclusion that writing typical single threaded object oriented code in rust only looks like it works; it's an awful idea in practice. I think the reason C++ people have so much trouble with rust is the syntax makes it easy to do the things you've always done, but the mysterious borrowchecker tells you no later on.
  - Retra 8y ago
    It is hard to think about program architecture. Most languages don't make you think about it at all, they just let you jam code together however you want and give you the tools to make it work. That was the biggest shock I had moving to Rust: I couldn't just do what I wanted, I had to figure out how to do what Rust wanted. But I also wanted to learn how to design systems better, so the fact that Rust makes me think deeper about it is an advantage for me. In an OO language, I'd just lazily cobble things together. The code would work, but I would learn nothing. And some people would rather do things that way. It is very hard to break habits, and Rust basically forces you to do that.
  - v_lisivka 8y ago
    It's hard to implement unsafe patterns in safe language. It's hard like using ASM with Java, because Java is platform independent language, while ASM is platform dependent language. This impedance mismatch causes problems, which can solved by wrappers. If we are talking about emulator, why not just make clear communication between CPU, RAM, and graphic device? Memory can be split into rows (e.g. by split_at()), so graphic device can take ownership of a single scan line at a time, leaving majority of the memory unlocked. We cannot avoid problem, but we can make scale of the problem much smaller by splitting memory into pages, so CPU can take ownership of pages, it works with right now, while graphical device can work with it own pages.
xfer 8y ago
Rust has lambdas, ADTs, pattern-matching and typeclasses(although not as powerful without kinds). These things alone makes a significant paradigm shift than programming in algol style languages. You can just use ARC<T> for every heap-allocated value and rust will still offer a significant advantage compared to C/C++.
- pjmlp 8y ago
  C++20 has all those things as well, except for pattern-matching expected to arrive by C++23. :) So if it wasn't for the copy-paste compatibility with unsafe C code, there is already quite a few modern features available in the language.
baq 8y ago
s/fighting the borrow checker/enforcing rules of data ownership/