> C++ as a whole should be deprecated -- and no new projects should use C++ (unless for some very odd and specific reason).
It's quite a bit easier than Rust and no other popular language has its most important features (cross platform, interfaces with syscalls and other libraries easily, manual memory management possible, likely to be supported for a long time).
Having used both C++ and Rust extensively, I would say that it is easier to get something to compile in C++ than in Rust, but I find Rust overall much easier. C++ is really very complex, and even after more than a decade of using it there are so many things I don't know. With Rust I feel like I have a pretty solid grasp of most of the language.
I agree.. I've been writing in Rust for about 2 months and I find it to be a much easier surface than C++.. getting over the borrow checker isn't as bad as some make it out to be.. in fact, if it compiles it largely works.. you might be cloning one too many strings as a newbie, but you get the hang of it quickly.. when I wrote a lot of C++, I used a really small feature set.. but that was like 20 years ago.. now (apparently) it's a lot better.. with Rust, you need to think about memory, stack, and heap, but it's not ridiculous. The type system is really great. Granted, I'm not writing a database, but so far, I see a lot of really good libraries that integrate really easily, and it's just fun to use. The functional features and futures feel a lot like scala... and it's fast.
oh and the last time I wrote in C++, I was using gmake.. all those compiler and linker switches.. header and linker search paths.. ugh.. I felt like I was launching a rocket to the moon just getting some of that to build. don't miss that.. chasing down memory corruption in threads with gdb.. also painful. I get that C++ is much better now, but I haven't really used it in a long time so can't comment.
Yes, but when you want to do linked structures, really generic code without repetition or decent compile-time programming, then C++ is very powerful at that.
I have found table-generation and processing at compile-time to be of big help.
For example, pre-computing values or parsing at compile-time.
This is useful for example in the following situations:
- You want to embed things at compile-time but keep things apart in a file. This file can be used at run-time when developing but is embedded and literally vanishes (you put your config directly in a struct) when deploying.
- You do not want to spend extra time at compile-time.
- No need to protect data at run-time with mutexes, etc.
The simplification it can yield is not immediately obvious. It can take a bit more work but the result is worth it. D is more powerful than C++ at this, btw.
It _looks_ easier because it lets you do anything you want. C++ makes you feel like you're going faster, but then you spend two weeks debugging a weird memory issue.
I come from functional programming background, so I'm all for taking a little bit longer to make my code compile if that means it'll work. I'd rather deal with compilation errors than waking up at 2am to debug a stupid segfault.
C++ has improved a lot over the past decade or so. Compilers can add runtime checks now that make most memory bugs easy to detect and diagnose. C++ has plenty of warts and legacy stuff that you wouldn't keep if you were designing a language from scratch, but it is way better than it used to be and there still isn't anything that fills the same space C++ targets. Rust tries to but IMO it is too opinionated.
> It _looks_ easier to me because it lets me do anything I want. C++ makes me feel like I'm going faster, but then I spend two weeks debugging a weird memory issue.
It's quite a bit easier than Rust and no other popular language has its most important features (cross platform, interfaces with syscalls and other libraries easily, manual memory management possible, likely to be supported for a long time).