4 ms·

> Show me a language that simpler and more elegant than C++, where you don't have to worry about choosing how to pass parameters, or manage memory, and that sti

> Show me a language that simpler and more elegant than C++, where you don't have to worry about choosing how to pass parameters, or manage memory, and that still is as fast as C++. As someone who built their career on memory constrained, fast code in C++ I'm gonna have to say that Rust is simpler and more elegant. You've got your zero cost abstractions, heck I can decided static vs dynamic dispatch at compile time. Lots of things are more explicit leading to less foot-guns that you see with implicit type conversion and the like. Borrow-checker catches all those nasty dataraces and ownership problems up front. I've yet to run across anything I could do in C++ that I can't do in Rust. Listen, I love C++ but I think you may want to expand your horizons a bit before declaring it the best language ever in this space.

iainmerrick 8y ago
Even if Rust is better than C++, that doesn’t mean C++ is bad.
- rootlocus 8y ago
  Yes, actually, it does. Because C++'s mantra has always been zero cost abstractions. And people have defended the language because "you can't do better and still have the same performance". Well, it seems you can.
  - blub 8y ago
    Languages are never compared across a single dimension (except to prove a point on the internet).
kllrnohj 8y ago
Rust does come with a different bag of complexity. I'm thrilled to see competition with C++ in this space finally and super excited about Rust, but let's not pretend Rust is easy, either. It has a notoriously monsterous learning curve (which is why there's a major focus to fix that curve: https://github.com/rust-lang/rust-roadmap/issues/17 https://github.com/rust-lang/rust-roadmap/issues/17 ) And in this particular context Rust also still forces you to figure out how to pass parameters and manage memory. It "just" helps you with when to call free, which std::unique_ptr also helps you with. Rust makes it a compile error to have a bug, which is awesome, but the "you have to figure out memory allocation & layout" complexity is still mostly there.
- vvanders 8y ago
  > It has a notoriously monsterous learning curve That learning curve exists in C++ too, it's just hidden under the iceberg of 'interesting' runtime behavior. There's nothing like trying to printf a data race only to have the print call insert a fence and make your data race disappear. > And in this particular context Rust also still forces you to figure out how to pass parameters and manage memory. This is a lot simpler in Rust. Everything is value type by default, Box<T> for heap allocations, which even then are managed mostly for you via RAII(yeah I know there's std::unique_ptr but you still also have new, delete, new[], delete[], etc). Parameter types are value, mut ref or const ref. Move semantics are implicit if you have a value type. You don't have const/volatile/etc function qualifiers. implicit type conversion(esp constructors) can be a total bastard and trip you up in nasty ways. Even more annoying if you're trying to bit-pack or do clever math. Rust got to learn from a lot of C++'s mistakes and is to me a better language for it.
  - kllrnohj 8y ago
    > This is a lot simpler in Rust. Everything is value type by default, Box<T> for heap allocations, which even then are managed mostly for you via RAII(yeah I know there's std::unique_ptr but you still also have new, delete, new[], delete[], etc). Parameter types are value, mut ref or const ref. Move semantics are implicit if you have a value type. You don't have const/volatile/etc function qualifiers. That's not simpler at all - it's basically the same. C++ is also value type by default and you have to ask for heap allocations. And just like in C++ you have types in Rust that look like stack allocations but aren't, like Vec. So no, it's just value type otherwise Box<T>. That's not true in the slightest. And you need to specify in your function if it's taking ownership or not in addition to whether or not it's pass-by-value or pass-by-reference. Other than new/delete it's the same shit, just a different syntax. Rust got to break backwards compatibility which allowed it to remove a lot of C/C++'s old mistakes, yes, but the raw complexity is still entirely there, and very nearly identical.
    - vvanders 8y ago
      > That's not simpler at all - it's basically the same Oh, you mean like how you have rvalues, lvalues, xvalues, glvalues and prvalues[1]. In Rust you have value, ref and mut ref. You also don't specify ownership of passed pointers. So you need to encode that into your function documentation, as opposed to Rust where only value types can change ownership. > And just like in C++ you have types in Rust that look like stack allocations but aren't, like Vec. Never said anything about that, we're just talking about parameter types here, of course you can have value types take ownership of stack allocations(Box<T>, std::unique_ptr and their variants). > And you need to specify in your function if it's taking ownership or not in addition to whether or not it's pass-by-value or pass-by-reference. Not in the case of Rust, value types are the only thing that can take ownership(even Arc/Rc return value types when you clone()). Refs just allow temporary access in a mutable/const way for the lifecycle of the function. > Rust got to break backwards compatibility which allowed it to remove a lot of C/C++'s old mistakes Thanks for proving my point. I've never seen a C++ codebase that didn't use some of C++'s mistakes. [1] https://stackoverflow.com/questions/3601602/what-are-rvalues-lvalues-xvalues-glvalues-and-prvalues https://stackoverflow.com/questions/3601602/what-are-rvalues...
blub 8y ago
I believe the only thing that can be said with certainty about Rust when compared to C++ is that it's safer. Simplicity in the sense of easy to understand is an adjective I would apply to languages such as golang, Swift or even Java. C++ and Rust are complicated languages, because they allow low-level control of the implementation and they insist on the programmer thinking deeply about resource management. Elegance is likewise a property I would not associate with Rust: resource management is clumsy and leaks into the syntax everywhere, it ends up defining how the language looks like.

iainmerrick 8y ago

Even if Rust is better than C++, that doesn’t mean C++ is bad.

rootlocus 8y ago
Yes, actually, it does. Because C++'s mantra has always been zero cost abstractions. And people have defended the language because "you can't do better and still have the same performance". Well, it seems you can.
- blub 8y ago
  Languages are never compared across a single dimension (except to prove a point on the internet).

kllrnohj 8y ago

Rust does come with a different bag of complexity. I'm thrilled to see competition with C++ in this space finally and super excited about Rust, but let's not pretend Rust is easy, either. It has a notoriously monsterous learning curve (which is why there's a major focus to fix that curve: https://github.com/rust-lang/rust-roadmap/issues/17 https://github.com/rust-lang/rust-roadmap/issues/17 ) And in this particular context Rust also still forces you to figure out how to pass parameters and manage memory. It "just" helps you with when to call free, which std::unique_ptr also helps you with. Rust makes it a compile error to have a bug, which is awesome, but the "you have to figure out memory allocation & layout" complexity is still mostly there.

vvanders 8y ago
> It has a notoriously monsterous learning curve That learning curve exists in C++ too, it's just hidden under the iceberg of 'interesting' runtime behavior. There's nothing like trying to printf a data race only to have the print call insert a fence and make your data race disappear. > And in this particular context Rust also still forces you to figure out how to pass parameters and manage memory. This is a lot simpler in Rust. Everything is value type by default, Box<T> for heap allocations, which even then are managed mostly for you via RAII(yeah I know there's std::unique_ptr but you still also have new, delete, new[], delete[], etc). Parameter types are value, mut ref or const ref. Move semantics are implicit if you have a value type. You don't have const/volatile/etc function qualifiers. implicit type conversion(esp constructors) can be a total bastard and trip you up in nasty ways. Even more annoying if you're trying to bit-pack or do clever math. Rust got to learn from a lot of C++'s mistakes and is to me a better language for it.
- kllrnohj 8y ago
  > This is a lot simpler in Rust. Everything is value type by default, Box<T> for heap allocations, which even then are managed mostly for you via RAII(yeah I know there's std::unique_ptr but you still also have new, delete, new[], delete[], etc). Parameter types are value, mut ref or const ref. Move semantics are implicit if you have a value type. You don't have const/volatile/etc function qualifiers. That's not simpler at all - it's basically the same. C++ is also value type by default and you have to ask for heap allocations. And just like in C++ you have types in Rust that look like stack allocations but aren't, like Vec. So no, it's just value type otherwise Box<T>. That's not true in the slightest. And you need to specify in your function if it's taking ownership or not in addition to whether or not it's pass-by-value or pass-by-reference. Other than new/delete it's the same shit, just a different syntax. Rust got to break backwards compatibility which allowed it to remove a lot of C/C++'s old mistakes, yes, but the raw complexity is still entirely there, and very nearly identical.
  - vvanders 8y ago
    > That's not simpler at all - it's basically the same Oh, you mean like how you have rvalues, lvalues, xvalues, glvalues and prvalues[1]. In Rust you have value, ref and mut ref. You also don't specify ownership of passed pointers. So you need to encode that into your function documentation, as opposed to Rust where only value types can change ownership. > And just like in C++ you have types in Rust that look like stack allocations but aren't, like Vec. Never said anything about that, we're just talking about parameter types here, of course you can have value types take ownership of stack allocations(Box<T>, std::unique_ptr and their variants). > And you need to specify in your function if it's taking ownership or not in addition to whether or not it's pass-by-value or pass-by-reference. Not in the case of Rust, value types are the only thing that can take ownership(even Arc/Rc return value types when you clone()). Refs just allow temporary access in a mutable/const way for the lifecycle of the function. > Rust got to break backwards compatibility which allowed it to remove a lot of C/C++'s old mistakes Thanks for proving my point. I've never seen a C++ codebase that didn't use some of C++'s mistakes. [1] https://stackoverflow.com/questions/3601602/what-are-rvalues-lvalues-xvalues-glvalues-and-prvalues https://stackoverflow.com/questions/3601602/what-are-rvalues...

blub 8y ago

I believe the only thing that can be said with certainty about Rust when compared to C++ is that it's safer. Simplicity in the sense of easy to understand is an adjective I would apply to languages such as golang, Swift or even Java. C++ and Rust are complicated languages, because they allow low-level control of the implementation and they insist on the programmer thinking deeply about resource management. Elegance is likewise a property I would not associate with Rust: resource management is clumsy and leaks into the syntax everywhere, it ends up defining how the language looks like.