Maybe rust gains the high-ground in 10 years, and gets thrown back down in 15 by a new language to fix all the things someone sees as a problem with Rust
Or we just all stick to C++40! Very fair point.
The Linux kernel, said to be written in C, is in fact written in C, C++, Assembly, Objective-C, and possibly more under the "other" category that are programming languages and not meta languages.
Of course, any sufficiently complicated task will require a rich set of different tools fitted to different parts of the problem, but to me the C++ needs are also met by Rust.
(assuming we haven't wiped ourselves out by then)
Oof. Altogether too fair :)
PartialEq seems to be exactly like operator==, just with a different syntax
Yep, more or less. The benefit to me is in using them. If you were to write a binary search tree, your Node might look like this:
Now you can build a Node<int> or Node<double> or whatever, but in your insert() method you will assume that T overloads both ==/<. Is there a way in C++ to tell the compiler about this? In Rust, you constrain it:
structNode<T>whereT:PartialEq+PartialOrd{val:T,left:Rc<RefCell<Node<T>>>,right:Rc<RefCell<Node<T>>>,// or whatever pointer type}
Now this code won't compile unless your T is an appropriate type. It serves as both documentation and stronger static analysis. As far as I'm aware, all you get is the failiure to build when your code attempts to use a method like operator== that doesn't exist for your current T class.
Any unimplemented cases of operator== default to a standard implementation
This is precisely the behavior I feel is inferior to Rust, which will fail to compile with a friendly message telling you to implement it specifically instead of guessing and failing.
the programming community in general has to see that SomeLang has better features than SomeOldLang.
I think this does cut to the core of my question. From my (completely novice) perspective, that seems to me like what we are working with. General consensus, though, is clearly that that's not the case. I understand the arguments for C++'s proliferation - it's of course not going anywhere, but I want to understand more about why Rust isn't actually as cracked up as it seems.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Or we just all stick to C++40! Very fair point.
Of course, any sufficiently complicated task will require a rich set of different tools fitted to different parts of the problem, but to me the C++ needs are also met by Rust.
Oof. Altogether too fair :)
Yep, more or less. The benefit to me is in using them. If you were to write a binary search tree, your
Nodemight look like this:Now you can build a
Node<int>orNode<double>or whatever, but in yourinsert()method you will assume thatToverloads both==/<. Is there a way in C++ to tell the compiler about this? In Rust, you constrain it:Now this code won't compile unless your
Tis an appropriate type. It serves as both documentation and stronger static analysis. As far as I'm aware, all you get is the failiure to build when your code attempts to use a method likeoperator==that doesn't exist for your currentTclass.This is precisely the behavior I feel is inferior to Rust, which will fail to compile with a friendly message telling you to implement it specifically instead of guessing and failing.
I think this does cut to the core of my question. From my (completely novice) perspective, that seems to me like what we are working with. General consensus, though, is clearly that that's not the case. I understand the arguments for C++'s proliferation - it's of course not going anywhere, but I want to understand more about why Rust isn't actually as cracked up as it seems.