You must log in or # to comment.
Is that because it’s that simple, or just that the boilerplate is pre-written in the standard library (or whatever it’s called in rust)?
Yes, it is that simple. In Rust if you have a structure
Personand you want to allow testing equality between instances, you just add that bit of code before the struct definition as follows:#[derive(PartialEq, Eq)] struct Person { name: String, age: u32, }In Rust,
PartialEqandEqare traits, which are similar to interfaces in Java. Manually implementing thePartialEqtrait in this example would be writing code that returns something likea.name == b.name && a.age == b.age. This is pretty simple but with large data structures it can be a lot of boilerplate.There also exist other traits such as
Cloneto allow creating a copy of an instance,Debugfor getting a string representation of an object, andPartialOrdandOrdfor providing an ordering. Each of these traits can be automatically implemented for a struct by adding#[derive(PartialEq, Eq, Clone, Debug, PartialOrd, Ord)]before it.It’s because people put in the hard work of writing amazing macros instead of baking code reuse into the type system itself 😁 I’m a rust noob and I love the derive macro.
So it’s actually a secret third option! That’s pretty rad.
Derive macros are a godsend. There’s macros to automatically implement serialization as well. Basically a Trait that can automatically be implemented when derived
On behalf of Java developers everywhere - thank you Project Lombok!
Fun story from before Rust was getting popular (years ago). So, I did a performance comparison to determine what language we should write our rules engine in. I compared Go, Rust, Node, and some others not worth mentioning.
At the time, I had experience with all but Rust.
Even knowing nothing, and working from scratch, the Rust POC was significantly faster. Just way, way, better.
That being said, I still chose Go due to productivity based on the language knowledge of the team to ease the transition (Go was closer to what they knew already), and while it was good for them to learn Go, I look back on it and realize Rust would have been a great opportunity to invest in their careers and have them learn it instead.
A hindsight is 20/20 experience for me.
The problem with rust, I always find is that when you’re from the previous coding generation like myself. Where I grew up on 8 bit machines with basic and assembly language that you could actually use moving into OO languages… I find that with rust, I’m always trying to shove a round block in a square hole.
When I look at other projects done originally in rust, I think they’re using a different design paradigm.
Not to say, what I make doesn’t work and isn’t still fast and mostly efficient (mostly…). But one example is, because I’m used to working with references and shoving them in different storage. Everything ends up surrounded by Rc<xxx> or Rc<RefCell<xxx>> and accessed with blah.as_ptr().borrow().x etc.
Nothing wrong with that, but the code (to me at least) feels messy in comparison to say C# which is where I do most of my day job work these days. But since I see often that things are done very different in rust projects I see online, I feel like to really get on with the language I need a design paradigm shift somewhere.
I do still persist with rust because I think it’s way more portable than other languages. By that I mean it will make executable files for linux and windows with the same code that really only needs the standard libraries installed on the machine. So when I think of writing a project I want to work on multi platforms, I’m generally looking at rust first these days.
I just realised this is programmerhumor. Sorry, not a very funny comment. Unless you’re a rust developer and laughing at my plight of trying to make rust work for me.
I do appreciate how newer C++ standards have made these kinds of things a lot easier too.
Define all comparison operators with just one one line using C++20
auto operator<=>(const ClassName&) const = default;Is there a way to avoid having to write copy and move twice every time yet?
That is completely incomprehensible lol
Maybe to a non C++ dev, but a lot of C++ is probably incomprehensible to a non C++ dev, just like there are other laguages that are incomprehensible to C++ devs. To me it makes perfect sense as it works just like all the other operator overloads.
auto- let the compiler deduce return typeoperator<=>- override the spaceship operator (pretty sure it exists in python too)(const ClassName&)- compare this class, presumably defined in Class name, with a const reference of type Class name, i.e. its own type.const- comparison can be made for const objects= default;- Use the default implementation, which is comparing all the member variables.An alternate more explicit version, which is actually what people recommend:
auto operator<=>(const ClassName&, const ClassName&) = default;if I just want to have less than comparison for example I would:
This one makes it explicit that you’re comparing two Class name objects.
if I just want to have less than comparison for example I would:
auto operator<(const ClassName&, const ClassName&) = default;If I need to compare against another class I could define:
auto operator<(const ClassName&, const OtherClass&)You just need to break the syntax apart and look at it from the LHS and the RHS seperately.
In layman’s terms: constantine felt boxed in by his social class which left him often at dagger-ends to the operations on his car. Unable to keep up with the constant payments, he defaulted on the loan.
See? Easy.
It’s nice that this exists these days, but my god is it horrendously unreadable at a glance
It makes it look like they’re just adding random noise to avoid colliding with existing syntax. Maybe they can try a UUID next time…
BuT ItS uNsAfE.
Only if you’re a bad programmer :/
This argument just doesn’t hold up. Software written by some of the best developers in the world still has these same bugs.
Why even use a language where you have to put so much effort into something that comes for free in many modern languages.
Haskell:
deriving EqNewer Scala follows the same when enabling strict equaility. It’s a good thing.
