Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

In my experience, C++ is a much more complicated language. The 8 ways to initialize something, the 5 types of values (xvalues etc.), inconsistent formatting conventions, inconsistent naming conventions, the rule of 5, exceptions, always remembering to check `this != other` when doing a move assignment operator, perfect forwarding, SFINAE, workarounds for not having a great equivalent to traits, etc. . Part of knowing the language is also knowing the conventions on top that are necessary in order to write it more safely and faster (if your move constructor is not noexcept it'll cause copies to occur when growing a vector of that object), and learning the many non-ideal competing ways that people do things, like error handling.


Why check this != other? I've seen this once before in a codebase and concluded it was unnecessary.

Asking as someone whose life became much easier after opting not do anything of the above and just write C in C++ ;-)


Consider a move assign to a vector<int> from src to this. The first step is for this to free its resources, the second step is to assign src resources to this, the third step is to set src resources to null.

If src and this are equal and you don't check for it, then you end up destroying src/this resources and the end result would be an empty vector (since the last step is to clear everything out).

The expected behavior is a no-op.


Right you said move but I was thinking of swap for some reason.

I probably still wouldn't care, unless it's clear that moving to self is even required. Trying to break everything in a thousand pieces and generalizing and perfecting them individually is a lot of busywork.


Thanks for organizing for me my thoughts on why even a restricted modern subset of C++ is complicated.


I mean yes, C++ managed to hit a uncanny overlap of being very overenginered in some aspects which to make it worse haven't focused at all on non-senior/export dev UX while also being underenginered in others aspects :/

They are trying to fix it in recent ~10 years, but they are also adding new clever expert features at the same time, so I kinda see it as a lost cause.

Rust isn't doesn't have "that" much less complexity if you take all the stable (or worse unstable experimental) things it has.

What makes Rust so nice is nearly always(1) if you don't use a feature you don't have to know about it (not so in C++) and if you stumble about a feature you don't know it's not just normally syntax visible but if you use it wrongly it won't segfault or even have a RCE due to out of bounds writes or similar.

So for C++ you have to learn a lot of the stuff upfront, but are not forced to by the compiler, and getting it wrong can have catastrophic consequences.

But for Rust you can learn it (mostly) bit by bit.

It's not perfect, when you go unsafe you are touching on a lot of "modern compiler" complexity which now also need to map to rust guarantees (but also have better save guards/visibility in Rust).

And async doesn't work so well with the bit by bit learning.

But in my personal experience if you don't have a team only consisting of senior C++ devs I would stay far away from C++. On the other hands with the right guidelines/limitations using rust with junior engineers is just fine (the guidelines matter to not get hangup on the wrong things or over-complicate things).


I keep reaching out to C++, because there is plenty of stuff out there that has C++ SDKs, or has their language runtimes partially written in C++, and adding another language in the middle like Rust will hardly help, only make the whole stack even more complex.


I have been out of it for a while and dont miss it much, but I thought that the rule of zero, not five, was the modern goal.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: