For me 2022 was the year of learning C++ (background in C# and Php) and I must say that after being intimidated by the language (extensive use of pointers, stack/heap compile/run time allocation and deallocation, templates) for years, when I really took a proper look and got some practice, it is an incredible language. The command an control you get by working with memory and the system on a lower level is amazing. I found it so much easier to learn (once I got the grasp of the cpp way of doing things) than something like Rust. All the higher level advanced concepts work and flow beautifully as you'd expect based on the lower level of the language... and the amount of "magic" is kept to minimum... you can just open std and look at what is being done and it all males sense. I understand why people want to move from C++ but as a newbie in this language, I find it amazing.
I work on a C++ project and actually sympathise with this sentiment. It's a massive strategic risk to our org, we pay a consistent tax in reduced productivity and stupid bugs, and I will advocate migrating away as soon as we have a suitable destination (Carbon looks promising).
But, I do also really enjoy writing C++! I'm optimistic that writing Carbon/Val/whatever ends up gaining traction in the industry will be just as good though.
The main beef with C++ is that it's just a mass of every single feature possible held together with some goo. It works, but there's no grace and elegance.
It is really only the fact that everyone writes C++ a little bit differently. From the outside this looks like C++ is a mess, but in reality, you can pick and choose what you like, and that's exactly what people do. You can be as safe or as unsafe as you need to be. That, of course, also opens the door for beginners to accidentally write unsafe code for a long time before they know all the footguns.
I think the real dent in C++ comes from wholesale improvements to languages by adding package management, one-liner built-in toolchains, built-in testing and build system. I could write paragraphs about why this is a good thing but we all know why.
CMake is making an effort in making it easy to fetch content for your build system, including Git repos, so there are paths to take today, but you need to learn a lot of separate things just to get started with C++. What are the chances that a beginners C++ tutorial gives you all the best practices in a way that a newer language does by default?
Learning C++ will probably look like the experience of using a web server with poor defaults, a strange configuration language, and thousands of different tutorials detailing a 20-year period of changes.
If I were to host content today I would not use Apache or nginx - I would probably start with Caddy and go from there.
> improvements to languages by adding package management, one-liner built-in toolchains, built-in testing and build system. I could write paragraphs about why this is a good thing but we all know why.
Not everybody shares this sentiment. I think it's great to be able to get yourself up and running quickly, and start dabbling with the language immediately, but I also think that at the same it is not so great because there is no "one size fits all purpose". I, for instance, happen to value the latter more than the former.
FWIW, I also wrote a lot of C++ for the first time last year, and found the lack of
> package management, one-liner built-in toolchains, built-in testing and build system
To be by far the least pleasant things about the language, especially C++20 where things like concepts are wonderful to use, but then you can't rely on having a toolchain that actually supports it.
The most recent xcode/Apple Clang do not, so on Mac you need to find your lib(std)c++ elsewhere.
It'd be great if there were at least some way to make this easy, e.g. to create a virtual environment that sets all paths correctly.
Or if the compiler from a toolchain would default to using its own headers and libraries instead of defaulting to the system's. (I assume they don't for a combination of historical reasons, and that you'd then you may be unable to link to system libraries due to things like mismatched std libraries).
Preferably, there would also be a GitHub Action to do it to make CI easier to set up.
> but then you can't rely on having a toolchain that actually supports it.
C++20 is still a bleeding edge so I'd advise you to pick C++17 or even C++14 if you want to have pleasant cross-platform coverage. That's what most companies with the goal of true cross-platform support will do. 3-year window time for compiler and library devs is really hard, especially given how many new features were introduced to C++20. And now consider how many different vendors there are ... https://en.cppreference.com/w/cpp/compiler_support numers them 12 but it doesn't count the ones from embedded space for example and probably some other are missing too, so 20? What we want to see on the paper hardly can match the much more complex reality.
> The most recent xcode/Apple Clang do not
It's a PITA, as usually found with Apple, especially considering that all other major compilers including GCC, Clang, MSVC and ICC work just fine: https://godbolt.org/z/Mj6ehq57v
> so on Mac you need to find your lib(std)c++ elsewhere.
This wouldn't work because concepts aren't a library feature but a compiler feature so perhaps your best bet would be to see if you can use vanilla clang or GCC to compile the code on Apple machines. I am not an expert here.
While C++ is the one with more features, the same can be said about Java 20, Python 3.11, C# 11, Haskell 2021,... when comparing against their version 1.0.
The problem of C++ is that its features are not just additive. In most languages, if you take two features and use them both, they add up. In C++, they may actively interfere with one another.
One example sorted out with Python 3 would be old style classes and new style ones.
Other would be tracking down if attributes get dynamically changed via __dict__, __slots__, and how __slots__ interact with each other if multiple definitions happen to exist.
The way numeric division and remainder changed between Python 2 and 3.
> In most languages, if you take two features and use them both, they add up.
Java nio vs. io
Java Reader vs. InputStream (not necessarily the interfaces themselves, but the redundancy between them eg should I use InputStream -> BufferInputStream -> InputStreamReader? Or InputStream -> InputStreamReader -> BufferedReader?)
Java float[] vs. ArrayList<Float> vs Vector<Float> vs. FloatVector vs. FloatBuffer - just how many ways can we describe "a linear allocation of numbers" in Java at this point? And they're still adding new ones!
So no, other languages don't just magically handle this more gracefully than C++ does. If a language is successful, it will either suffer from this or it'll stagnate - it's the natural consequence of preserving backwards compatibility while adding new features & capabilities.
Reader is for text/characters while InputStream is for bytes. An InputStream always lays at the heart of a Reader. Java's I/O may not be the most elegant of simplest, but it makes additive sense assuming you don't just have a bone to pick with the language.
The float examples are artifacts of pragmatism between plain old data types versus heap allocated objects. Though I do admit Vector<Float> is absolutely obsolete and should be avoided. The others have a clear purpose and raison d'être.
> The others have a clear purpose and raison d'être.
Yes, but they don't compose cleanly together. As in, I can't just use FloatVector in all places that took a FloatBuffer previously or whatever. They aren't additive in an incremental migration sense, they are additive in the "these are just wholly unrelated APIs in their own wholly distinct silos" sense. Aka, the thing C++ is regularly slammed for doing even though it's additions aren't even this clunky.
Yeah, that doesn't qualify. It is all one feature: override copy or move semantics, and there is a prescribed way to do it. Rule of zero, of course, is the norm, and is an extremely beneficial interaction.
C++ gets special treatment for some reason when it comes to backwards compatibility and modern language features.
Oh no! we got threads and timers! C++ recognized the existence of file systems and regular expressions, woe I say! Polymorphic lambdas? I've got std::bind1st haha! Wait, not atomic! Anything but that!
Yes, but I think this is the ultimate fate of most successful languages. New languages start small and elegant, and everyone raves over them, then over time new features get added, and added ... and eventually the elegance and othogonality disappear. If this was a program rather than a language, now would be the time to refactor, but you can't because of backwards compatibility, so eventually you get to c++-like bloat. I actually like c++ -, but it's definitely out of control at this point.. although many people just ignore the bleeding edge features and basically code in something closer to c++11.
Languages really need to evolve to stay alive, but the evolution will eventually kill them!
... are there really people who go into their office job and think "oh this tool I'm using needs more grace or elegance?". If I had a carpentry company and my employees complained that their hammers and nails weren't elegant enough... I'd quickly look for new employees.
I agree. It is honestly a fine language IMO and while I have nothing against Rust, I also haven’t had much of an interest or incentive to use it. Yes, buffer overflow is a thing - it’s never been an issue in my experience. Use after free and memory leaks are infrequent, easy to fix, and caught early.
Golang is not a real replacement because 1. Golang core devs are too opinionated on random shit and make some things very hard to do without reinventing the wheel because “you shouldn’t do that” partially because it’s a corporate-owned language 2. GC. There are other minor things but those are the big ones, it’s still an excellent backend language but can’t replace C++.
Besides Rust everything else is a toy without stability and backwards compatibility and/or lack of libraries. Rust is fine, it’s just that the problems it tries to solve aren’t something that experienced C++ devs often struggle with.
> Besides Rust everything else is a toy without stability and backwards compatibility and/or lack of libraries. Rust is fine, it’s just that the problems it tries to solve aren’t something that experienced C++ devs often struggle with.
The single main reason for Rust's success is that this statement was proven wrong again, again and again. C/C++ devs kept repeating it, severe bugs keep getting discovered.
Yep, I totally agree. I took a long break from C++ after I learned the basics at university. I got into it again one and a half years ago when I needed really fast code and I was pleasantly surprised how easy it is. I'm exclusively using smartpointers and I very rarely run into scenarios where I have problems with memory leakage, etc.
Since I had written the prototype in Java and now interface with Javascript/Typescript, I'm really amazed how clean and well-reasoned my C++ side of the program is. So yeah, I'm also really happy with the state C++ is in right now.
It doesn't deserve a flag, but the sunny optimism feels delusional. It's obvious that C++ has problems and there's obvious red flags like why someone like Linux Torvalds vehemently hates the entire language.
The poster addresses none of this and has a overly positive attitude towards C++. There's obvious nuance on this topic that the post fails to address and he instead just preaches to a biased choir. At least he admits he's a beginner.
All the Rust programmers I know are really happy to discuss the limitations and shortcomings of the language. It's possible that the problem you're pointing at comes from the word "reddit" rather than "rust" :)
Note: I've looked at the parent's comment history. The only one of them which was not a troll against Rust was a troll against the EU.
We use rust full time at my job, and griping about the language’s rough edges is a common pastime. The fanboys are loud and obnoxious but I can assure you they don’t make up the whole rust community.
Rust has its rough edges, but what people do is gripe about those in language development spaces. Then the rough edges get filed down in the next release trains, or sometimes the next language edition. In C++ they are totally unfixable.
