6 ms·

I've seen this idea from a few people and I don't get it at all. Rust is certainly not the simplest language you'll run into, but C++ is incredibly baroque, th

I've seen this idea from a few people and I don't get it at all. Rust is certainly not the simplest language you'll run into, but C++ is incredibly baroque, they're not really comparable on this axis. One difference which is already important and I think will grow only more important over time is that Rust's Editions give it permission to go back and fix things, so it does - where in C++ it's like venturing into a hoarder's home when you trip over things which are abandoned in favour of a newer shinier alternative.

rich_sasha 1y ago
C++'s complexity is coming from how eager it is to let you shoot yourself in the foot. Rust will make you sweat blood to prove the bird in the sky you're shooting at is really not your own foot.
- deleted 1y ago
  [deleted]
- eldenring 1y ago
  It's really not that bad.
- bcrl 1y ago
  And the gun isn't a gun, it's just a bunch of rope that you somehow got tangled into an explosive with a detonator you can't quite seem to locate.
- WD-42 1y ago
  You sure it doesn’t come from, for example, needing a macro just to get the length of an array?
  - saghm 1y ago
    Yes, I think it's pretty easy to be sure that this isn't where the complexity comes from when there's literally a method to do that on arrays. I'm not even sure which language you're talking about here, because you can call `.len()` in Rust or `.size()` in C++. If you're trying to remember what the language is where there's no immediately obvious straightforward way to get the length of an array, it's not Rust or C++; you must have been thinking of C.
    - tialaramex 1y ago
      This is a case of exactly the "hoarder" modality in C++ that I described. When somebody says array in C++ you think of std::array, the newer shiny C++ class which you're asked to use instead of the native array types. The native array types in C++ still exist and indeed do not provide methods like size() In Rust the arrays aren't stunted left over primitive types which weren't gifted modern features, array.len() works because all Rust's types get features like this, not just the latest and greatest stuff.
      - eMSF 1y ago
        While it is true that only class types have member functions in C++, that does not mean that objects of other types demand the use of macros. C++ also supports non-member functions, and the standard library contains a fair amount of these; including `std::size` that can be used to "get" the length of an array. (C++ arrays are different from arrays in many other programming languages, though not necessarily Rust, in that their type specifies their length, so in a way this is something you already "have" but certainly there are cases where it is convenient to "get" this information from an object.)
        WD-42 1y ago
        Ah, std::size, since c++17. No wonder nobody knows about it, that’s after we all started switching to rust.
viccis 1y ago
>where in C++ it's like venturing into a hoarder's home when you trip over things which are abandoned in favour of a newer shinier alternative Perl is so bad about this that I once worked on a very old codebase in which I could tell approximately when it was written based on which features were being used.
adastra22 1y ago
C++ has editions too btw. C++11, C++14, C++17, etc. These are opt in and allowed to break compatibility, although that is very rarely done in practice.
- Expurple 1y ago
  > although that is very rarely done in practice. That's one difference. And the other important differences are: - Rust apps can depend on library "headers" written in other editions. That's the whole deal with editions! Breaking changes are local to your own code and don't fracture the ecosystem. - Rust has a built-in tool that automatically migrates your code to the next edition while preserving its behavior. In C++, upgrading to the next standard is left as an exercise for the reader (just like everything else). And that's why it's done so rarely and so slowly.
  - pjmlp 1y ago
    Not really, because the crates they depend on cannot expose APIs with semantic changes across versions. Also it requires everything to be compiled with the same compiler, from source code. There are tools available in some C++ compilers for migration like clang, note the difference between ISO languages with multiple implementations, and one driven by its reference compiler.
    - Expurple 1y ago
      > Not really, because the crates they depend on cannot expose APIs with semantic changes across versions. Not sure what you're talking about. Any specific examples? > Also it requires everything to be compiled with the same compiler, from source code. It's not related to editions at all. It's related to not having an implicit stable ABI. It's possible have a dynamic Rust library that exposes a repr(C) interface, compile it into an .so using one version of the compiler, and then compile the dependent "pure Rust" crates using another compiler that's just going to read the metadata ("headers") of that library and link the final binary together. Same as in C and C++. You just can't compile any Rust code into a stable dynamic library, by defalut. (You can still always compile into a dylib that needs a specific compiler version)
blub 1y ago
Because they’re both complicated languages, but for different reasons. Rust didn’t really solve memory safety, it just pushed all the complexity into the type system. If one was struggling with memory errors in C++ that’s nice. If one was using Java, that still sucks. Furthermore some programmers really like complicated languages like Rust, Haskell, etc others like straightforward languages like Go, Python, etc.
- pjmlp 1y ago
  Go pushes the complexity into the programmer, that is how one ends with source code like Kubernetes, when the language doesn't provide all the tooling. Python belongs to the complicated languages section, people that think Python is straightforward never bothered reading all the manuals, nor had to put up with all the breaking changes throughout its history, it wasn't only 2 => 3, that was the major event, every release breaks something, even if little.
  - ReaperCub 1y ago
    > Go pushes the complexity into the programmer, that is how one ends with source code like Kubernetes, when the language doesn't provide all the tooling. I am not sure what you mean by this. I write go code pretty much everyday and that code looks vaguely the same as it would do in C#, or Python, or JavaScript. > Python belongs to the complicated languages section, people that think Python is straightforward never bothered reading all the manuals, nor had to put up with all the breaking changes throughout its history, it wasn't only 2 => 3, that was the major event, every release breaks something, even if little. I've read the manuals. Most docs appear to be reasonably well written, even if I find many of the examples a bit odd (I've never been a big fan of Monty Python, so the spam and eggs examples are all a bit odd). The 2 => 3 change was probably a big thing for those migrating all the existing libraries, frameworks. But as someone that uses it for prototyping stuff, I barely noticed the difference.
- Expurple 1y ago
  Go is "straightforward" at the cost of making your codebase not straightforward: https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride#simple-is-a-lie https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-... . Programming is complex. That complexity has to live somewhere. Python is absolutely not straighforward, it's a huge language with many moving parts and gotchas. Although, I admit, both are very easy to start programming in and to start shipping broken projects that appear working at first. They are good for learning programming, but terrible for production. > Rust didn’t really solve memory safety, it just pushed all the complexity into the type system. Yes, that's what it did, and that's the right tradeoff in most cases. Where the compiler can't make a reasonable default choice, it should force the programmer to make a choice, and then sanity-check it. > If one was struggling with memory errors in C++ that’s nice. If one was using Java, that still sucks. It's nice for those struggling with uncaught exceptions, null pointer bugs, mutithreading bugs, and confusing stateful object graphs in Java.
pjmlp 1y ago
Because of the type system, with its ML influence, two macro systems, the stuff on nightly that many folks enjoy using, having to rely on external crates for proper error handling and async/await features. Additionally, given its ML influence, too many people enjoy doing Haskell level FP programming in Rust, which puts off those not yet skilled in the FP arts. Also the borrow checker is the Rust version of Haskell burrito blogs with monads, it is hard to get how to design with it in mind, and when one gets it, it isn't that easy to explain to others still trying to figure it out. Hence why from the outside people get this opinion over Rust. Naturally those of us with experience in compilers, type systems theory and such, see it differently, we are at another level of understanding.
- Ygg2 1y ago
  > Also the borrow checker is the Rust version of Haskell burrito blogs with monads, it is hard to get how to design with it in mind, Eh. Haskell monads are a math-centric way of performing operations on wrapped types (stuff inside a monad). Rust borrow checker is way more pragmatic-centric, i.e. how can we prevent certain behaviors. The difference being you don't see Monads being replaced by Tree-Monads, without impacting the code. > and when one gets it, it isn't that easy to explain to others still trying to figure it out. So is going from 0-based to X-based arrays (where X is an integer); Or learning a new keyboard layout. Just because it's hard (unfamiliar) doesn't mean it's impossible.
  - pjmlp 1y ago
    In a way you're right, hence my last sentence.
    - Ygg2 1y ago
      I don't quite get what you mean by: > Naturally those of us with experience in compilers, type systems theory and such, see it differently, we are at another level of understanding. I mean yeah, you might have a new perspective, but so can it be a blinder to how people learn language. Curse of knowledge, and all that.

rich_sasha 1y ago

C++'s complexity is coming from how eager it is to let you shoot yourself in the foot. Rust will make you sweat blood to prove the bird in the sky you're shooting at is really not your own foot.

deleted 1y ago
[deleted]
eldenring 1y ago
It's really not that bad.
bcrl 1y ago
And the gun isn't a gun, it's just a bunch of rope that you somehow got tangled into an explosive with a detonator you can't quite seem to locate.
WD-42 1y ago
You sure it doesn’t come from, for example, needing a macro just to get the length of an array?
- saghm 1y ago
  Yes, I think it's pretty easy to be sure that this isn't where the complexity comes from when there's literally a method to do that on arrays. I'm not even sure which language you're talking about here, because you can call `.len()` in Rust or `.size()` in C++. If you're trying to remember what the language is where there's no immediately obvious straightforward way to get the length of an array, it's not Rust or C++; you must have been thinking of C.
  - tialaramex 1y ago
    This is a case of exactly the "hoarder" modality in C++ that I described. When somebody says array in C++ you think of std::array, the newer shiny C++ class which you're asked to use instead of the native array types. The native array types in C++ still exist and indeed do not provide methods like size() In Rust the arrays aren't stunted left over primitive types which weren't gifted modern features, array.len() works because all Rust's types get features like this, not just the latest and greatest stuff.
    - eMSF 1y ago
      While it is true that only class types have member functions in C++, that does not mean that objects of other types demand the use of macros. C++ also supports non-member functions, and the standard library contains a fair amount of these; including `std::size` that can be used to "get" the length of an array. (C++ arrays are different from arrays in many other programming languages, though not necessarily Rust, in that their type specifies their length, so in a way this is something you already "have" but certainly there are cases where it is convenient to "get" this information from an object.)
      - WD-42 1y ago
        Ah, std::size, since c++17. No wonder nobody knows about it, that’s after we all started switching to rust.

viccis 1y ago

>where in C++ it's like venturing into a hoarder's home when you trip over things which are abandoned in favour of a newer shinier alternative Perl is so bad about this that I once worked on a very old codebase in which I could tell approximately when it was written based on which features were being used.

adastra22 1y ago

C++ has editions too btw. C++11, C++14, C++17, etc. These are opt in and allowed to break compatibility, although that is very rarely done in practice.

Expurple 1y ago
> although that is very rarely done in practice. That's one difference. And the other important differences are: - Rust apps can depend on library "headers" written in other editions. That's the whole deal with editions! Breaking changes are local to your own code and don't fracture the ecosystem. - Rust has a built-in tool that automatically migrates your code to the next edition while preserving its behavior. In C++, upgrading to the next standard is left as an exercise for the reader (just like everything else). And that's why it's done so rarely and so slowly.
- pjmlp 1y ago
  Not really, because the crates they depend on cannot expose APIs with semantic changes across versions. Also it requires everything to be compiled with the same compiler, from source code. There are tools available in some C++ compilers for migration like clang, note the difference between ISO languages with multiple implementations, and one driven by its reference compiler.
  - Expurple 1y ago
    > Not really, because the crates they depend on cannot expose APIs with semantic changes across versions. Not sure what you're talking about. Any specific examples? > Also it requires everything to be compiled with the same compiler, from source code. It's not related to editions at all. It's related to not having an implicit stable ABI. It's possible have a dynamic Rust library that exposes a repr(C) interface, compile it into an .so using one version of the compiler, and then compile the dependent "pure Rust" crates using another compiler that's just going to read the metadata ("headers") of that library and link the final binary together. Same as in C and C++. You just can't compile any Rust code into a stable dynamic library, by defalut. (You can still always compile into a dylib that needs a specific compiler version)

blub 1y ago

Because they’re both complicated languages, but for different reasons. Rust didn’t really solve memory safety, it just pushed all the complexity into the type system. If one was struggling with memory errors in C++ that’s nice. If one was using Java, that still sucks. Furthermore some programmers really like complicated languages like Rust, Haskell, etc others like straightforward languages like Go, Python, etc.

pjmlp 1y ago
Go pushes the complexity into the programmer, that is how one ends with source code like Kubernetes, when the language doesn't provide all the tooling. Python belongs to the complicated languages section, people that think Python is straightforward never bothered reading all the manuals, nor had to put up with all the breaking changes throughout its history, it wasn't only 2 => 3, that was the major event, every release breaks something, even if little.
- ReaperCub 1y ago
  > Go pushes the complexity into the programmer, that is how one ends with source code like Kubernetes, when the language doesn't provide all the tooling. I am not sure what you mean by this. I write go code pretty much everyday and that code looks vaguely the same as it would do in C#, or Python, or JavaScript. > Python belongs to the complicated languages section, people that think Python is straightforward never bothered reading all the manuals, nor had to put up with all the breaking changes throughout its history, it wasn't only 2 => 3, that was the major event, every release breaks something, even if little. I've read the manuals. Most docs appear to be reasonably well written, even if I find many of the examples a bit odd (I've never been a big fan of Monty Python, so the spam and eggs examples are all a bit odd). The 2 => 3 change was probably a big thing for those migrating all the existing libraries, frameworks. But as someone that uses it for prototyping stuff, I barely noticed the difference.
Expurple 1y ago
Go is "straightforward" at the cost of making your codebase not straightforward: https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride#simple-is-a-lie https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-... . Programming is complex. That complexity has to live somewhere. Python is absolutely not straighforward, it's a huge language with many moving parts and gotchas. Although, I admit, both are very easy to start programming in and to start shipping broken projects that appear working at first. They are good for learning programming, but terrible for production. > Rust didn’t really solve memory safety, it just pushed all the complexity into the type system. Yes, that's what it did, and that's the right tradeoff in most cases. Where the compiler can't make a reasonable default choice, it should force the programmer to make a choice, and then sanity-check it. > If one was struggling with memory errors in C++ that’s nice. If one was using Java, that still sucks. It's nice for those struggling with uncaught exceptions, null pointer bugs, mutithreading bugs, and confusing stateful object graphs in Java.

pjmlp 1y ago

Because of the type system, with its ML influence, two macro systems, the stuff on nightly that many folks enjoy using, having to rely on external crates for proper error handling and async/await features. Additionally, given its ML influence, too many people enjoy doing Haskell level FP programming in Rust, which puts off those not yet skilled in the FP arts. Also the borrow checker is the Rust version of Haskell burrito blogs with monads, it is hard to get how to design with it in mind, and when one gets it, it isn't that easy to explain to others still trying to figure it out. Hence why from the outside people get this opinion over Rust. Naturally those of us with experience in compilers, type systems theory and such, see it differently, we are at another level of understanding.

Ygg2 1y ago
> Also the borrow checker is the Rust version of Haskell burrito blogs with monads, it is hard to get how to design with it in mind, Eh. Haskell monads are a math-centric way of performing operations on wrapped types (stuff inside a monad). Rust borrow checker is way more pragmatic-centric, i.e. how can we prevent certain behaviors. The difference being you don't see Monads being replaced by Tree-Monads, without impacting the code. > and when one gets it, it isn't that easy to explain to others still trying to figure it out. So is going from 0-based to X-based arrays (where X is an integer); Or learning a new keyboard layout. Just because it's hard (unfamiliar) doesn't mean it's impossible.
- pjmlp 1y ago
  In a way you're right, hence my last sentence.
  - Ygg2 1y ago
    I don't quite get what you mean by: > Naturally those of us with experience in compilers, type systems theory and such, see it differently, we are at another level of understanding. I mean yeah, you might have a new perspective, but so can it be a blinder to how people learn language. Curse of knowledge, and all that.