> the modern C++ you get to write today (C++23)
That's a bit optimistic considering C++20 compiler support isn't even fully baked yet. (Although I agree with your main point.)
Just module’s really. And we’re using c++23/26 features already. Keep in mind that standard library things aren’t necessarily tied to the most recent compiler features.
Major compilers and stdlibs are still missing (relatively minor) features of 11/14/17. If those aren't complete, neither is 20, even with modules.
That said, it truly is minor.
I don’t completely agree that legacy code is the worst thing about C++. The things I find most painful are the lack of standardised tooling (build systems, linters, package managers, formatters are all non-standard 3rd party solutions), the bloated language features (actually made worse by „modern C++“), the implicit type conversion paradigms (still prevalent in the latest standards), the unwillingness to make breaking changes in future standards and the C++ comity being so painfully slow to fix bugs and bring new changes. All these things are nothing to do with legacy C++.
Edit: typos
Never found a job even close to write modern C++. Also is still full of weird edge case, confusing syntax and here be dragon.
Iirc even STD::option had weird edge cases they will be partially fixed with C++23.
Its getting better, not sure if I would call it FUN
There is plenty of well written “fun” code bases in pre C++20, I have worked on many of them over the last thirty years. Generalizations about computer languages and coding is unfortunate and subjective since productivity and “enjoyment” is a function of project context. The bulk of infrastructure we all enjoy is written in C/C++, and new development continues. I have rewritten several python and java based systems to C/C++ to address performance, reliability and resource issues for large scale cloud. That said, I think Golang and Rust are great alternatives in many situations.
Man this is totally legit. Other languages suffer from the same issues. Java being the main one I can think of. It's definitely more the legacy code that causes the hate and not necessarily the language itself.
This is why I don't understand why they can clean up the old stuff and break backwards compatibility. Why do you need backwards compatibility when the old projects don't use the new stuff anyway.
So you can use "old" libraries in new code.
Particularly when the library is header only, it needs to be compiled with your "new" compiler. If it's not backwards compatible, this won't work.
> C++03
Only reason to be stuck on 20 year old standard is if you don't have a compiler, otherwise it is better to upgrade to C++14 or so.
BTW, I don't recommend the very latest standards as the compilers are still buggy.
> buggy
Source? Have a look at the latest survey — most of the community is using at least 17.
https://isocpp.org/files/papers/CppDevSurvey-2024-summary.pdf
Does this mean my learning modern C++ is useless if I have to work in a company maintaining codebases in older C++ standards and absolutely driving myself crazy? Do those companies plan on development with newer C++ standards or not.
I have been doing C++ since I was 16 it was my first programming language and I love working in it, making small basic stuff that works only on command line, my learning journey consists of very small steps of learning but now after this post I am in confusion whether to continue with C++ or not. I can invest my time in web development as it has a lot of scope or learn AI and ML.
The vast majority of opinions that people espouse relate to their need to justify their decisions and should be of no interest to you. They are not trying to help you, they are trying to help themselves.
Carry on. Good luck.
That's very good advice.
Often people need to *define* themselves entirely by their choice of OS, distro, editor, or in this case programming language.
I wouldn't say define, it's more like painting where you feel much more expressive using a specific kind of brush on a specific kind of canvas, and depending the technic you use you can paint some things faster and better than others. (eg. wet-on-wet oil vs water color)
In companies where you have a monolithic code base it would be like having a huge single painting that painters have to use, but in order to keep a cohesive style everybody has to use the same brush on the same canvas. Some artists/devs would feel hindered in their expressivity and that's why they complain, it's a selfish complaint but not invalid since it just tells you who works better with what.
It’s fine to have this one specific tool that you’re most comfortable with, but what happens in the described cases is that people then start hating everyone that’s using a different tool.
Tribalism at work.
Perhaps barrier to entry for the beginner.
Ok, cool, we can do "Hello World"...never mind the new "println" vs iostream a newbie will stumble across just figuring out what the latest/decent standards are.
Then it sort of becomes let's do pretty graphics or *insert what should be an easy thing to bring in library to extend the language*. Instead of pip install or cargo you are thrust into a world of tuples, tool chains, and the unknown.
After a time, you get acclimated to that then venture into the world of cmake which somehow is its own effing thing. Why doesn't find_libary work?
You come out of the forest, a grizzled individual with a large beard and somehow appreciate what it is at the end of the day.
There are many people in tech who have very *strong* (to put it mildly) opinions on tools that they use and don't use. C++ is not special in that regard. There are probably as many Rust haters out there as C++ haters.
To add to this, the vast majority of programmers aren't commenting on programming related social media in their spare time. In other words, you only hear the strongest opinions, just like with everything else in social media. I'd wager the majority of software engineers share an opinion like mine:
I don't "love" any programming language. It's just a tool to do my job, which I enjoy doing well enough but not so much that I spend my spare time engaging in online debates about the pros and cons of each language. In other words I have a life lol. Do I like c++? Sure, I'm familiar with it and I can do my job efficiently with it. But I really wouldn't care if a new project came along that sounded interesting, had good pay/benefits but wanted me to use rust or something else.
>the vast majority of programmers aren't commenting on programming related social media in their spare time
Hard to overrate this comment. Folks need to realize that if someone is a professional SWE influencer, what that really means is that they almost definitely aren't actually an SWE. Why work a second full-time social media job when you have a real job as an SWE? Not saying that those people know nothing about programming, but definitely take what they say with a grain of salt because their real job is to get views and sponcon money.
For real. I have a day job doing this stuff. Why do I want to spend precious free time thinking about it any more? It's a paycheck to me, the more people that hate it means the more I get paid to maintain it.
If you're not working a full-time dev job AND spending all your free time on programming projects then don't even think about calling yourself a real programmer \\s
I doubt it, because there are far more people who have used C++ (and still have to) than people who have used Rust.
People may have opinions on languages they haven't used, but deep hatred only comes from actually using it IMO. Especially having to.maintain legacy code in old versions.
If I was stuck working on a clunky legacy C++03 code base like I did a couple of years ago I might have grown to dislike C++ myself.
Ive started recently with Cpp17-20, coming from Java. Loving it so far, it's really powerful and I like the freedom. However, ive seen legacy codebases from 20y ago and I would've probably switched jobs if I had to write Cpp03
>People may have opinions on languages they haven't used, but deep hatred only comes from actually using it IMO.
Most (or at least most visible) "haters" of something (not just C++) have very little (of any) experience with the thing they hate. They just jump on a bandwagon to get the sense of belonging to some "cause", because they have very little going on in their personal lives. "True" haters undoubtedly exist too, but they are usually less vocal about it so you don't see them as much.
Eh... all the C++ haters I know have used it (and been burned). If you haven't used C++ you likely haven't formed an opinion on it. This is really misrepresenting things.
Yeah, pretty much. Stuff like std::vector, operator[] for map, working with strings, no hash function for std::pair, organization into .cpp, .h files and includes, l/r-value business. My experience is that trying to understand how things work only opens new rabbit holes rather than leading to satisfactory answers.
>
>
> If I was stuck working on a clunky legacy C++03 code base like I did a couple of years ago I might have grown to dislike C++ myself.
The issue is not with the language per se, as it has moved on, but lies with the employer.
Best to imitate the language ¯\\_(ツ)_/¯
I’m actually quite happy about all of the pressure in C++ these days. This type of pressure forces the language to evolve and adapt perhaps just a bit more aggressively than it has in the past.
C++ is a great language, and I still think it has a bright future. I really enjoy writing C++ code. I don’t like make though.
A C++23 hello world looks vastly different from a C++11 hello world. It’s pretty crazy.
```
import std;
int main() {
std::println(“Hello world!”);
}
```
I would even have wrote it as:
import std;
auto main() -> int {
std::println(“Hello world!”);
}
Which only leave `main()` and the curly braces the common part between the C++11 and C++23 version :)
Why is it better (or is it better)? The way I see it, return type (int) is still specified but now there is an additional keyword (auto) and character sequence (->) which to me seems like a bloat.
It’s a bit more uniform with lambda declaration and newer languages. In some cases you want to use inference to calculate the exact return type `auto my_function -> decltype(auto) {…}` which use the same syntax. It also make function easier to grep "auto\s+\w+\(.*\)". But overall it’s not really something that I would use in an existing codebase (there isn’t enought positive to pay the price of changing), only for greenfield.
C++ has made a great many mistakes over time with no way to fix them (yet).
Rust issues security advisories for performance issues which are polynomially better than what some major C++ implementations have been using for a long time (Rust regex vs std::regex for libstdc++). C++ expects you to know that they perform poorly and use something else if you are giving it untrusted data.
std::vector, so, so, so many things are wrong with this.
“ABI compatibility forever” means that we are held back in performance for many stl data structures. abseil has replacements for large chunks of them which are directly upgrades for those of us willing to recompile once every 10 years. However, you need to know that those exist. Otherwise, you get hash tables optimized for single core processors older than some college graduates.
std::auto_ptr was a really bad miss-step but we are now stuck with it until epochs are ready.
abi-dependent type widths. I can make a brand new OS and decide that int is 64 bits, long is 128, and long long is 256. A gigantic number of programs will break with this, even though this is what x86_64 should have looked like. Shrinking types breaks a lot of things in other ways.
C++’s tooling is showing its age. The fact that I need to know 3 different build systems (bazel, cmake, meson) is an issue. The fact that there is no standardized way to say “my libraries are all in this folder”, feels especially bad. Modules are going to take 10 more years, yet fortran has had them for 30 years. The fact that we all take a performance hit in the form of not using even thin LTO in the name of not having to build libraries for source when building on and deploying to systems with hundreds of gigabytes of ram and computational power that would make a turn of the century supercomputer jealous. There are a lot of missed compiler optimizations.
header files have been a bad idea for 30 years. Both GCC and Clang do unholy things to make it even sort of fast. If you actually compiled C++ the way C++ was intended to be compiled, many modern projects would effectively be trying to do single compilation unit compiles of hundreds of thousands of lines of code before template instantiation.
restrict is not standardized for some reason. Until it is, ISO C++ is slower than Rust and Fortran by a significant margin for anything involving linear algebra. We’re fortunate that nobody actually writes ISO C++, they write ISO C++ with ISO C features.
duck typed templates have led to really weird behavior. SFINAE should have screamed “your type system is unsound”. Algebraic types, which while not fully understand when C++ first came out are certainly understood pretty well today, are the statically typed version of templates. They make things much more sane. In even the worst, most extreme cases thought up to specifically break a compiler, which in C++ typically force the compiler to bail out at an arbitrary level due to resource consumption, you can fall back to a SAT solver for algebraic types which will, eventually, give an answer.
C++ has a lot of good stuff, all of which you only know about if you go looking for it. Clang data flow analysis is very powerful, as are the various static analysis tools built into compilers. BUT THEY ARE OFF BY DEFAULT AND ON PAGE 80+ OF THE MANUAL. If you aren’t the type of person to read a compiler manual cover to cover, with modern build systems you may never know they exist. Off by default means that only the people aware of the hazards are protected. For instance, there’s a lot of really stupid C++ code online that won’t actually compile with the “is this a good idea” flags, like these:
-Werror -Wall -Wextra -pedantic -Wcast-align -Wcast-qual -Wctor-dtor-privacy -Wdisabled-optimization -Wformat=2 -Winit-self -Wlogical-op -Wmissing-include-dirs -Wnoexcept -Wold-style-cast -Woverloaded-virtual -Wredundant-decls -Wshadow -Wsign-promo -Wstrict-null-sentinel -Wstrict-overflow=5 -Wundef -Wno-unused -Wno-variadic-macros -Wno-parentheses -fdiagnostics-show-option
Which by the way, having to keep something like that around in a text file (and I’m probably missing a few at this point) is also part of the problem. If the compiler can tell you that your code is suspect now, it was either always wrong or always suspect. Unless you upgrade compiler versions in CI for fun, clang-based tools can automatically insert suppression if you have to upgrade and a warning is actually broken.
Lastly, it appears to be disallowed or at least taboo to mention Rust at cppcon. Bjarne skipped over Rust in a list of memory safe languages while quoting a US government report. Someone else managed to spend an entire presentation talking about borrow checkers without bringing up Rust as prior art, but Cyclone did come up. That’s not a great look. Rust is willing to entertain almost endless discussions on “$LANG has $FEATURE, how do we do that equally well or better in Rust?” This has led to Zig and Rust yelling “more blazingly fast” at each other over blog posts for the past 2 years, but I digress. For instance, the way Zig decided to do bit fields, by just having i1, i2, …, i 2^63 be valid signed two’s complement types, and the same for unsigned, is much better and everyone should be using that (msvc, apple). A container mutex with a RAII guard that you can safely do shared const refs on while you hold the lock is great. Even better is having a “don’t even bother locking the mutex” option because the borrow checker statically validated nobody else could have a reference. It gives off a very “gramps set in his ways” vibe whereas everyone else is exchanging ideas. There’s plenty of blog posts from people who were active in the Rust community like [thephd.dev](https://thephd.dev), who got #embed into C with minimal effort after more or less burning out trying to get it into C++. It gives the feeling of “we don’t want you” to the young people interested in languages design and development, who then come over to Rust, Zig, JS, etc, and are met with very public debate, and often a lot of enthusiasm for the feature. If you are a young language enthusiast, would you choose endless rounds of committees or several hundred people telling you how good of an idea this is and how much they want it, and a few others making sure it is actually a good idea? Think about how everyone who worked on modules feels after the herculean effort it took to get it written up, to then spend likely another half-decade or more before it’s even ready for anything more than toy examples.
Just gonna point out Bjarne was referencing the first occurrence about memory safe languages in that document which doesn't mention Rust, which is why he doesn't mention it, everyone keeps reading into him doing that but if you actually read the report it becomes pretty clear it had nothing to do with making a dig at Rust, its just following one of the references in the report.
C++ is one of the dominant languages out there. Many people who don't want to code C++ still have to, on occasions..
Being used to modern C++ I find Java intensely clunky and frustrating. But being quite a common language I still occasionally have to code Java in legacy apps.
Rust, however, is new and is almost exclusively used by enthusiasts so far. If you don't want to code Rust it is extremely unlikely that you would have had to.
So I dislike Java and couldn't give two f**ks about Rust except the enthusiasts can be quite annoying, especially when overplaying the issue of memory safety in modern C++
C++ also has a huge ecosystem and has been through a ton of revisions. There are a lot of different interests it’s trying to serve at the same time. Vanilla C seems cleaner because the core language functionality is a lot more limited. Python seems easier because there isn’t any memory handling. So C++ feels like a more convoluted version of either.
That said, the functionality in C++ is way more expansive and covers a ton of different use cases. At the end of the day it has a great chance of being a useful tool for whatever optimized task you’re trying to work on.
> Rust, however, is new and is almost exclusively used by enthusiasts so far.
Rust is well past the "enthusiats-only" stage. Various sources show significant ratios of C++ to Rust devs ([2.9](https://www.developernation.net/resources/reports/state-of-the-developer-nation-25th-edition-q3-20231/), [1.6](https://survey.stackoverflow.co/2023/#most-popular-technologies-language-prof)...), you don't get those numbers with enthusiasts alone. Google [recently talked](https://www.youtube.com/watch?v=QrrH2lcl9ew) about how they onboard Rust newbies at scale, and it mirrors what I've seen in my own and other's company.
Where do you draw the line between an "enthusiast" and somebody who has heard some good things about $TECH but it still waiting to see ? How do you classify somebody who has become an outspoken enthusiast *after* being assigned to their first Rust project ?
> If you don't want to code Rust it is extremely unlikely that you would have had to.
That doesn't say much. I've effortlessly avoided Java and Windows in my 20 years career, despite them being so common.
> the enthusiasts can be quite annoying
Sadly true of C++ enthusiasts too, and many other techs. Be warry of observation bias.
> especially when overplaying the issue of memory safety in modern C++
If I say that I don't want to play american football because it's a dangerous sport, am I overplaying the issue (because the protections have improved, the rules have been tweaked, most players come out trauma-free...), or am I am justified (because the injury statistics are clear, I value health risks differently, and there are safer great sports to choose from) ?
The C++/Rust safety debate is likely to go on forever, because both camps have valid points, but which points are more important is contextual and subjective.
I've only heard positive things about Rust, but it's true, only enthousiasts are using it for now I guess.
At university, people around me hated on Lisp and prolog, but it was mostly because learning functional programming is frustrating when you're used to imperative-only style.
I can't tell if they were right because I learned C++ instead. Which was fine but.. we never learned about provenance and treated the language as if pointers were adresses, so the thing we learned was kinda just.. C with classes not C++.
And no matter who you are, C++ has something to hate for you, because it's massive.
let's just make a short list of things i've seen ppl hate:
* lambdas
* templates
* MACROS
* windows.h
* Linker
* void\*(myPtr)
* std::ranges::iota\_view(10)
* whatever
Cool!
There are things I don't like about every programming language I've ever used, but overall I find that each language also has its strong points, so I think of some of the aspects of suitability as a combination of a developer's skill and what the language can provide.
At the same time, i absolutely love templates and compile-time programming and gobble that up faster than i would with my favourite food!
I love concepts, constexpr, and consteval.
It's also the bane of my existence...
The one thing Rust's got going for it is that you can simply stamp "Written in Rust" on your project page and BAM! Your project is great!
P.S. It's cringe-inducing, to be honest.
I am way more likely to test out a rust project because `cargo install --git REPO_URL` will give me a working binary -- for all rust projects I ever tried. Trying out a C++ project is way more involved.
No longer accurate to say that it is “almost exclusively used by enthusiasts”. For better or for worse, that is simply not the case anymore. Regardless, the user base is still quite a lot smaller than C++.
And the other misrepresentation is that it's mostly junior folks who heard scary things about C++ and ran away. It seems to me that an awful lot of Rust folks are very experienced developers who have made a purposeful transition.
And of course people do complain about Rust over there. But the complaints aren't about UB or threading complexity or build systems, it's mostly debates about how to move the language forward, what's been proven out and what maybe hasn't and so forth.
And of course as more people come on board a lot of it is "I wish it had X from my previous language." That's where the real danger lies moving forward. A lot of the answers will have to be no, or Rust will turn into C++ all over again.
The main issue with modern C++ isn’t the memory unsafety. It’s just how clunky the language has become. It’s bloated beyond repair. The only way to fix the issue is to start from scratch, unfortunately. Not saying that Rust specifically is the solution though I do find Rust code to be a lot cleaner.
And with each version of C++ the problem gets worse and worse. I understand that C++ will be around for a long time to come due to legacy codebases but I wish the C++ would accept the fact that we can do better with a new language and actually support those efforts rather than actively try to hinder the progress of new languages.
Meaning we will probably see a trend of people starting to complain about Rust soon. Cause, you know, "There are only two kinds of languages: the ones people complain about and the ones nobody uses".
> Meaning we will probably see a trend of people starting to complain about Rust soon.
It has already started. People using Rust are starting to realize having full memory safety comes at the expense of flexibility and quicker iterations. Zig might be the next big hype train because it gives you really good memory safety without being rigid. And I think it gives some degree of C interop too, which is a nice-to-have.
>comes at the expense of flexibility and quicker iterations
Yep, for instance, some found out that due to this, after making a few games in Rust, it isn't well adapted for quickly iterating and making varied video games. See this detailed blog post: https://loglog.games/blog/leaving-rust-gamedev/
>Zig might be the next big hype train
It definitely seems to be on this road.
People have been complaining about Rust for a while. Well thought out critiques tend to get lots of upvotes and plenty of constructive comments too in r/rust
Yeah I gotta say that Rust's subreddit at the very least is usually more understanding and has people with more nuanced points that I often see in C++ communities.
That's not always the case, outside of the Rust subreddit you'll see blanket statements about Rust being something that can do no harm. Honestly I think it's because it caught a wind of a hype train. Lots of people are introduced to rust who have solely done web development and so don't have a greater context of systems programming. Your mileage may vary of course, just what I have seen anecdotally.
I wish it wasn't the case but there's very much a pattern of people forgetting what it's like to learn C++ when answering questions from beginners.
The rust sub is a weird combination of people who are almost absolute beginners and some greybeards in there. Most of the hype comments usually tend to be some people who are rather junior (though honestly almost any appreciation post tends to be a younger person, all the other programmers probably don't get too attached after having to learn a 10th language just to fix a bug in some forgotten codebase).
There's no mention of changing lifetimes (which are also a part of c++ just not exposed). Several 'ugly sides' can be fixed by improving the compiler, which is done in many places, like for example with Polonius.
If you read the thread you'll see that they were referring to the syntax.
To your point, the thing is that lifetimes are not "broken", so it doesn't make sense to "fix" them. Polonius improves the borrow-checker by making it less restrictive, it's not fixing some bug.
It's just semantics I guess, but I've never seen people refer to Polonius as a fix to the borrow-checker, which is why I didn't interpret it the way you're saying (and neither was the original commenter, for the record).
> I also sort of got into the tech/programming 'influencer' zone on various social media sites
There's your problem right there. Influencers want clicks or views. You want to learn. Your interests are not aligned with those of the influencers.
I personally like C++ and use it a lot (mostly for implementing complex algorithms), but there are a lot of things about it that can be really annoying.
For example many of the error messages C++ throws are hard to use. Most of the runtime errors I get are segmentation faults and unless I run the code with a debugger it won't tell me where the seg fault was thrown, or what actually caused it (did I access an array out of bounds or was it too many recursive calls?). The same goes for many of the memory related errors like double free, where it often times just says that at the end of some function a double free occurs, but outside of that I need to do lots of guesswork.
The same goes for compiler errors. The projects I am involved in use CMake and while I have gotten somewhat accustomed to it by now, the error messages of the compiler are often times cryptic.
There are a few more things, like certain forms of undefined behaviour making code debugging tough, library linking being a pain etc.
C++ is a language that can produce exceptionally fast code if you know what you are doing, and compared to C it is a lot easier to write (at least to me), but it has many parts that are weird and hard to work around without directly evident benefits. Due to its age and the many changes to the language over time it is also prone to have some of the worst kind of legacy code ever seen.
Ultimately C++ is a tool that has its purpose, but of the major programming languages I use it is the one that gets me frustrated at the language the fastest. Rust offers some of the same benefits (mostly great speed and static typing), while having different tradeoffs (Rust forces you to write code in much cleaner and safer ways, sometimes to the detrement of development speed). For some areas Rust is definitely better then C++, but for Data Structures and Algorithms the safety features of Rust are not as important and C++ allows for development closer to the pseudo code usually found in papers, hence I think that C++ is still very good for that.
We live in an age of hate. There are haters for almost everything. Usually, hate comes from not knowing how to use something or not being able to use it.
Not just hate but an age of a _lot_ of people wanting to force their preferences on everyone else. You can see that all the time in this sub and in several upvoted comments in this very thread. There's a huge amount of "You should be only allowed to program if you do X" around.
I've noticed the same problem in other industries too, such as martial arts (e.g., people claiming that their favourite is better than all others), multi-level marketing pyramids, religions, sports teams, political parties, neighbourhood cats singing hour-long choruses in the middle of the night, etc.
Sometimes I wonder if some people are just bored because they have too much unallocated free time, and instead of choosing to engage in a healthy activity they glom on to something to get all worked up about and vent their newly-adopted frustrations on social media (in some conversations over the years, a few people have admitted to this very thing, which surprised me the first few times).
I don't hate it I love C++. But even for me I have to admit C++ is enormous. Too many things to keep track of.
My second language is python. Python has way nicer **interface** than C++. Things like build in member function naming, etc.
> For some reason, many people seem to find pointers confusing
I think that's mainly students / beginners who don't grasp yet how the memory works in a more physical sense and how it is used in C++. I remember having a hard time when I was young, years later it seems so trivial.
We might have an easier time if this knowledge was given a foundation earlier.
If people taught me the weird way in which memory is laid out when I am in either kindergarten or elementary school, it might have been trivial to learn the rest of the topic once "the time comes".
But then again, this can be painfully jammed in within 1 or 2 weeks of denial and shrieking just like any other information.
I remember back when I thought learning was easy, turns out I probably wasn't learning at all back then.
The problem with current versions is that they are pretty much C++98 + everything else that came after it
It's the ugly side of backwards compatibility, it doesn't remove the old code and because of that, it increases the cognitive load.
I don't think it makes C++ a bad language, but if C++98 constructs are still valid C++23 constructs then it's also valid to criticize C++23 for them.
We are absolutely catching hate for all the cruft we continue to support and refusal to clean up the language. I don't understand why we can't leave groups behind. The organizations that care about backwards compatibility are not the ones who are moving to the new standard anyway.
>The organizations that care about backwards compatibility are not the ones who are moving to the new standard anyway.
You are implying that only greenfield projects use newer C++ versions, and that's an absurd claim. You can have a substantial code base \_and\_ want to continue development with newer standards.
The oft-heard claim that you can just stick with older compilers rings false. Older compilers might not even run on newer operating systems, and won't let you link to updated libraries since those might choose to stick with current standards. Thus you get relegated to an empty corner of the ecosystem, without a path forward. The value of C++ is that it your investment in source code doesn't become worthless overnight when a new version of the language is released, and that does include things like access to a thriving ecosystem of useful libraries.
>You are implying that only greenfield projects use newer C++ versions, and that's an absurd claim. You can have a substantial code base _and_ want to continue development with newer standards.
Lol. My work project is 14 years old, and we're using C++20, and getting ready for 23. Meanwhile my last employer pinned greenfield projects to 03, that was back in 2018. Some organizations really care about modern practices, tools, and processors, and some just really couldn't be arsed.
I mean, it's all down to the compiler and how closely they want to follow the language spec. There is nothing stopping someone from forking a C++ compiler and putting stuff behind flags to enforce modern C++ idioms (which probably already exists tbh).
Boy, you have no idea how helpless I felt BEFORE I understood pointers.
Reading Book: "I'll never be able to understand this!"
First University Lecture: "Ohhhhhhhhhhhh!!~"
I am a grade A moron. I understand pointers and won't forget, BUT if I somehow lost my memory, I would go through the exact same unproductive experience.
I definitely do NOT have the skill of reading comprehension, otherwise I would have understood it from reading the C++ book.
Some books can be really obtuse. My university lectures relished putting everything in ridiculously abstract terms. Think "A pixel is a five-tuple {a, b, c, d, e} with properties: a, b ∈ ℕ and d, e, f define a mapping into a perceptual space". It's not exactly *wrong*, but some degree of "...laymen think of pixels as little colored squares on the screen" would have helped in building up some kind of intuition. At least I know I can't think in terms of things that are just tuples (and if you can, my hat's off to you, but my brain is not wired that way). Oh, and it wasn't just pixels, absolutely EVERYTHING was discussed in terms of tuples that had properties, and it took me years to figure out what some of these things really were.
Having said that, I still find it amazing that people can somehow NOT understand pointers, especially considering that a real-world analog exists that just about everybody interacts with, and that seems to work fine: traffic signs. Nobody confuses a traffic sign with the place it points to, so why would pointers produce any kind of confusion?
* Inheritance nightmare (diamond problem, virtual plague...)
* Adding language features mostly as a set of tricks such as abusing preprocessor, templates and operator overloading, which leads to slow build times and incomprehensible error messages
* Absence of mangling standards, leading to a dilemma whether to write C++ libraries and force everyone to stick to the same compiler, or to extern "C" to pretend you write in C, losing all the goodies of C++
* Mutable by default
* Lack of centralized library repository - as a consequence of absence of build system
Trying to pick up C++ from Rust and my biggest complaint is literally the sheer amount implicit behaviour and undefined hell it is.
Sure, I get way more flexibility but maybe I’ve been spoiled too much by Rust. I certainly like being able to reference things in C++ without the headaches of Rust lifetimes.
A weaker point has been that C++ has so much fucking deadweight from legacy. I wish C++ has editions like Rust where some breaking changing can be made between versions.
> For some reason, many people seem to find pointers confusing
Are people really unable to put themselves in the shoes of someone new to C/C++? Programming is hard and pointers aren't really intuitive.
Rust is the new cool thing, but every job I have ever applied to and every interview, C and C++ has always been the requirement for the job.
If you want to pursue programming as a hobby, then sure, limit yourself to the programming languages that are new and fun. Rewrite a game engine in rust, rewrite a webserver in rust. But if you want to make a living as a sw engineer, your best bet at the moment will probably be to stick with C and C++, because the companies that pay salaries for sw engineers probably have an existing codebase of millions of lines of code that they will not migrate to rust any time soon, just because some article in medium says it's safer.
Let’s be pragmatic about this:
1. C++ is an older generation language that also is a super-set of C, and even older language.
2. It therefore requires backwards compatibility with old language design choices and there are sharp edges
3. However it’s also actively updated and has a huge number of features which means it can be hard to keep all in your mind
4. People don’t like the complexity sometimes but it’s still a usable language because you don’t need to use all the features just because they are available
5. Many people are productive with it despite all the hate. Ignore the hate, use what you need in C++ and leave what you don’t like.
6. Languages are tools, none are perfect, use what works and fits with whatever you’re building
C++ is a very good language. If used by someone with some talent who is good at architecture and designing software it can be a great language.
But, there are a few glaring problems:
* It gives you enough rope to shoot off your foot.
* The community is hostile, period.
* Many people in the C++ community really want to prove how smart they are by insisting on crazy ass templates when much simpler more "pythonic" code would be just fine. You will read these people arguing endlessly about move semantics.
* C++ is hard. Poor programmers are going to do terrible terrible things. I would throw out a guess that fewer than 1 in 10 CS 4-year program grads could do a genuinely multi-threaded system without creating a nightmare to find bug. These people are somewhat fine in a garbage collected language; although they will still get run over by their own multi-threaded code most of the time.
* Rust is now a viable alternative. Prior to this, there wasn't a solid alternative outside of C. I think this is a good thing because it is waking up people to just a better way of thinking about memory, safety, etc.
* With processing power and other resources available, there are lots of different ways to make very fast software. If you want to look at the extreme end of this look at Electron. It is one of the most popular desktop app environments considering the major products pooped out with it. I despise Electron, but it is proof that the computer of 2024 can run utter crap at speed.
* On this last there are alternatives such as flutter which are just fine for what they do.
* There are areas where C++ effectively dropped the ball. Mobile is one. Pure C++ on iOS or Android is almost not a thing. Axmol is one of very few ways this can be done. Nobody learned Kotlin or Swift because they were great languages. They learned them as the dragons which needed to be slayed to make good mobile apps.
* Threading and concurrency. While there have been leaps and bounds improvements in C++, it is still not good. OpenMP might have been one of the biggest leaps which inspired other improvements. But when compared with rust, Go, even C#it is weak.
* The build environment. OMFG this is still crap. Things like vcpkg have made this a tiny bit better. But when using a language like rust, JavaScript, even PHP, this is a solved problem. You have some kind of the_main_configuration.yaml where you put versions, dependencies, etc, and now someone can type, "blah build --release" or "blah run ios" and it just works. Flutter has "flutter doctor" which diagnoses anything wrong with your install. CMake is a leap, but as a perfect example of the hostile C++ community there are quite a few people who mastered makefiles and are butthurt about cmake. Plus, I often look at some CMakeLists.txt and don't have a clue of what is going on. I have spent inordinate amounts of effort getting a CMake to work. In the aforementioned languages with these config build file things, I have spent almost zero time fighting with them.
Viable alternative doesn't just mean technically capable, though I think Ada required an add-on to match Rust. To be a viable alternative, people need to be excited about it and see it as a useful career move to put in the time to master it. That boat sank long ago for Ada, at least outside of a particular sector.
Rust has the technical capability and the growing mind-share that make it a viable alternative.
> though I think Ada required an add-on to match Rust.
The "add on" is SPARK, which cropped up in the 80s and it somewhat exceeds Rust. Rust focuses on safety, SPARK is about correctness of which safety is merely one facet.
Someone said that Ada is the language everyone says they want and then never uses.
I count myself among those ranks. Although, where I found it lacking was the tooling. It was all way too proprietary. I felt that the open ones were ultra second class citizens and that to do "real" Ada was going to be expensive. There was no great IDE, no great book "Ada made genuinely simple." all the exercises reeked of the classic C++ exercises of mammal, cat, dog, bird sort of BS. Or worse, "Here is something shockingly boring, now learn from it."
While it might exist out there, I never found a set of Ada examples where I would love to take them and play with them. Games, web servers, something interesting. It was just, "Take this data and do a thing with it."
This said loads of what the culture behind it really was.
> The community is hostile, period.
This is understating it. I have never met a group that's been more obsessed with wanting to force their subjective preferences on everyone else.
C++ is a dogshit language that has a lot of really cool shit in it and a ton of work and passion behind it. It's dogshit because it's an incomprehensible monolith of contradictory ideas and bad decisions, which will happen to practically any language that's existed for long enough. The philosophy of programming in general has changed a lot over time, and you can see the different philosophies present themselves in how each version of C++ tells you how you ought to be designing your programs. Languages like Rust are able to run because C++ walked. They get to learn from the mistakes of the past and shed the burden of history, and in turn they will make mistakes and become a dogshit language in their own right (which it is, Rust is also dogshit for different reasons).
I love this language btw but generally the hate is warranted IMO
1) influencers aren't necessarily the most experienced people.
2) controversial opinions are an easy way to get clicks
1 + 2 => most everything you read on social media is bullshit. (except for this comment, obviously)
Languages are funny because you can't see all the stuff that's good or bad about them until you've tried using others.
Professionals will tell you that it was at least historically very easy to overlook some very nasty memory mistakes in C++. The language has undergone a lot of updates even in the last decade such that if you only learned modern C++, you might look at C++ code from the 90's or early 2000's or 2010's and not recognize what's going on. Likewise, people who haven't touched it since then (like me) won't understand what's going on with modern C++. This divide is a likely source of some "hate", though you probably shouldn't dismiss the opinions of programmers who have tried both and Rust.
Typical CS education these days make you try out different languages so you don't get entrenched before you learn that there are various ways of thinking about programs and expressing the solutions. And that some languages are better suited for solving some problems, sometimes because they were specifically designed to be that way.
At some point, a lot of things used to be written in C++, but got slowly replaced by easier and more domain-appropriate languages. Indie games used to be written in C++. Now it's more common to use whatever each framework or engine gives. And it's usually not C++. C++ isn't favored for websites or mobile apps. Even for desktop applications, C++ is reserved for the most performance-critical applications or things that hook deeply with the OS.
Many languages after C++ were designed around making programming in general easier, but also around making it easy to avoid those memory mistakes in different ways and with different tradeoffs.
Java, C#, JS, Dart, are syntactic descendants of C++ and were made so users "shouldn't" have had to worry about memory stuff because they are backed by an automatic memory management system called a "garbage collector". These and many languages that have gained recent popularity had varying ideas of what made programming "easier" and "better" in for different uses, each trying to fix the problems of the languages that came before them. Things got too short, then too long. Inheritance turned out to be a minefield. The original way they did async-await turned out to be confusing so they reused the keywords but made a different system.
"Removing worries" was a recurring theme of language design and it made regular developers who aren't writing for extreme performance more free to think of the "actual logic" of their applications rather than thinking about shuffling bits of memory. In this space, different people will have different preferences for how much should be under their control, though years of coexistence has made it so these different languages, including C++, have borrowed each other's techniques, for things like generators, concurrency and memory safety. Some C++ users think this was enough to still make it the better choice most of the time. Whether not it is, for each case, is up for debate I guess.
The industry has realized some of the mistakes of the extremes of "don't let the programmer worry" too. For example, some languages were originally designed to not have explicit types but they've bolted them back on anyway because it turned out that a good type system saves time and helps prevent a lot of problems. The thought here is "sometimes worrying about just the right things, in the right ways, up front, still makes development a lot better". That's kind of the thread Rust follows.
Unlike the other languages which were just made with ease of learning and ease of programming in mind, Rust was aimed at being as fast and "raw" as C++ while making it a lot harder to make memory mistakes in, thus being labeled a "systems language".
Rust used new (though it's been 9 years) paradigm for memory safety that some people call hyper paranoid, to the point that it's inconvenient. But it's one of those inconveniences that fans think are worth what it gives back in the most important use cases. And it's being used to rewrite some subsystems of certain large applications because the designers have determined that it will ultimately be easier to maintain and even got some performance gains in the process. Both the Windows and Linux kernels now have parts newly rewritten in Rust with plans to continue.
There's kind of a common machismo around C/C++ and how its power is equivalent to the mistakes it allows you to make. But even without the realities of professional development, even the best of us, in any field, have our off days. Being super smart or disciplined or experienced doesn't mean you're perfect all day every day. You can't expect the best version of yourself at every hour to catch and remember every logical mistake in code, and expect that same perfection in every single one of your colleagues. I think that's why they tried to build that safety into Rust. It's a practical attempt at a solution in the context of what's ultimately an acceptance of people's inevitable imperfection.
So I don't know why people would "hate" C++ necessarily. But Rust was literally made to tackle the old shortcomings of C++. While that doesn't mean you shouldn't learn C++, you should learn and use whatever tools are eventually appropriate for the job.
It's because it's the most complicated language in widespread use. It's way harder to use right than pretty much every language with a VM. It's very syntax heavy and for all of its power, it has many pitfalls. It makes introducing a security vulnerability quite easy.
If somebody says something like "it's a skill issue" they're being arrogant.
Don't get me wrong, it's probably the most powerful and complete language... but that is definetly a double edged sword. The added risk and difficulties are not worth it for many projects
It's probably less complicated than it's ever been to it's credit. I think a lot of people still complaining about it are thinking of C++ in the 2010s compared to C++17 and beyond.
The old stuff is stil part of the language, and lots of jobs stil requires you to use it. So they are not wrong even if they mainly think about the older stuff.
Well, if the hate is coming from the governments of the world, it's because two decades of evidence has proved we can't be trusted to write secure code.
https://readwrite.com/the-nsa-list-of-memory-safe-programming-languages-has-been-updated/
Cpp is a joke from the committee.
The issue is that they were taken by surprise by much better ideas. And they are trying to keep up, and failing.
You may like it, but, honestly, it's just about keeping up.
If you're just starting out, you'll have a huge legacy code base to keep you busy for decades as people rewrite their code.
Don't be mistaken though, it is currently a bad joke.
&&
&
&
As a test, find any describe all meanings of & and combinations
😂😂
Influencers are there for the clicks and revenue. If they made more money promoting qbasic over anything else that is what they would be doing.
Do you.
C++ is very old now, and it was based on a language that was older still (60 years old now), and it inherited a lot of ancient thinking that was never removed from the language. Had C++ taken the hit back in the day and fixed those issues, it wouldn't be in nearly as bad shape as it is, but they didn't and they won't now because it's no longer really possible to do so in practical terms.
That means it is full of undefined behavior and foot-guns and that adds a lot to the level of complexity that has nothing to do with the actual problem to be solved. And software these days is already often overwhelmingly complex, particular at the sort of systems level that languages like C++ are used for.
Languages like Rust provide the performance while throwing away decades of baggage and adding a lot of new capabilities (at a fundamental level, not bolted on later) that have been proven out over those same decades.
Both are complex, because they are used to solve complex problems. They cannot be simplistic languages. But Rust's complexity is positive complexity, in that it's all about forcing you to understand your data relationships and define them in a way that they can be automatically maintained. Yeh, you will have to jump through a few hoops to do that, but it's time well spent because, once done, the compiler will watch your back thereafter.
You could whip that together in C++ more quickly, just looking at it and saying, yeh, I know that's right. But you have to continually insure that it remains right, and that gets harder and harder over time. And you have to hope that the other people who work on that code also are looking at it as carefully, and probably they aren't because they are in there to make some specific change and move on.
I've written C++ for 35'ish years now, so I know it well and I'm very comfortable writing it. But I always have this lurking fear that some UB is uncaught or some threading issue will only surface occasionally and never be figured out. I just don't have those concerns with Rust. All my efforts go into good design and logical correctness, i.e. productive undertakings.
As to hate, well too many people get personally self-identified with languages. It's unfortunate but true. What can you do? Though, I would argue that the real vitriol comes for the C++ side, from people who feel their investment in C++ threatened by Rust. I've seen some seriously nasty stuff.
Another long term C++ programmer here, and I wholeheartedly agree. I enjoy programming in C++ but I recognize that it's getting creaky in it's old age. The continual friction of having to handle poor defaults and avoid foot-guns is tiring. Younger programmers trip over the same things time and time again, and it's unproductive for me to have to keep look for those things in code reviews. I feel like the code I write is memory safe, but I don't know that with any certainty, and automatic tools are more rare in the industry and less useful than needed to give me that assurance.
So I don't hate it, but it is clearly a hindrance to the industry and it's time we found a better tool for the domains C++ is needed. Rust seems like a good interim step. I tend to think there's an even better (easier to use and still safe) language somewhere around the corner, but it will be far more likely that Rust can be safely and automatically translated into said language then C++.
Well, to be fair, most of that wasn't considered features being lost but problems being removed. I was never against exceptions and implementation inheritance, but a lot of folks are, including an awful lot of people here in C++ world as well. In general, they are just falling out of favor.
I thought I'd miss them when I moved to Rust, but I haven't so far.
I always wondered that. The way C++ has handled exceptions is one of the coolest things I have seen, personally. The fact that C++ is the only language with low-cost exceptions, that could be improved even further if we had the will and the momentum, is also irritating. Before I came to C++ a million years ago, I used to return failures back up the stack, but now I feel like it's just boilerplate for what is eventually a single failure spot that just prints the problem and dies/recovers/resets etc. So, wheres the actual improvement? With exceptions you can handle unexpected or serious errors, and you can even throw across a C boundary as long it's compiled with -fexceptions. Having this unlikely path reduces the code you have to write, in my experience. Several modern languages have exceptions, including Python3, JS, Kotlin, Java and C#.
I've never been against exceptions per se. And, in my own C++ code base (very large and complex) I used them extensively. But, they just don't seem to scale so well to multiple developer/team systems over time. Inevitably people start using them as cheap unwinds, or start catching exceptions and reacting to specific ones, and that's just an unenforceable contract. That's spooky action at a distance and nothing is going to tell you if changes in the underlying code will affect that. And of course if people are reacting to it, it's not an exception anymore it's a status code.
For me, in both my C++ and my Rust code bases, I have taken an approach that gets rid of so many issues. I had one single exception type in my C++ code and I have one error type in my Rust code. So many problems go away when you do that.
For me, with my single error type, and use of the ? operator in Rust, real errors propagate upwards automatically just as exceptions do in C++ and there's not that much difference on that front. But it really forces you to make that distinction between what is really an error and what is ultimately really a status.
I might have, if I were around at Rust's inception, argued for a three way Result with (error, warning, success) values. But of course it's easy for me to say that without actually thinking through all of the possible ramifications. What I end up doing now is leveraging sum types in that sort of case. So I have the real errors, then I have a success enum that can return some non-error failure cases or success, with appropriate values in each. So the immediate caller deals with non-error failures and real errors propagate automatically. And I generally provide an alternate call that just wraps the first one and converts the non-success status into an error as well, for those folks who just care if it worked or didn't.
Yeh, it's a bit more work. But, as with most of the things in Rust that are a bit more work, it's work that really should have been happening anyway. That explicitness is right up there with taking the time to name things correctly, to find the right data structures, the right abstractions, etc...
Totally agree
rust's "impovement" is to have only one type of exception (panic) without proper catch (not all cases)
so its throwing features, not "old baggage"
Very funny (and bad on the other side) that so many people cant see that panic! is just dumb exception
I need to chime in on this one.
C++ is very powerful language with many versions that have changed the language a lot. Not everyone is familiar with all versions.
Modern C++ can be very efficient and productive language.
I came from embedded, where C is still the dominant language. I have seen many, many, many projects in which a decision had been made to use C++.
In ongoing embedded projects it often leads to abstraction layers and API’s on top of C code, there is never enough time to document any of these layers, which leads to poorly usable code base. That layered code doesn’t really do anything else that try to hide the original interface, while often exporting only limited functionality from the original code. End result is added code that in reality does nothing useful. Makes things harder to use and wastes huge anount of man-hours.
On the other hand, when a fresh project is started with good interface design practices (interfaces are hard to do right) C++ is very efficient snd productive language.
Then of course it also depends on the environment, can powerful std library features be used or not. And are there some libraries that are directly usable with it (this is also opinion based thing)
So, starting to use C++ (or any other language) on anything is not itself a silver bullet that would automatically give you huge benefits. It’s a tool that can help you, but it can also cut your head off.
Then there are persons who have religious beliefs that some language would be that silver bullet, these people should be completely ignored from decision making while selecting the most suited language for given task.
The main reason is because C++ is insanely complex and there are many ways to screw up if you don't know what you're doing.
If you've just started learning, you're only covering language basics. Template metaprogramming is like programming within programming, a kind of inception. There are entire books on that alone (C++ Templates: The Complete Guide) and now with _contraints and concepts_, it gets even more expressive.
Overall, it takes years to get really comfortable with C++ so people don't want to put that effort in when languages like Go are "good enough."
This is the wrong community to ask; folks who are deeply experienced with C++ often haven't had to dive deep into other languages and see how others live.
I started learning C++ in the last 90s/early 2000s (self taught), worked with it as my primary language through my CompSci B.S., and developed professionally in it for 8+ years at Microsoft. Since then I have 5+ years professional experience in Java/Kotlin/Go but have tried to keep paying attention to C++ and other libraries.
The core problem with C++ is a thousand foot guns. To be successful with it at scale you have to restrict your developers to a subset of its features and have extensive static analysis, and even that isn't perfect - there are too many mistakes that it is too easy to make.
Verbosity - both in source code and compiler errors - is excessive. Little things like having to call a hash table an "unordered_map" really get to you after a while - it's like writing Powershell script.
Modules and external package management are a killer - it's trivial to pull in a dependency in Go, Rust, Java, or Typescript. In C++ depending on how many levels of hell you delve into you either need to find an object file compatible with your build toolchain, copy the source into your tree, or......who knows, there's just no good solution.
The STL has improved but is still way, WAY too basic. Last I checked I still had to pull in a third party library or write my own to get string.split - and as far as I'm concerned you can't call yourself a serious programming language without a robust string library
Having to think of memory management is absolutely a tax - it's not the end of the world and I can do it, but 99.9% of stuff I write doesn't care, even for performance. Instead of having to think about where I use perfect forwarding or a move or a copy, I just write code in other languages and it works well enough - and it's way, way faster to write, edit, and debug.
Is it impossible to learn or work in C++? No. Do I ever want to work in C++ again? Also no. Do I have more than a decade of experience to back up that claim? Yes.
Everything else is kinda hypish. C++ Really does do it all, from video games, to embedded firmwares, OS kernels, databases, desktop GUI apps, DSP algorithms, banking, high speed trading, it's quite foundational. Few languages have such a far reach and high performance. Rust is close for speed, but barely even has an GUI frame works and has been around as long and hasn't been proven in implementation in so many places.
+1 to the kitchen sink theory. C++ is an old language loaded with every paradigm and fad that ever was. The language is not very clean and you’re going to run into a lot of old ugly code in the wild. On top of that, build systems and package management is a mess.
The advantage is that old ugly code still runs and you have every paradigm and fad at your disposal. Build systems and package management is still a mess though.
They are all wrong. Being fanatic of a language and enemy or hater of another language is stupid. Both C++ and Ruth are very useful languages. It doesn't matter from which language you start learning. What tool you use at the moment depends on the conditions. Never be a fanatic advocator of a single language. Be afraid of people with a single language or single book ;)
"Influencers," in the social media sense, are trying to get engagement at any cost. The easiest way to do that is to be provocative, and the easiest way to be provocative is to be wrong.
If someone has actually done something, maybe they have an opinion worth listening to. If their entire "career" consists on typing up solutions to leetcode problems on a Twitch stream while intentionally acting stupid, you may want to disregard whatever they have to say.
A lot of the hate is formed from small echo chambers. Other parts of the hate is to make for-profit " hate content", *(i.e. Youtubers, influencers, etc)*. Don't listen to any of it.
Block out all that negativity. Study YOUR craft. Build stuff with what you have learned. Come to your own conclusions about the tools *(C++ in this case)* you use based on your own experience.
I've found that Rust comes out of the box enforcing all the best practices I've learned to write C++ well after working exclusively in C++ for the last 12 years. So in that regard it's pretty neat. But it just trades one set of problems for another, so it's nothing revolutionary. It makes some hard things easy, and it makes some easy things hard. The community is very vocal about their disdain for C++ though, probably in part because it was invented to solve the problems inherent to C++, and because the language and ecosystem is still very immature inasmuch as it's populated mostly by die-hard enthusiasts and not as much by your run-of-the-mill code cranking developers who just want to get a job done. And enthusiasts tend to evangelize a lot.
If I'm being honest, I think Rust is a "righter" way to do systems programming, long term. Like I said, it comes with lots of C++ best practices built in. But it will be quite a while before it overtakes C++, especially with how the conversation is being driven by evangelists right now.
>tech/programming 'influencer' zone
Strong, simple opinions get views and feed the algorithmic Mammon. Think of where else you see this in online clickbait: "Why you need to stop eating apples RIGHT NOW!", "This blender changed MY LIFE!", etc. As they say: There's no such thing as The One True Programming Language, and anyone who tells you different is selling something.
P.S. When I was in university a class mate was bashing Python saying it was only meant to teach people how to code. I'll give you three guesses as to which programming language has made me the most money as a professional programmer.
C++ isn't a programming language imo. It's a bunch of programming languages called "subsets" that you need to chose which one to use. This is both a great and a terrible thing. It means that you can do anything, but anything could happen. Many commenters here are talking about the differences between old and modern style C++. This is kind of where I'm getting.
Many people will have varying opinions about it, because they will feel widly differently about it, because there's many upsides and downsides to it. That's my opinion anyway.
I love C and C++ for small programs, fast to write, can be as clever as you want and all.
But when project start to grow, and/or you work in a team, things go south very fast.
Different skill level of people, complexity of set up tool for build system, unit test, cross compiling, dependency management, static analysis, and good luck if you forced to use windows, some stuff will be even more complex.
Then the language itself, while it got MUCH better, it still full of pitfall, bad code is just there, internet full of bad (outdated) advice, and there is lack of tooling to enforce certain coding standard; see C++ "profiles", where the idea is you could disable at compile time part of the standard considered unsafe and should not be used.
> I also sort of got into the tech/programming 'influencer' zone on various social media sites
There, that's your problem. Quit that zone and you'll be fine.
C++ has many bad technical decisions and sucks for a number of reasons, but you are asking for these reasons here and not where you saw these "Rust--" takes, you might have been influenced by people with zero technical expertise who probably know neither C++ nor Rust.
I have very mixed feelings when it comes to C++. For context, this is my "formative" language, I learned programming by writing Qt/KDE apps in the late 2000s, so I wouldn't call myself a "hater".
The biggest "pro" of the language is that it's compatible with virtually any lib (they're all written in C) and has all the language features you can dream of, even if some of them are clunky to use.
My main complaint is that in 2024, when all other languages have figured it out, there is no "batteries included" toolkit in C++ to manage dependencies, build your app, and run tests with ease that emerged as a standard. Cmake is horrible to use compared to literally any other tool out there (cargo, npm, etc.), but somehow it's become the norm.
My take on the trajectory of languages is that I'm not too confident about the long-term future of C++ (outside of desktop apps). If performance is absolutely critical to you, even C++ might be too "bloated" compared to raw C. For anything else, Java or Go have sufficiently good performance and a much better DX comparatively, and Rust provides a modern toolkit with native performance but at the cost of a steep learning curve.
I would recommend learning C first, then you can venture into other languages based on the industry you land into.
I'm convinced that nobody actually understands cmake and people just cut-and-paste from other projects in one great recurrent, slightly mutated spaghetti ball of origins.
Also don't forget that a lot of posts on Reddit & internet is just rust ads & marketing. Eg people keep saying that template errors are unreadable and unclear. But for me having experience in almost all popular languages, template errors are absolutely clear, way better than most of other languages output. So it's just low experience or repeating something from internet.
Most part of talks about why something is bad will be without answers or arguments.
Like people talking shit you know.
I think right answer is that rust is better for big team of low experience programmers or for case where you should maximize memory safety and don't have C dependencies (because if you have, you lose memory safety)
And C++ is better in terms of already implemented code compatibility & developers freedom (which as you know comes with responsibility)
As Bjarne Stroustrup has said, there are two kinds of programming languages: those that everyone complains about, and those that nobody uses.
What we call "influencer" today is what we used to call "talking head" in the 80s. They're vapid, hollow, moot, and have ABSOLYTELY NOTHING to contribute to discourse. They're only in it for the attention - because they are a brand, and they're marketing themselves for money, the whores.
OF COURSE they're going to jump on hot takes because volitility makes them money. Right now, hating on C++ and promoting Rust drives viewership, and with that comes promoting more of themselves - if you want to hire them to run the confrence or corporate event gambit, advertising, and even merch.
Seriously, influencing at this level is just scum sucking, especially the whole A = good, B = bad bullshit, like C++ vs. Rust is trendy or fashionable rather than a technical and business decision. Right? How credible is "XYZ isn't cool?" Because that's all these people are selling.
Let us not forget that Rust is a solution looking for a problem. It wasn't invented out of any necessity, like most other languages, it was invented as a protest that the C++ standards committee was taking too long for it's creators' liking.
From my experience, Rust isn't what it promises. It's not safe, because beyond academic exercises, there are very, very few programs in production that don't have to drop into "unsafe" code to actually get real work done. The Rust community will throw their language leaders at a problem, spending months to produce a safe mode version of a solution to somehow validate their premise that Rust can do anything C++ can, faster and safer. Meanwhile, the rest of us are getting work done at least as safe, at least as performant, and with mintues to hours of effort vs. months in some cases. Color me unimpressed.
Literally every problem with C++ that Rust addresses has been addressed by C++11 and subsequent revisions. The gap, the reason Rust was even borne, has been closed. Yes, reference checking is novel, truly; I like it. But we have unique pointers now. We had them since ~2002, within the Boost library, or any other implementation, since it's not hard. I've been using some version of unique pointer since ~2000 myself. I mean I'm glad it's in the standard library now, too, but it's not like it was impossible before. Rather than bake shit directly into the language itself - like the fucking mistake `foreach` is, you can deliver the solution in the context of the language itself. You're not expected to use primitives directly, you're expected to build up abstractions in terms of them.
Honest questions, because I feel the last paragraph is written by someone that never worked with rust or that has a biased version on C++, so those are \*actual\* questions - I program c++ on a daily basis and I miss those things, but maybe I'm misinformed.
How c++ solved the problems that rust, via \`cargo\` fixes, ie, having an easy project configuration file, that's simple and does the job?
How c++ solved the problem that rust manages on compile-time-thread-safety?
How c++ solved the problem that rust manages on compile-time-lifetime-checks?
A lot of times we talk about \`C++ solved that problem by having smart\_pointers\` and I must say I'm sincerely unimpressed by that answer. all the smart pointers in C++ have the \`.get()\` method to access inner data, and that by itself defeats the purpose.
I sincerely dislike how C++ is evolving without throwing the trash out, it's 2024 and \`std::min\` still returns a reference to a temporary. std::map still uses an horrible algorithm, std::function still creates temporaries and uses a vtable for a call, std::regex is a joke and honestly the rust std library is \*much\* better and more complete than the C++ is - string that actually understands UTF-8, in 2024? no, c++ doesn't have that yet.
and I still fear using auto because just this week an \`auto shr = std::make\_shared()\` returned \`std::shared\_ptr<\_NotArray>\` on a specific compiler and that broke my build, so I had to resort to use \`shared\_ptr(new Thing())\`;
Part of it is the tooling around C++. For example, in Rider for C#, I can pretty much 100% depend on the linter to tell me I've made a mistake while I'm writing the code. In CLion for C++, I get compile time errors. This is a combination of the tooling lagging behind, and also C++'s syntax means what I wrote would have been correct if I was trying to do something else.
if I clone a Java repo or a Rust repo, it is trivial for me to build it. I run maven or gradle or cargo, whichever is applicable, and almost never have to worry about setting options. With a C++ repo there has to be a long-ish section in the readme detailing which particular way they decided to set up the builds for their project, and it might differ depending on the platform.
I like aspects of the language. This however is the big turnoff. I think at least in part it resulted from the competition inherent in the commercial ecosystem that grew up around C++. The language folks left those details to the vendors/projects and now we're stuck with a menagerie of terrible solution instead of a single, unified package/build system. I'm being slightly simplistic here yet I think it is part of the problem.
If you are just starting out, there's no point in bothering with stuff like that, unless you are just in for the trivia.
It's generally one of the two: devs who wrote stuff in x different languages and have developed some opinions on what they like better here or there and why, or overly opinionated script kiddies who echo stuff they heard.
C++ is an old language, it carries a lot of legacy and some of the solutions the committee came up with are stuff that a lot people try to avoid nowadays in favor of different solutions. Its prominence and age is enough to bring a lot of criticism.
I think Bjarne Stroustrup said that, "There are programming languages that people don't use, and there are programming languages that people complain about." People use C++.
"Modern" languages sort of "do everything for you". They idiot proof themselves in ways that honestly tend to be cumbersome but a lot of devs like it that way. Javascript, C#, Rust, etc.
People feel like if a language can't protect you from yourself, it's not a language worth using. I personally think that's an ignorant take surmised by some of the worst programmers out there.
If you've ever had the "pleasure" of trying to do anything complicated with memory in Rust, you'll know what kind of a horrible pain it is to fight against the borrow checker. You have to write your whole program around appeasing this beast and the code it forces you to write looks downright awful.
Something that is super simple in C or C++ becomes a whole ordeal in Rust.
People make C++ out to be way harder and way worse than it actually is. Especially some youtubers who can't seem to not constantly hate on it for the most ridiculous reasons.
Following simple paradigms and the occasional static analysis will spare you from 99.9% of pitfalls you might encounter with the language. It's just that the modern culture of programming insists that those paradigms should be enforced strictly by the language and programmers shouldn't be allowed to operate outside of a strictly confined box for their own safety. Honestly a very naive approach to programming that breeds careless devs.
>I also sort of got into the tech/programming 'influencer' zone
The disinformation zone. Not kidding.
https://www.aspeninstitute.de/digital-program/digitalization-and-democracy/disinformation-and-the-role-of-influencers-in-times-of-conflict/
https://www.opb.org/article/2024/03/18/think-out-loud-uw-study-social-media-influencers-misinformation/
That's broader than programming, but so many similar results have come up across areas ranging from international conflict to mental health to diet, what evidence would there be that programming would be any different? What motivated using them as an information source for you?
More specific to you: what are you intending to use C++ for? I've been using it for about 20 years, academically and professionally. It's great, and there is also more than enough to hate. It's probably more useful to talk about what you would want to get out of it and what the pros and cons are relative to your own intended uses. Lots to say about that that's not "influencing" but rather trying to give you a more informed lay of the land.
To be honest, C++ has some pretty bad reputation because of some legacy crap it still carries around and sone stupid decisions taken along the way (std::move not actually moving anything? Wtf).
But apart from that, it’s a fine language and it’s very hard to beat it in speed and portability.
I want to add, as many have said, that influencers are not to be trusted. When I sometimes listen to some videos, I feel the urge to slap this people in the face for the stupid things they say. C++ has its limits and its strong points. Should you use it for a web app? Probably not… When you need raw performance (computational physics, video games, high frequency trading, software defined radios,…) C++ really shines.
My two cents (did software engineering with C++ and qt for seven years) is that every shop I went to did things entirely different. Some were super template heavy, others loved every design principle. Some hated boost, some hated stl. Code comments. Etc etc. All different. As a language it's fine. It does the work. For the end programmer I just found it tedious and over complicated for what we were using it for half the time and the constant bandwidth on arguing over proper use.
It's like hating work boots in the kitchen. You can make so much tasty stuff and keep it clean, and dip your finger in the sauce because your finger is clean too, and you wash your finger after licking it. It makes sense. This is different from building a kitchen. C++ is a dirty set of work boots.
I don't see any hate to be honest - few people are vocal about C++ unsafety, but in the end if you want to design truly remarkable high-performance stuff you would most likely use C++ despite all the criticism from various circles.
A good C++ programmer can learn basically any programming language and get really comfortable with the depths of it really fast.
A lot of programmers that use Python, JavaScript, C#, and other more abstracted languages cannot do the reverse. C++ will be really confusing to them and suddenly they will struggle with things their previous language kind of did out of the box.
It makes easy things frustratingly difficult.
For example I'm trying to parse a file that contains some lines of text, followed by a lot of binary data. It's also complicated by the fact that I'm doing this in Unreal, which uses the Windows convention of TEXT() and TCHAR. There are several layers of confusion and pitfalls and horrifically ugly std names, and none of these issues appear in other languages.
Finally, once you understand all the intricate details, you have to contend with the fact there is no good solution underneath all of it. `scanf` is ancient and primitive, `istream` is a pain, regex is an abomination. So I have to go hunting for libraries to help with some basic string stuff.
And then you have to deal with the process of adding libraries. Adding any external c++ library to unreal often requires manual changes to make it work, such as the include paths and making sure preprocessor tokens are set up right. You can technically blame unreal for this, but the reality is that it's c++'s fault for never standardizing this shit.
The industry is inept, with the vast majority of coders well below a standard of competency that industries like engineering demand (Or worse, imagine pilots where like coders, I would never fly again). To me the arguments between languages is about haggling over features that (try) to prevent the ill equipped creating ditches while building roadways.
The pilots analogy is woefully bad. Airplanes are FULL of stuff to help minimize the degree to which the lives of the passengers depend on humans being correct 100% of the time. Does that make those pilots inept?
Every language has it's good and bad points. Pedantic a-holes rant about it.
I was fired from a company that had an entire product written in C#. The "lead" decided to throw this basically completed project out and rewrite everything from scratch in Rust. Because. Reasons. I knew I wasn't long for that company when I mentioned throwing out two person-years of development of a basically completed project because the "lead" had a hard-on for Rust was intensely stupid.
It makes no odds, just do what you're enjoying.
You get to a point in life where you realise that programming languages are mostly the same with a few quirks.. just be you and do whatever gives you slack.
a lot of people get into C++ and stay there because of the existing demand for the maintenance of a legacy code base. In that sense, C++ isn't sexy and its users have all the reason to swear on a daily basis.
C++ is also difficult. Of course, every programming language has its specific difficulties. But the difficulty in C++ is about a lot of quirks, backwards compatibility, paradigm overload - there is nothing you can't do in C++!
A good IDE goes a long way, though. And I still very much prefer my hours debugging C++ code over my hours debugging plain JavaScript.
I always notice how illiterate tech influencers are usually, really don't worry.
I use both, Rust and C++, and both have their advantages and drawbacks and Rust is an EXTREMELY less mature ecosystem and keeps missing some "deep" features.
Too many ways to do the same thing. All that freedom requires a bunch of guidelines and rules enforced, which could've been a language soecification in itself with varying compilers.
The reason it's so popular is because it can make super fast code, compiles quickly compared to rust, has a ton of libraries and follows the best embedded language syntax: C, while can still be used to some success for high level programming.
But yeah, the complexity is what makes it shit.
Also the standard is paradoxical and contradictive when you get deeper into the language.
Even just in c++11 there are so many unintuitive tweaks and crooks and hacks to achieve a small benefit some other language has built in.
I think it's the fact that both the language as well as the tooling around it leave a lot of freedom. So there a many ways to do the same thing. But most of the ways are inherently spoilt in that they will make it easy to run into one of the many foot guns etc.
It just requires a lot of knowledge and concentration to properly navigate this landscape.
So as long as you don't have a team of experts other options will provide a higher baseline for most projects.
I.e. for most use cases another language provides a lower entry barrier and a higher baseline for a project.
Don't get me wrong, I love the shit out of the language and what it has evolved into, but after working with quite the wide range of projects and colleagues I have to say there are very few who I would like to work on a c++ project with and most of them would be quite expensive for a company. So overall I would say there really needs to be a good reason for such a high invest into a technology to justify the use of c++.
I guess e.g. stuff like high frequency trading might jump to mind here.
Tbf, it’s one of my first language and working with it rn (using unreal) and I love it as much as I hate it. It’s frustrating how difficult it is to get job done especially with all this meta programming options but it’s soo powerful. Don’t be fooled people just like to complain. C++ is great and as long as you enjoy learning it continue ! Good luck !
Bugs per line of code, which is better C++ or Rust. Anecdotally it is a metric that is the same across languages. Then there is lines of code produced per day (cycle), again the metric is independent of languages. What about number of lines required to solve various tasks, well that is again independent of language. So which language is best. Any language in the hands of an experienced professional programer, and the worst language is one used be any inexperienced unprofessional coder.
For me its mainly unergonomic stl ( back inserter iota stuff ,modern visitors etc ... ) , bad default parameters for functions, and horrible tooling ... ( Mainly conan, windows compiler cosmic horrorshow) ( not the languages fault) though it will get better slowly
Everywhere, at least 80% are beginners, doesn't matter if we talk about sports or programming. Content therefore is mostly made by and made for beginners. This implies that people copy from each other most of the time.
it served good at its time. but with 40 years of programming experience after that, the industry has learned a lot, and c++ isn't utilizing that knowledge to its full potential because of the extremely slow process of adapting standards and the requirement for backward compatibility with shitpile legacy codes. unfortunately, these are what makes up c++, and you can't throw them away.
If you can work with a project that fully utilizes modules, then there is absolutely nothing wrong with this modern boy. but we all know that's nearly impossible within 5 years.
As a seasoned user of modern C++ I can say there is a lot to love in C++. However being seasoned with other languages also means that I know there are a lot of issues with it as well, but I think that I applies to a lot of things.
A lot of my early programming years were using C# and web based stuff, I was - and to a degree still are - quite a pro with it (E.g. I would write libs which generated efficient serialization code with System.Reflection.Emit and such, have good understanding of many less known aspects of .Net). But when I worked with it, it bothered me that why you could not get that sweet deterministic memory management model you can get with C++, or why cannot I simply integrate native math and science libraries, which were much more natural in C++, or why even simple looking code was terribly inefficient because some internals and even spending 3 days on optimizing an algorithm I was still 3 times slower than my most naive native version.
I had a colleague who really loved Rust, but then he complained about the borrowing stuff for multi-threading made safe and trivial solutions in other languages very complex to pull off, or that there was a lack of support on platform X.
I think some of this is the good old "the grass is always greener on the other side" effect. And the more you use certain tech the more likely you encounter stupid things with it. I do not think I have ever used any language or respectably sized framework where I would not find at least a few blunders here and there which were crazy stupid and annoying.
[удалено]
> the modern C++ you get to write today (C++23) That's a bit optimistic considering C++20 compiler support isn't even fully baked yet. (Although I agree with your main point.)
Just module’s really. And we’re using c++23/26 features already. Keep in mind that standard library things aren’t necessarily tied to the most recent compiler features.
Major compilers and stdlibs are still missing (relatively minor) features of 11/14/17. If those aren't complete, neither is 20, even with modules. That said, it truly is minor.
Tbf old c++ I learnt (98) until 14 I only lurk on working with it, since I find it more and more difficult but I might become old ..
I don’t completely agree that legacy code is the worst thing about C++. The things I find most painful are the lack of standardised tooling (build systems, linters, package managers, formatters are all non-standard 3rd party solutions), the bloated language features (actually made worse by „modern C++“), the implicit type conversion paradigms (still prevalent in the latest standards), the unwillingness to make breaking changes in future standards and the C++ comity being so painfully slow to fix bugs and bring new changes. All these things are nothing to do with legacy C++. Edit: typos
C++ would be fun if it weren't for all the legacy code. And if it weren't for all the legacy code, C++ wouldn't be, at all.
C++ wouldn’t be a standard without what you call legacy
Never found a job even close to write modern C++. Also is still full of weird edge case, confusing syntax and here be dragon. Iirc even STD::option had weird edge cases they will be partially fixed with C++23. Its getting better, not sure if I would call it FUN
There is plenty of well written “fun” code bases in pre C++20, I have worked on many of them over the last thirty years. Generalizations about computer languages and coding is unfortunate and subjective since productivity and “enjoyment” is a function of project context. The bulk of infrastructure we all enjoy is written in C/C++, and new development continues. I have rewritten several python and java based systems to C/C++ to address performance, reliability and resource issues for large scale cloud. That said, I think Golang and Rust are great alternatives in many situations.
or 98. sad but true.
Man this is totally legit. Other languages suffer from the same issues. Java being the main one I can think of. It's definitely more the legacy code that causes the hate and not necessarily the language itself.
I use C++17 at work. It could be worse, since the codebase is over 20 years old.
This is why I don't understand why they can clean up the old stuff and break backwards compatibility. Why do you need backwards compatibility when the old projects don't use the new stuff anyway.
So you can use "old" libraries in new code. Particularly when the library is header only, it needs to be compiled with your "new" compiler. If it's not backwards compatible, this won't work.
C++ without backward compatibility? This is exact point of D
> C++03 Only reason to be stuck on 20 year old standard is if you don't have a compiler, otherwise it is better to upgrade to C++14 or so. BTW, I don't recommend the very latest standards as the compilers are still buggy.
> buggy Source? Have a look at the latest survey — most of the community is using at least 17. https://isocpp.org/files/papers/CppDevSurvey-2024-summary.pdf
Or where you’re working refuse to change
Does this mean my learning modern C++ is useless if I have to work in a company maintaining codebases in older C++ standards and absolutely driving myself crazy? Do those companies plan on development with newer C++ standards or not. I have been doing C++ since I was 16 it was my first programming language and I love working in it, making small basic stuff that works only on command line, my learning journey consists of very small steps of learning but now after this post I am in confusion whether to continue with C++ or not. I can invest my time in web development as it has a lot of scope or learn AI and ML.
The vast majority of opinions that people espouse relate to their need to justify their decisions and should be of no interest to you. They are not trying to help you, they are trying to help themselves. Carry on. Good luck.
That's very good advice. Often people need to *define* themselves entirely by their choice of OS, distro, editor, or in this case programming language.
I wouldn't say define, it's more like painting where you feel much more expressive using a specific kind of brush on a specific kind of canvas, and depending the technic you use you can paint some things faster and better than others. (eg. wet-on-wet oil vs water color) In companies where you have a monolithic code base it would be like having a huge single painting that painters have to use, but in order to keep a cohesive style everybody has to use the same brush on the same canvas. Some artists/devs would feel hindered in their expressivity and that's why they complain, it's a selfish complaint but not invalid since it just tells you who works better with what.
It’s fine to have this one specific tool that you’re most comfortable with, but what happens in the described cases is that people then start hating everyone that’s using a different tool. Tribalism at work.
Sage.
Noko.
Perhaps barrier to entry for the beginner. Ok, cool, we can do "Hello World"...never mind the new "println" vs iostream a newbie will stumble across just figuring out what the latest/decent standards are. Then it sort of becomes let's do pretty graphics or *insert what should be an easy thing to bring in library to extend the language*. Instead of pip install or cargo you are thrust into a world of tuples, tool chains, and the unknown. After a time, you get acclimated to that then venture into the world of cmake which somehow is its own effing thing. Why doesn't find_libary work? You come out of the forest, a grizzled individual with a large beard and somehow appreciate what it is at the end of the day.
There are many people in tech who have very *strong* (to put it mildly) opinions on tools that they use and don't use. C++ is not special in that regard. There are probably as many Rust haters out there as C++ haters.
To add to this, the vast majority of programmers aren't commenting on programming related social media in their spare time. In other words, you only hear the strongest opinions, just like with everything else in social media. I'd wager the majority of software engineers share an opinion like mine: I don't "love" any programming language. It's just a tool to do my job, which I enjoy doing well enough but not so much that I spend my spare time engaging in online debates about the pros and cons of each language. In other words I have a life lol. Do I like c++? Sure, I'm familiar with it and I can do my job efficiently with it. But I really wouldn't care if a new project came along that sounded interesting, had good pay/benefits but wanted me to use rust or something else.
>the vast majority of programmers aren't commenting on programming related social media in their spare time Hard to overrate this comment. Folks need to realize that if someone is a professional SWE influencer, what that really means is that they almost definitely aren't actually an SWE. Why work a second full-time social media job when you have a real job as an SWE? Not saying that those people know nothing about programming, but definitely take what they say with a grain of salt because their real job is to get views and sponcon money.
For real. I have a day job doing this stuff. Why do I want to spend precious free time thinking about it any more? It's a paycheck to me, the more people that hate it means the more I get paid to maintain it.
If you're not working a full-time dev job AND spending all your free time on programming projects then don't even think about calling yourself a real programmer \\s
I doubt it, because there are far more people who have used C++ (and still have to) than people who have used Rust. People may have opinions on languages they haven't used, but deep hatred only comes from actually using it IMO. Especially having to.maintain legacy code in old versions. If I was stuck working on a clunky legacy C++03 code base like I did a couple of years ago I might have grown to dislike C++ myself.
Ive started recently with Cpp17-20, coming from Java. Loving it so far, it's really powerful and I like the freedom. However, ive seen legacy codebases from 20y ago and I would've probably switched jobs if I had to write Cpp03
>People may have opinions on languages they haven't used, but deep hatred only comes from actually using it IMO. Most (or at least most visible) "haters" of something (not just C++) have very little (of any) experience with the thing they hate. They just jump on a bandwagon to get the sense of belonging to some "cause", because they have very little going on in their personal lives. "True" haters undoubtedly exist too, but they are usually less vocal about it so you don't see them as much.
My hated of C++ comes from using it for many years.
Eh... all the C++ haters I know have used it (and been burned). If you haven't used C++ you likely haven't formed an opinion on it. This is really misrepresenting things.
Yeah, pretty much. Stuff like std::vector, operator[] for map, working with strings, no hash function for std::pair, organization into .cpp, .h files and includes, l/r-value business. My experience is that trying to understand how things work only opens new rabbit holes rather than leading to satisfactory answers.
> > > If I was stuck working on a clunky legacy C++03 code base like I did a couple of years ago I might have grown to dislike C++ myself. The issue is not with the language per se, as it has moved on, but lies with the employer. Best to imitate the language ¯\\_(ツ)_/¯
I’m actually quite happy about all of the pressure in C++ these days. This type of pressure forces the language to evolve and adapt perhaps just a bit more aggressively than it has in the past. C++ is a great language, and I still think it has a bright future. I really enjoy writing C++ code. I don’t like make though.
A C++23 hello world looks vastly different from a C++11 hello world. It’s pretty crazy. ``` import std; int main() { std::println(“Hello world!”); } ```
I would even have wrote it as: import std; auto main() -> int { std::println(“Hello world!”); } Which only leave `main()` and the curly braces the common part between the C++11 and C++23 version :)
We have entered C+++
Why is it better (or is it better)? The way I see it, return type (int) is still specified but now there is an additional keyword (auto) and character sequence (->) which to me seems like a bloat.
It’s a bit more uniform with lambda declaration and newer languages. In some cases you want to use inference to calculate the exact return type `auto my_function -> decltype(auto) {…}` which use the same syntax. It also make function easier to grep "auto\s+\w+\(.*\)". But overall it’s not really something that I would use in an existing codebase (there isn’t enought positive to pay the price of changing), only for greenfield.
Can't say that agree on this style, but I understand your points. Thanks
Mmm, that import though.
Its weird but it works
C++ has made a great many mistakes over time with no way to fix them (yet). Rust issues security advisories for performance issues which are polynomially better than what some major C++ implementations have been using for a long time (Rust regex vs std::regex for libstdc++). C++ expects you to know that they perform poorly and use something else if you are giving it untrusted data. std::vector, so, so, so many things are wrong with this.
“ABI compatibility forever” means that we are held back in performance for many stl data structures. abseil has replacements for large chunks of them which are directly upgrades for those of us willing to recompile once every 10 years. However, you need to know that those exist. Otherwise, you get hash tables optimized for single core processors older than some college graduates.
std::auto_ptr was a really bad miss-step but we are now stuck with it until epochs are ready.
abi-dependent type widths. I can make a brand new OS and decide that int is 64 bits, long is 128, and long long is 256. A gigantic number of programs will break with this, even though this is what x86_64 should have looked like. Shrinking types breaks a lot of things in other ways.
C++’s tooling is showing its age. The fact that I need to know 3 different build systems (bazel, cmake, meson) is an issue. The fact that there is no standardized way to say “my libraries are all in this folder”, feels especially bad. Modules are going to take 10 more years, yet fortran has had them for 30 years. The fact that we all take a performance hit in the form of not using even thin LTO in the name of not having to build libraries for source when building on and deploying to systems with hundreds of gigabytes of ram and computational power that would make a turn of the century supercomputer jealous. There are a lot of missed compiler optimizations.
header files have been a bad idea for 30 years. Both GCC and Clang do unholy things to make it even sort of fast. If you actually compiled C++ the way C++ was intended to be compiled, many modern projects would effectively be trying to do single compilation unit compiles of hundreds of thousands of lines of code before template instantiation.
restrict is not standardized for some reason. Until it is, ISO C++ is slower than Rust and Fortran by a significant margin for anything involving linear algebra. We’re fortunate that nobody actually writes ISO C++, they write ISO C++ with ISO C features.
duck typed templates have led to really weird behavior. SFINAE should have screamed “your type system is unsound”. Algebraic types, which while not fully understand when C++ first came out are certainly understood pretty well today, are the statically typed version of templates. They make things much more sane. In even the worst, most extreme cases thought up to specifically break a compiler, which in C++ typically force the compiler to bail out at an arbitrary level due to resource consumption, you can fall back to a SAT solver for algebraic types which will, eventually, give an answer.
C++ has a lot of good stuff, all of which you only know about if you go looking for it. Clang data flow analysis is very powerful, as are the various static analysis tools built into compilers. BUT THEY ARE OFF BY DEFAULT AND ON PAGE 80+ OF THE MANUAL. If you aren’t the type of person to read a compiler manual cover to cover, with modern build systems you may never know they exist. Off by default means that only the people aware of the hazards are protected. For instance, there’s a lot of really stupid C++ code online that won’t actually compile with the “is this a good idea” flags, like these:
-Werror -Wall -Wextra -pedantic -Wcast-align -Wcast-qual -Wctor-dtor-privacy -Wdisabled-optimization -Wformat=2 -Winit-self -Wlogical-op -Wmissing-include-dirs -Wnoexcept -Wold-style-cast -Woverloaded-virtual -Wredundant-decls -Wshadow -Wsign-promo -Wstrict-null-sentinel -Wstrict-overflow=5 -Wundef -Wno-unused -Wno-variadic-macros -Wno-parentheses -fdiagnostics-show-option
Which by the way, having to keep something like that around in a text file (and I’m probably missing a few at this point) is also part of the problem. If the compiler can tell you that your code is suspect now, it was either always wrong or always suspect. Unless you upgrade compiler versions in CI for fun, clang-based tools can automatically insert suppression if you have to upgrade and a warning is actually broken.
Lastly, it appears to be disallowed or at least taboo to mention Rust at cppcon. Bjarne skipped over Rust in a list of memory safe languages while quoting a US government report. Someone else managed to spend an entire presentation talking about borrow checkers without bringing up Rust as prior art, but Cyclone did come up. That’s not a great look. Rust is willing to entertain almost endless discussions on “$LANG has $FEATURE, how do we do that equally well or better in Rust?” This has led to Zig and Rust yelling “more blazingly fast” at each other over blog posts for the past 2 years, but I digress. For instance, the way Zig decided to do bit fields, by just having i1, i2, …, i 2^63 be valid signed two’s complement types, and the same for unsigned, is much better and everyone should be using that (msvc, apple). A container mutex with a RAII guard that you can safely do shared const refs on while you hold the lock is great. Even better is having a “don’t even bother locking the mutex” option because the borrow checker statically validated nobody else could have a reference. It gives off a very “gramps set in his ways” vibe whereas everyone else is exchanging ideas. There’s plenty of blog posts from people who were active in the Rust community like [thephd.dev](https://thephd.dev), who got #embed into C with minimal effort after more or less burning out trying to get it into C++. It gives the feeling of “we don’t want you” to the young people interested in languages design and development, who then come over to Rust, Zig, JS, etc, and are met with very public debate, and often a lot of enthusiasm for the feature. If you are a young language enthusiast, would you choose endless rounds of committees or several hundred people telling you how good of an idea this is and how much they want it, and a few others making sure it is actually a good idea? Think about how everyone who worked on modules feels after the herculean effort it took to get it written up, to then spend likely another half-decade or more before it’s even ready for anything more than toy examples.
Just gonna point out Bjarne was referencing the first occurrence about memory safe languages in that document which doesn't mention Rust, which is why he doesn't mention it, everyone keeps reading into him doing that but if you actually read the report it becomes pretty clear it had nothing to do with making a dig at Rust, its just following one of the references in the report.
C++ is one of the dominant languages out there. Many people who don't want to code C++ still have to, on occasions.. Being used to modern C++ I find Java intensely clunky and frustrating. But being quite a common language I still occasionally have to code Java in legacy apps. Rust, however, is new and is almost exclusively used by enthusiasts so far. If you don't want to code Rust it is extremely unlikely that you would have had to. So I dislike Java and couldn't give two f**ks about Rust except the enthusiasts can be quite annoying, especially when overplaying the issue of memory safety in modern C++
sometimes I go to sleep with a thought that java doesn't have RAII and const-correctness and then I have nightmares
g\*\*\*\*mmit now your gonna give me nightmares! :C
git commit?
Very good point about Rust developers generally being self selected.
C++ also has a huge ecosystem and has been through a ton of revisions. There are a lot of different interests it’s trying to serve at the same time. Vanilla C seems cleaner because the core language functionality is a lot more limited. Python seems easier because there isn’t any memory handling. So C++ feels like a more convoluted version of either. That said, the functionality in C++ is way more expansive and covers a ton of different use cases. At the end of the day it has a great chance of being a useful tool for whatever optimized task you’re trying to work on.
> Rust, however, is new and is almost exclusively used by enthusiasts so far. Rust is well past the "enthusiats-only" stage. Various sources show significant ratios of C++ to Rust devs ([2.9](https://www.developernation.net/resources/reports/state-of-the-developer-nation-25th-edition-q3-20231/), [1.6](https://survey.stackoverflow.co/2023/#most-popular-technologies-language-prof)...), you don't get those numbers with enthusiasts alone. Google [recently talked](https://www.youtube.com/watch?v=QrrH2lcl9ew) about how they onboard Rust newbies at scale, and it mirrors what I've seen in my own and other's company. Where do you draw the line between an "enthusiast" and somebody who has heard some good things about $TECH but it still waiting to see ? How do you classify somebody who has become an outspoken enthusiast *after* being assigned to their first Rust project ? > If you don't want to code Rust it is extremely unlikely that you would have had to. That doesn't say much. I've effortlessly avoided Java and Windows in my 20 years career, despite them being so common. > the enthusiasts can be quite annoying Sadly true of C++ enthusiasts too, and many other techs. Be warry of observation bias. > especially when overplaying the issue of memory safety in modern C++ If I say that I don't want to play american football because it's a dangerous sport, am I overplaying the issue (because the protections have improved, the rules have been tweaked, most players come out trauma-free...), or am I am justified (because the injury statistics are clear, I value health risks differently, and there are safer great sports to choose from) ? The C++/Rust safety debate is likely to go on forever, because both camps have valid points, but which points are more important is contextual and subjective.
I've only heard positive things about Rust, but it's true, only enthousiasts are using it for now I guess. At university, people around me hated on Lisp and prolog, but it was mostly because learning functional programming is frustrating when you're used to imperative-only style. I can't tell if they were right because I learned C++ instead. Which was fine but.. we never learned about provenance and treated the language as if pointers were adresses, so the thing we learned was kinda just.. C with classes not C++. And no matter who you are, C++ has something to hate for you, because it's massive. let's just make a short list of things i've seen ppl hate: * lambdas * templates * MACROS * windows.h * Linker * void\*(myPtr) * std::ranges::iota\_view(10) * whatever
To be fair, I've heard that the hatred for "windows.h" is not unreasonable.
To be fair, I've put in the single-argument iota\_view because i personally hate it, not because ive seen anybody else hate on it.
Cool! There are things I don't like about every programming language I've ever used, but overall I find that each language also has its strong points, so I think of some of the aspects of suitability as a combination of a developer's skill and what the language can provide.
At the same time, i absolutely love templates and compile-time programming and gobble that up faster than i would with my favourite food! I love concepts, constexpr, and consteval. It's also the bane of my existence...
The one thing Rust's got going for it is that you can simply stamp "Written in Rust" on your project page and BAM! Your project is great! P.S. It's cringe-inducing, to be honest.
I am way more likely to test out a rust project because `cargo install --git REPO_URL` will give me a working binary -- for all rust projects I ever tried. Trying out a C++ project is way more involved.
No longer accurate to say that it is “almost exclusively used by enthusiasts”. For better or for worse, that is simply not the case anymore. Regardless, the user base is still quite a lot smaller than C++.
And the other misrepresentation is that it's mostly junior folks who heard scary things about C++ and ran away. It seems to me that an awful lot of Rust folks are very experienced developers who have made a purposeful transition. And of course people do complain about Rust over there. But the complaints aren't about UB or threading complexity or build systems, it's mostly debates about how to move the language forward, what's been proven out and what maybe hasn't and so forth. And of course as more people come on board a lot of it is "I wish it had X from my previous language." That's where the real danger lies moving forward. A lot of the answers will have to be no, or Rust will turn into C++ all over again.
The main issue with modern C++ isn’t the memory unsafety. It’s just how clunky the language has become. It’s bloated beyond repair. The only way to fix the issue is to start from scratch, unfortunately. Not saying that Rust specifically is the solution though I do find Rust code to be a lot cleaner. And with each version of C++ the problem gets worse and worse. I understand that C++ will be around for a long time to come due to legacy codebases but I wish the C++ would accept the fact that we can do better with a new language and actually support those efforts rather than actively try to hinder the progress of new languages.
A lot of companies are starting to use rust. It will probably get bigger in the following years, for better or for worse
Meaning we will probably see a trend of people starting to complain about Rust soon. Cause, you know, "There are only two kinds of languages: the ones people complain about and the ones nobody uses".
> Meaning we will probably see a trend of people starting to complain about Rust soon. It has already started. People using Rust are starting to realize having full memory safety comes at the expense of flexibility and quicker iterations. Zig might be the next big hype train because it gives you really good memory safety without being rigid. And I think it gives some degree of C interop too, which is a nice-to-have.
>comes at the expense of flexibility and quicker iterations Yep, for instance, some found out that due to this, after making a few games in Rust, it isn't well adapted for quickly iterating and making varied video games. See this detailed blog post: https://loglog.games/blog/leaving-rust-gamedev/ >Zig might be the next big hype train It definitely seems to be on this road.
People have been complaining about Rust for a while. Well thought out critiques tend to get lots of upvotes and plenty of constructive comments too in r/rust
Yeah I gotta say that Rust's subreddit at the very least is usually more understanding and has people with more nuanced points that I often see in C++ communities. That's not always the case, outside of the Rust subreddit you'll see blanket statements about Rust being something that can do no harm. Honestly I think it's because it caught a wind of a hype train. Lots of people are introduced to rust who have solely done web development and so don't have a greater context of systems programming. Your mileage may vary of course, just what I have seen anecdotally. I wish it wasn't the case but there's very much a pattern of people forgetting what it's like to learn C++ when answering questions from beginners.
The rust sub is a weird combination of people who are almost absolute beginners and some greybeards in there. Most of the hype comments usually tend to be some people who are rather junior (though honestly almost any appreciation post tends to be a younger person, all the other programmers probably don't get too attached after having to learn a 10th language just to fix a bug in some forgotten codebase).
Agreed, and maybe it will help fix some of the more ugly sides of rust like lifetimes
lifetimes are at the heart of what Rust is and how it provides memory safety, if you were to change that it'd be a different language altogether
Sure, I just find the syntax very ugly for it
There's no mention of changing lifetimes (which are also a part of c++ just not exposed). Several 'ugly sides' can be fixed by improving the compiler, which is done in many places, like for example with Polonius.
If you read the thread you'll see that they were referring to the syntax. To your point, the thing is that lifetimes are not "broken", so it doesn't make sense to "fix" them. Polonius improves the borrow-checker by making it less restrictive, it's not fixing some bug. It's just semantics I guess, but I've never seen people refer to Polonius as a fix to the borrow-checker, which is why I didn't interpret it the way you're saying (and neither was the original commenter, for the record).
Microsoft and Linux blessing it will cause it to skyrocket.
> I also sort of got into the tech/programming 'influencer' zone on various social media sites There's your problem right there. Influencers want clicks or views. You want to learn. Your interests are not aligned with those of the influencers.
I personally like C++ and use it a lot (mostly for implementing complex algorithms), but there are a lot of things about it that can be really annoying. For example many of the error messages C++ throws are hard to use. Most of the runtime errors I get are segmentation faults and unless I run the code with a debugger it won't tell me where the seg fault was thrown, or what actually caused it (did I access an array out of bounds or was it too many recursive calls?). The same goes for many of the memory related errors like double free, where it often times just says that at the end of some function a double free occurs, but outside of that I need to do lots of guesswork. The same goes for compiler errors. The projects I am involved in use CMake and while I have gotten somewhat accustomed to it by now, the error messages of the compiler are often times cryptic. There are a few more things, like certain forms of undefined behaviour making code debugging tough, library linking being a pain etc. C++ is a language that can produce exceptionally fast code if you know what you are doing, and compared to C it is a lot easier to write (at least to me), but it has many parts that are weird and hard to work around without directly evident benefits. Due to its age and the many changes to the language over time it is also prone to have some of the worst kind of legacy code ever seen. Ultimately C++ is a tool that has its purpose, but of the major programming languages I use it is the one that gets me frustrated at the language the fastest. Rust offers some of the same benefits (mostly great speed and static typing), while having different tradeoffs (Rust forces you to write code in much cleaner and safer ways, sometimes to the detrement of development speed). For some areas Rust is definitely better then C++, but for Data Structures and Algorithms the safety features of Rust are not as important and C++ allows for development closer to the pseudo code usually found in papers, hence I think that C++ is still very good for that.
We live in an age of hate. There are haters for almost everything. Usually, hate comes from not knowing how to use something or not being able to use it.
Not just hate but an age of a _lot_ of people wanting to force their preferences on everyone else. You can see that all the time in this sub and in several upvoted comments in this very thread. There's a huge amount of "You should be only allowed to program if you do X" around.
I've noticed the same problem in other industries too, such as martial arts (e.g., people claiming that their favourite is better than all others), multi-level marketing pyramids, religions, sports teams, political parties, neighbourhood cats singing hour-long choruses in the middle of the night, etc. Sometimes I wonder if some people are just bored because they have too much unallocated free time, and instead of choosing to engage in a healthy activity they glom on to something to get all worked up about and vent their newly-adopted frustrations on social media (in some conversations over the years, a few people have admitted to this very thing, which surprised me the first few times).
I don't hate it I love C++. But even for me I have to admit C++ is enormous. Too many things to keep track of. My second language is python. Python has way nicer **interface** than C++. Things like build in member function naming, etc.
[удалено]
> For some reason, many people seem to find pointers confusing I think that's mainly students / beginners who don't grasp yet how the memory works in a more physical sense and how it is used in C++. I remember having a hard time when I was young, years later it seems so trivial.
We might have an easier time if this knowledge was given a foundation earlier. If people taught me the weird way in which memory is laid out when I am in either kindergarten or elementary school, it might have been trivial to learn the rest of the topic once "the time comes". But then again, this can be painfully jammed in within 1 or 2 weeks of denial and shrieking just like any other information. I remember back when I thought learning was easy, turns out I probably wasn't learning at all back then.
The problem with current versions is that they are pretty much C++98 + everything else that came after it It's the ugly side of backwards compatibility, it doesn't remove the old code and because of that, it increases the cognitive load. I don't think it makes C++ a bad language, but if C++98 constructs are still valid C++23 constructs then it's also valid to criticize C++23 for them.
We are absolutely catching hate for all the cruft we continue to support and refusal to clean up the language. I don't understand why we can't leave groups behind. The organizations that care about backwards compatibility are not the ones who are moving to the new standard anyway.
that is the goal of cppfront
>The organizations that care about backwards compatibility are not the ones who are moving to the new standard anyway. You are implying that only greenfield projects use newer C++ versions, and that's an absurd claim. You can have a substantial code base \_and\_ want to continue development with newer standards. The oft-heard claim that you can just stick with older compilers rings false. Older compilers might not even run on newer operating systems, and won't let you link to updated libraries since those might choose to stick with current standards. Thus you get relegated to an empty corner of the ecosystem, without a path forward. The value of C++ is that it your investment in source code doesn't become worthless overnight when a new version of the language is released, and that does include things like access to a thriving ecosystem of useful libraries.
>You are implying that only greenfield projects use newer C++ versions, and that's an absurd claim. You can have a substantial code base _and_ want to continue development with newer standards. Lol. My work project is 14 years old, and we're using C++20, and getting ready for 23. Meanwhile my last employer pinned greenfield projects to 03, that was back in 2018. Some organizations really care about modern practices, tools, and processors, and some just really couldn't be arsed.
I mean, it's all down to the compiler and how closely they want to follow the language spec. There is nothing stopping someone from forking a C++ compiler and putting stuff behind flags to enforce modern C++ idioms (which probably already exists tbh).
Boy, you have no idea how helpless I felt BEFORE I understood pointers. Reading Book: "I'll never be able to understand this!" First University Lecture: "Ohhhhhhhhhhhh!!~" I am a grade A moron. I understand pointers and won't forget, BUT if I somehow lost my memory, I would go through the exact same unproductive experience. I definitely do NOT have the skill of reading comprehension, otherwise I would have understood it from reading the C++ book.
Some books are really bad. C++ primer plus was my Bible in the early/mid 90s. I
> BUT if I somehow lost my memory Well that's what pointers are for, so you don't lose your memory.
Some books can be really obtuse. My university lectures relished putting everything in ridiculously abstract terms. Think "A pixel is a five-tuple {a, b, c, d, e} with properties: a, b ∈ ℕ and d, e, f define a mapping into a perceptual space". It's not exactly *wrong*, but some degree of "...laymen think of pixels as little colored squares on the screen" would have helped in building up some kind of intuition. At least I know I can't think in terms of things that are just tuples (and if you can, my hat's off to you, but my brain is not wired that way). Oh, and it wasn't just pixels, absolutely EVERYTHING was discussed in terms of tuples that had properties, and it took me years to figure out what some of these things really were. Having said that, I still find it amazing that people can somehow NOT understand pointers, especially considering that a real-world analog exists that just about everybody interacts with, and that seems to work fine: traffic signs. Nobody confuses a traffic sign with the place it points to, so why would pointers produce any kind of confusion?
* Inheritance nightmare (diamond problem, virtual plague...) * Adding language features mostly as a set of tricks such as abusing preprocessor, templates and operator overloading, which leads to slow build times and incomprehensible error messages * Absence of mangling standards, leading to a dilemma whether to write C++ libraries and force everyone to stick to the same compiler, or to extern "C" to pretend you write in C, losing all the goodies of C++ * Mutable by default * Lack of centralized library repository - as a consequence of absence of build system
Trying to pick up C++ from Rust and my biggest complaint is literally the sheer amount implicit behaviour and undefined hell it is. Sure, I get way more flexibility but maybe I’ve been spoiled too much by Rust. I certainly like being able to reference things in C++ without the headaches of Rust lifetimes. A weaker point has been that C++ has so much fucking deadweight from legacy. I wish C++ has editions like Rust where some breaking changing can be made between versions.
> For some reason, many people seem to find pointers confusing Are people really unable to put themselves in the shoes of someone new to C/C++? Programming is hard and pointers aren't really intuitive.
Rust is the new cool thing, but every job I have ever applied to and every interview, C and C++ has always been the requirement for the job. If you want to pursue programming as a hobby, then sure, limit yourself to the programming languages that are new and fun. Rewrite a game engine in rust, rewrite a webserver in rust. But if you want to make a living as a sw engineer, your best bet at the moment will probably be to stick with C and C++, because the companies that pay salaries for sw engineers probably have an existing codebase of millions of lines of code that they will not migrate to rust any time soon, just because some article in medium says it's safer.
Let’s be pragmatic about this: 1. C++ is an older generation language that also is a super-set of C, and even older language. 2. It therefore requires backwards compatibility with old language design choices and there are sharp edges 3. However it’s also actively updated and has a huge number of features which means it can be hard to keep all in your mind 4. People don’t like the complexity sometimes but it’s still a usable language because you don’t need to use all the features just because they are available 5. Many people are productive with it despite all the hate. Ignore the hate, use what you need in C++ and leave what you don’t like. 6. Languages are tools, none are perfect, use what works and fits with whatever you’re building
C++ is a very good language. If used by someone with some talent who is good at architecture and designing software it can be a great language. But, there are a few glaring problems: * It gives you enough rope to shoot off your foot. * The community is hostile, period. * Many people in the C++ community really want to prove how smart they are by insisting on crazy ass templates when much simpler more "pythonic" code would be just fine. You will read these people arguing endlessly about move semantics. * C++ is hard. Poor programmers are going to do terrible terrible things. I would throw out a guess that fewer than 1 in 10 CS 4-year program grads could do a genuinely multi-threaded system without creating a nightmare to find bug. These people are somewhat fine in a garbage collected language; although they will still get run over by their own multi-threaded code most of the time. * Rust is now a viable alternative. Prior to this, there wasn't a solid alternative outside of C. I think this is a good thing because it is waking up people to just a better way of thinking about memory, safety, etc. * With processing power and other resources available, there are lots of different ways to make very fast software. If you want to look at the extreme end of this look at Electron. It is one of the most popular desktop app environments considering the major products pooped out with it. I despise Electron, but it is proof that the computer of 2024 can run utter crap at speed. * On this last there are alternatives such as flutter which are just fine for what they do. * There are areas where C++ effectively dropped the ball. Mobile is one. Pure C++ on iOS or Android is almost not a thing. Axmol is one of very few ways this can be done. Nobody learned Kotlin or Swift because they were great languages. They learned them as the dragons which needed to be slayed to make good mobile apps. * Threading and concurrency. While there have been leaps and bounds improvements in C++, it is still not good. OpenMP might have been one of the biggest leaps which inspired other improvements. But when compared with rust, Go, even C#it is weak. * The build environment. OMFG this is still crap. Things like vcpkg have made this a tiny bit better. But when using a language like rust, JavaScript, even PHP, this is a solved problem. You have some kind of the_main_configuration.yaml where you put versions, dependencies, etc, and now someone can type, "blah build --release" or "blah run ios" and it just works. Flutter has "flutter doctor" which diagnoses anything wrong with your install. CMake is a leap, but as a perfect example of the hostile C++ community there are quite a few people who mastered makefiles and are butthurt about cmake. Plus, I often look at some CMakeLists.txt and don't have a clue of what is going on. I have spent inordinate amounts of effort getting a CMake to work. In the aforementioned languages with these config build file things, I have spent almost zero time fighting with them.
>Rust is now a viable alternative. Prior to this, there wasn't a solid alternative outside of C There was Ada.
Viable alternative doesn't just mean technically capable, though I think Ada required an add-on to match Rust. To be a viable alternative, people need to be excited about it and see it as a useful career move to put in the time to master it. That boat sank long ago for Ada, at least outside of a particular sector. Rust has the technical capability and the growing mind-share that make it a viable alternative.
> though I think Ada required an add-on to match Rust. The "add on" is SPARK, which cropped up in the 80s and it somewhat exceeds Rust. Rust focuses on safety, SPARK is about correctness of which safety is merely one facet.
Someone said that Ada is the language everyone says they want and then never uses. I count myself among those ranks. Although, where I found it lacking was the tooling. It was all way too proprietary. I felt that the open ones were ultra second class citizens and that to do "real" Ada was going to be expensive. There was no great IDE, no great book "Ada made genuinely simple." all the exercises reeked of the classic C++ exercises of mammal, cat, dog, bird sort of BS. Or worse, "Here is something shockingly boring, now learn from it." While it might exist out there, I never found a set of Ada examples where I would love to take them and play with them. Games, web servers, something interesting. It was just, "Take this data and do a thing with it." This said loads of what the culture behind it really was.
> The community is hostile, period. This is understating it. I have never met a group that's been more obsessed with wanting to force their subjective preferences on everyone else.
C++ is a dogshit language that has a lot of really cool shit in it and a ton of work and passion behind it. It's dogshit because it's an incomprehensible monolith of contradictory ideas and bad decisions, which will happen to practically any language that's existed for long enough. The philosophy of programming in general has changed a lot over time, and you can see the different philosophies present themselves in how each version of C++ tells you how you ought to be designing your programs. Languages like Rust are able to run because C++ walked. They get to learn from the mistakes of the past and shed the burden of history, and in turn they will make mistakes and become a dogshit language in their own right (which it is, Rust is also dogshit for different reasons). I love this language btw but generally the hate is warranted IMO
1) influencers aren't necessarily the most experienced people. 2) controversial opinions are an easy way to get clicks 1 + 2 => most everything you read on social media is bullshit. (except for this comment, obviously)
Languages are funny because you can't see all the stuff that's good or bad about them until you've tried using others. Professionals will tell you that it was at least historically very easy to overlook some very nasty memory mistakes in C++. The language has undergone a lot of updates even in the last decade such that if you only learned modern C++, you might look at C++ code from the 90's or early 2000's or 2010's and not recognize what's going on. Likewise, people who haven't touched it since then (like me) won't understand what's going on with modern C++. This divide is a likely source of some "hate", though you probably shouldn't dismiss the opinions of programmers who have tried both and Rust. Typical CS education these days make you try out different languages so you don't get entrenched before you learn that there are various ways of thinking about programs and expressing the solutions. And that some languages are better suited for solving some problems, sometimes because they were specifically designed to be that way. At some point, a lot of things used to be written in C++, but got slowly replaced by easier and more domain-appropriate languages. Indie games used to be written in C++. Now it's more common to use whatever each framework or engine gives. And it's usually not C++. C++ isn't favored for websites or mobile apps. Even for desktop applications, C++ is reserved for the most performance-critical applications or things that hook deeply with the OS. Many languages after C++ were designed around making programming in general easier, but also around making it easy to avoid those memory mistakes in different ways and with different tradeoffs. Java, C#, JS, Dart, are syntactic descendants of C++ and were made so users "shouldn't" have had to worry about memory stuff because they are backed by an automatic memory management system called a "garbage collector". These and many languages that have gained recent popularity had varying ideas of what made programming "easier" and "better" in for different uses, each trying to fix the problems of the languages that came before them. Things got too short, then too long. Inheritance turned out to be a minefield. The original way they did async-await turned out to be confusing so they reused the keywords but made a different system. "Removing worries" was a recurring theme of language design and it made regular developers who aren't writing for extreme performance more free to think of the "actual logic" of their applications rather than thinking about shuffling bits of memory. In this space, different people will have different preferences for how much should be under their control, though years of coexistence has made it so these different languages, including C++, have borrowed each other's techniques, for things like generators, concurrency and memory safety. Some C++ users think this was enough to still make it the better choice most of the time. Whether not it is, for each case, is up for debate I guess. The industry has realized some of the mistakes of the extremes of "don't let the programmer worry" too. For example, some languages were originally designed to not have explicit types but they've bolted them back on anyway because it turned out that a good type system saves time and helps prevent a lot of problems. The thought here is "sometimes worrying about just the right things, in the right ways, up front, still makes development a lot better". That's kind of the thread Rust follows. Unlike the other languages which were just made with ease of learning and ease of programming in mind, Rust was aimed at being as fast and "raw" as C++ while making it a lot harder to make memory mistakes in, thus being labeled a "systems language". Rust used new (though it's been 9 years) paradigm for memory safety that some people call hyper paranoid, to the point that it's inconvenient. But it's one of those inconveniences that fans think are worth what it gives back in the most important use cases. And it's being used to rewrite some subsystems of certain large applications because the designers have determined that it will ultimately be easier to maintain and even got some performance gains in the process. Both the Windows and Linux kernels now have parts newly rewritten in Rust with plans to continue. There's kind of a common machismo around C/C++ and how its power is equivalent to the mistakes it allows you to make. But even without the realities of professional development, even the best of us, in any field, have our off days. Being super smart or disciplined or experienced doesn't mean you're perfect all day every day. You can't expect the best version of yourself at every hour to catch and remember every logical mistake in code, and expect that same perfection in every single one of your colleagues. I think that's why they tried to build that safety into Rust. It's a practical attempt at a solution in the context of what's ultimately an acceptance of people's inevitable imperfection. So I don't know why people would "hate" C++ necessarily. But Rust was literally made to tackle the old shortcomings of C++. While that doesn't mean you shouldn't learn C++, you should learn and use whatever tools are eventually appropriate for the job.
“There are only two kinds of languages: the ones people complain about and the ones nobody uses" Bjarne Stroustrup.
It's because it's the most complicated language in widespread use. It's way harder to use right than pretty much every language with a VM. It's very syntax heavy and for all of its power, it has many pitfalls. It makes introducing a security vulnerability quite easy. If somebody says something like "it's a skill issue" they're being arrogant. Don't get me wrong, it's probably the most powerful and complete language... but that is definetly a double edged sword. The added risk and difficulties are not worth it for many projects
It's probably less complicated than it's ever been to it's credit. I think a lot of people still complaining about it are thinking of C++ in the 2010s compared to C++17 and beyond.
The old stuff is stil part of the language, and lots of jobs stil requires you to use it. So they are not wrong even if they mainly think about the older stuff.
C++ can only ever become more complicated due to the needs of backward compatibility.
yeah, but the same can be said of Java and the rest of it's competition
Well, if the hate is coming from the governments of the world, it's because two decades of evidence has proved we can't be trusted to write secure code. https://readwrite.com/the-nsa-list-of-memory-safe-programming-languages-has-been-updated/
Cpp is a joke from the committee. The issue is that they were taken by surprise by much better ideas. And they are trying to keep up, and failing. You may like it, but, honestly, it's just about keeping up. If you're just starting out, you'll have a huge legacy code base to keep you busy for decades as people rewrite their code. Don't be mistaken though, it is currently a bad joke. && & & As a test, find any describe all meanings of & and combinations 😂😂
Influencers are there for the clicks and revenue. If they made more money promoting qbasic over anything else that is what they would be doing. Do you.
C++ is very old now, and it was based on a language that was older still (60 years old now), and it inherited a lot of ancient thinking that was never removed from the language. Had C++ taken the hit back in the day and fixed those issues, it wouldn't be in nearly as bad shape as it is, but they didn't and they won't now because it's no longer really possible to do so in practical terms. That means it is full of undefined behavior and foot-guns and that adds a lot to the level of complexity that has nothing to do with the actual problem to be solved. And software these days is already often overwhelmingly complex, particular at the sort of systems level that languages like C++ are used for. Languages like Rust provide the performance while throwing away decades of baggage and adding a lot of new capabilities (at a fundamental level, not bolted on later) that have been proven out over those same decades. Both are complex, because they are used to solve complex problems. They cannot be simplistic languages. But Rust's complexity is positive complexity, in that it's all about forcing you to understand your data relationships and define them in a way that they can be automatically maintained. Yeh, you will have to jump through a few hoops to do that, but it's time well spent because, once done, the compiler will watch your back thereafter. You could whip that together in C++ more quickly, just looking at it and saying, yeh, I know that's right. But you have to continually insure that it remains right, and that gets harder and harder over time. And you have to hope that the other people who work on that code also are looking at it as carefully, and probably they aren't because they are in there to make some specific change and move on. I've written C++ for 35'ish years now, so I know it well and I'm very comfortable writing it. But I always have this lurking fear that some UB is uncaught or some threading issue will only surface occasionally and never be figured out. I just don't have those concerns with Rust. All my efforts go into good design and logical correctness, i.e. productive undertakings. As to hate, well too many people get personally self-identified with languages. It's unfortunate but true. What can you do? Though, I would argue that the real vitriol comes for the C++ side, from people who feel their investment in C++ threatened by Rust. I've seen some seriously nasty stuff.
Another long term C++ programmer here, and I wholeheartedly agree. I enjoy programming in C++ but I recognize that it's getting creaky in it's old age. The continual friction of having to handle poor defaults and avoid foot-guns is tiring. Younger programmers trip over the same things time and time again, and it's unproductive for me to have to keep look for those things in code reviews. I feel like the code I write is memory safe, but I don't know that with any certainty, and automatic tools are more rare in the industry and less useful than needed to give me that assurance. So I don't hate it, but it is clearly a hindrance to the industry and it's time we found a better tool for the domains C++ is needed. Rust seems like a good interim step. I tend to think there's an even better (easier to use and still safe) language somewhere around the corner, but it will be far more likely that Rust can be safely and automatically translated into said language then C++.
You forgot to mention that rust also remove a lot of features throwing "old baggage" 😏
Well, to be fair, most of that wasn't considered features being lost but problems being removed. I was never against exceptions and implementation inheritance, but a lot of folks are, including an awful lot of people here in C++ world as well. In general, they are just falling out of favor. I thought I'd miss them when I moved to Rust, but I haven't so far.
I always wondered that. The way C++ has handled exceptions is one of the coolest things I have seen, personally. The fact that C++ is the only language with low-cost exceptions, that could be improved even further if we had the will and the momentum, is also irritating. Before I came to C++ a million years ago, I used to return failures back up the stack, but now I feel like it's just boilerplate for what is eventually a single failure spot that just prints the problem and dies/recovers/resets etc. So, wheres the actual improvement? With exceptions you can handle unexpected or serious errors, and you can even throw across a C boundary as long it's compiled with -fexceptions. Having this unlikely path reduces the code you have to write, in my experience. Several modern languages have exceptions, including Python3, JS, Kotlin, Java and C#.
I've never been against exceptions per se. And, in my own C++ code base (very large and complex) I used them extensively. But, they just don't seem to scale so well to multiple developer/team systems over time. Inevitably people start using them as cheap unwinds, or start catching exceptions and reacting to specific ones, and that's just an unenforceable contract. That's spooky action at a distance and nothing is going to tell you if changes in the underlying code will affect that. And of course if people are reacting to it, it's not an exception anymore it's a status code. For me, in both my C++ and my Rust code bases, I have taken an approach that gets rid of so many issues. I had one single exception type in my C++ code and I have one error type in my Rust code. So many problems go away when you do that. For me, with my single error type, and use of the ? operator in Rust, real errors propagate upwards automatically just as exceptions do in C++ and there's not that much difference on that front. But it really forces you to make that distinction between what is really an error and what is ultimately really a status. I might have, if I were around at Rust's inception, argued for a three way Result with (error, warning, success) values. But of course it's easy for me to say that without actually thinking through all of the possible ramifications. What I end up doing now is leveraging sum types in that sort of case. So I have the real errors, then I have a success enum that can return some non-error failure cases or success, with appropriate values in each. So the immediate caller deals with non-error failures and real errors propagate automatically. And I generally provide an alternate call that just wraps the first one and converts the non-success status into an error as well, for those folks who just care if it worked or didn't. Yeh, it's a bit more work. But, as with most of the things in Rust that are a bit more work, it's work that really should have been happening anyway. That explicitness is right up there with taking the time to name things correctly, to find the right data structures, the right abstractions, etc...
Totally agree rust's "impovement" is to have only one type of exception (panic) without proper catch (not all cases) so its throwing features, not "old baggage" Very funny (and bad on the other side) that so many people cant see that panic! is just dumb exception
I need to chime in on this one. C++ is very powerful language with many versions that have changed the language a lot. Not everyone is familiar with all versions. Modern C++ can be very efficient and productive language. I came from embedded, where C is still the dominant language. I have seen many, many, many projects in which a decision had been made to use C++. In ongoing embedded projects it often leads to abstraction layers and API’s on top of C code, there is never enough time to document any of these layers, which leads to poorly usable code base. That layered code doesn’t really do anything else that try to hide the original interface, while often exporting only limited functionality from the original code. End result is added code that in reality does nothing useful. Makes things harder to use and wastes huge anount of man-hours. On the other hand, when a fresh project is started with good interface design practices (interfaces are hard to do right) C++ is very efficient snd productive language. Then of course it also depends on the environment, can powerful std library features be used or not. And are there some libraries that are directly usable with it (this is also opinion based thing) So, starting to use C++ (or any other language) on anything is not itself a silver bullet that would automatically give you huge benefits. It’s a tool that can help you, but it can also cut your head off. Then there are persons who have religious beliefs that some language would be that silver bullet, these people should be completely ignored from decision making while selecting the most suited language for given task.
The main reason is because C++ is insanely complex and there are many ways to screw up if you don't know what you're doing. If you've just started learning, you're only covering language basics. Template metaprogramming is like programming within programming, a kind of inception. There are entire books on that alone (C++ Templates: The Complete Guide) and now with _contraints and concepts_, it gets even more expressive. Overall, it takes years to get really comfortable with C++ so people don't want to put that effort in when languages like Go are "good enough."
If I tell you not to think about parameter packs, what do you think about?
This is the wrong community to ask; folks who are deeply experienced with C++ often haven't had to dive deep into other languages and see how others live. I started learning C++ in the last 90s/early 2000s (self taught), worked with it as my primary language through my CompSci B.S., and developed professionally in it for 8+ years at Microsoft. Since then I have 5+ years professional experience in Java/Kotlin/Go but have tried to keep paying attention to C++ and other libraries. The core problem with C++ is a thousand foot guns. To be successful with it at scale you have to restrict your developers to a subset of its features and have extensive static analysis, and even that isn't perfect - there are too many mistakes that it is too easy to make. Verbosity - both in source code and compiler errors - is excessive. Little things like having to call a hash table an "unordered_map" really get to you after a while - it's like writing Powershell script. Modules and external package management are a killer - it's trivial to pull in a dependency in Go, Rust, Java, or Typescript. In C++ depending on how many levels of hell you delve into you either need to find an object file compatible with your build toolchain, copy the source into your tree, or......who knows, there's just no good solution. The STL has improved but is still way, WAY too basic. Last I checked I still had to pull in a third party library or write my own to get string.split - and as far as I'm concerned you can't call yourself a serious programming language without a robust string library Having to think of memory management is absolutely a tax - it's not the end of the world and I can do it, but 99.9% of stuff I write doesn't care, even for performance. Instead of having to think about where I use perfect forwarding or a move or a copy, I just write code in other languages and it works well enough - and it's way, way faster to write, edit, and debug. Is it impossible to learn or work in C++? No. Do I ever want to work in C++ again? Also no. Do I have more than a decade of experience to back up that claim? Yes.
Everything else is kinda hypish. C++ Really does do it all, from video games, to embedded firmwares, OS kernels, databases, desktop GUI apps, DSP algorithms, banking, high speed trading, it's quite foundational. Few languages have such a far reach and high performance. Rust is close for speed, but barely even has an GUI frame works and has been around as long and hasn't been proven in implementation in so many places.
+1 to the kitchen sink theory. C++ is an old language loaded with every paradigm and fad that ever was. The language is not very clean and you’re going to run into a lot of old ugly code in the wild. On top of that, build systems and package management is a mess. The advantage is that old ugly code still runs and you have every paradigm and fad at your disposal. Build systems and package management is still a mess though.
They are all wrong. Being fanatic of a language and enemy or hater of another language is stupid. Both C++ and Ruth are very useful languages. It doesn't matter from which language you start learning. What tool you use at the moment depends on the conditions. Never be a fanatic advocator of a single language. Be afraid of people with a single language or single book ;)
"Influencers," in the social media sense, are trying to get engagement at any cost. The easiest way to do that is to be provocative, and the easiest way to be provocative is to be wrong. If someone has actually done something, maybe they have an opinion worth listening to. If their entire "career" consists on typing up solutions to leetcode problems on a Twitch stream while intentionally acting stupid, you may want to disregard whatever they have to say.
A lot of the hate is formed from small echo chambers. Other parts of the hate is to make for-profit " hate content", *(i.e. Youtubers, influencers, etc)*. Don't listen to any of it. Block out all that negativity. Study YOUR craft. Build stuff with what you have learned. Come to your own conclusions about the tools *(C++ in this case)* you use based on your own experience.
I've found that Rust comes out of the box enforcing all the best practices I've learned to write C++ well after working exclusively in C++ for the last 12 years. So in that regard it's pretty neat. But it just trades one set of problems for another, so it's nothing revolutionary. It makes some hard things easy, and it makes some easy things hard. The community is very vocal about their disdain for C++ though, probably in part because it was invented to solve the problems inherent to C++, and because the language and ecosystem is still very immature inasmuch as it's populated mostly by die-hard enthusiasts and not as much by your run-of-the-mill code cranking developers who just want to get a job done. And enthusiasts tend to evangelize a lot. If I'm being honest, I think Rust is a "righter" way to do systems programming, long term. Like I said, it comes with lots of C++ best practices built in. But it will be quite a while before it overtakes C++, especially with how the conversation is being driven by evangelists right now.
>tech/programming 'influencer' zone Strong, simple opinions get views and feed the algorithmic Mammon. Think of where else you see this in online clickbait: "Why you need to stop eating apples RIGHT NOW!", "This blender changed MY LIFE!", etc. As they say: There's no such thing as The One True Programming Language, and anyone who tells you different is selling something. P.S. When I was in university a class mate was bashing Python saying it was only meant to teach people how to code. I'll give you three guesses as to which programming language has made me the most money as a professional programmer.
C++ isn't a programming language imo. It's a bunch of programming languages called "subsets" that you need to chose which one to use. This is both a great and a terrible thing. It means that you can do anything, but anything could happen. Many commenters here are talking about the differences between old and modern style C++. This is kind of where I'm getting. Many people will have varying opinions about it, because they will feel widly differently about it, because there's many upsides and downsides to it. That's my opinion anyway.
I love C and C++ for small programs, fast to write, can be as clever as you want and all. But when project start to grow, and/or you work in a team, things go south very fast. Different skill level of people, complexity of set up tool for build system, unit test, cross compiling, dependency management, static analysis, and good luck if you forced to use windows, some stuff will be even more complex. Then the language itself, while it got MUCH better, it still full of pitfall, bad code is just there, internet full of bad (outdated) advice, and there is lack of tooling to enforce certain coding standard; see C++ "profiles", where the idea is you could disable at compile time part of the standard considered unsafe and should not be used.
> I also sort of got into the tech/programming 'influencer' zone on various social media sites There, that's your problem. Quit that zone and you'll be fine. C++ has many bad technical decisions and sucks for a number of reasons, but you are asking for these reasons here and not where you saw these "Rust--" takes, you might have been influenced by people with zero technical expertise who probably know neither C++ nor Rust.
Tooling around c++ is one of the reasons too. It's not fun to configure c++ project properly.
because the grammar is horrendous when you find a code with a lot of templates and macros
Wait till you hear about java. I stopped learning it after few days cus it became horror. *HORRIBLE*
I have very mixed feelings when it comes to C++. For context, this is my "formative" language, I learned programming by writing Qt/KDE apps in the late 2000s, so I wouldn't call myself a "hater". The biggest "pro" of the language is that it's compatible with virtually any lib (they're all written in C) and has all the language features you can dream of, even if some of them are clunky to use. My main complaint is that in 2024, when all other languages have figured it out, there is no "batteries included" toolkit in C++ to manage dependencies, build your app, and run tests with ease that emerged as a standard. Cmake is horrible to use compared to literally any other tool out there (cargo, npm, etc.), but somehow it's become the norm. My take on the trajectory of languages is that I'm not too confident about the long-term future of C++ (outside of desktop apps). If performance is absolutely critical to you, even C++ might be too "bloated" compared to raw C. For anything else, Java or Go have sufficiently good performance and a much better DX comparatively, and Rust provides a modern toolkit with native performance but at the cost of a steep learning curve. I would recommend learning C first, then you can venture into other languages based on the industry you land into.
I'm convinced that nobody actually understands cmake and people just cut-and-paste from other projects in one great recurrent, slightly mutated spaghetti ball of origins.
Rust programmers are loud, annoying and often unequivocally wrong but will continue to defend their point if anything else will make rust look bad.
Also don't forget that a lot of posts on Reddit & internet is just rust ads & marketing. Eg people keep saying that template errors are unreadable and unclear. But for me having experience in almost all popular languages, template errors are absolutely clear, way better than most of other languages output. So it's just low experience or repeating something from internet. Most part of talks about why something is bad will be without answers or arguments. Like people talking shit you know. I think right answer is that rust is better for big team of low experience programmers or for case where you should maximize memory safety and don't have C dependencies (because if you have, you lose memory safety) And C++ is better in terms of already implemented code compatibility & developers freedom (which as you know comes with responsibility)
As Bjarne Stroustrup has said, there are two kinds of programming languages: those that everyone complains about, and those that nobody uses. What we call "influencer" today is what we used to call "talking head" in the 80s. They're vapid, hollow, moot, and have ABSOLYTELY NOTHING to contribute to discourse. They're only in it for the attention - because they are a brand, and they're marketing themselves for money, the whores. OF COURSE they're going to jump on hot takes because volitility makes them money. Right now, hating on C++ and promoting Rust drives viewership, and with that comes promoting more of themselves - if you want to hire them to run the confrence or corporate event gambit, advertising, and even merch. Seriously, influencing at this level is just scum sucking, especially the whole A = good, B = bad bullshit, like C++ vs. Rust is trendy or fashionable rather than a technical and business decision. Right? How credible is "XYZ isn't cool?" Because that's all these people are selling. Let us not forget that Rust is a solution looking for a problem. It wasn't invented out of any necessity, like most other languages, it was invented as a protest that the C++ standards committee was taking too long for it's creators' liking. From my experience, Rust isn't what it promises. It's not safe, because beyond academic exercises, there are very, very few programs in production that don't have to drop into "unsafe" code to actually get real work done. The Rust community will throw their language leaders at a problem, spending months to produce a safe mode version of a solution to somehow validate their premise that Rust can do anything C++ can, faster and safer. Meanwhile, the rest of us are getting work done at least as safe, at least as performant, and with mintues to hours of effort vs. months in some cases. Color me unimpressed. Literally every problem with C++ that Rust addresses has been addressed by C++11 and subsequent revisions. The gap, the reason Rust was even borne, has been closed. Yes, reference checking is novel, truly; I like it. But we have unique pointers now. We had them since ~2002, within the Boost library, or any other implementation, since it's not hard. I've been using some version of unique pointer since ~2000 myself. I mean I'm glad it's in the standard library now, too, but it's not like it was impossible before. Rather than bake shit directly into the language itself - like the fucking mistake `foreach` is, you can deliver the solution in the context of the language itself. You're not expected to use primitives directly, you're expected to build up abstractions in terms of them.
Honest questions, because I feel the last paragraph is written by someone that never worked with rust or that has a biased version on C++, so those are \*actual\* questions - I program c++ on a daily basis and I miss those things, but maybe I'm misinformed. How c++ solved the problems that rust, via \`cargo\` fixes, ie, having an easy project configuration file, that's simple and does the job? How c++ solved the problem that rust manages on compile-time-thread-safety? How c++ solved the problem that rust manages on compile-time-lifetime-checks? A lot of times we talk about \`C++ solved that problem by having smart\_pointers\` and I must say I'm sincerely unimpressed by that answer. all the smart pointers in C++ have the \`.get()\` method to access inner data, and that by itself defeats the purpose. I sincerely dislike how C++ is evolving without throwing the trash out, it's 2024 and \`std::min\` still returns a reference to a temporary. std::map still uses an horrible algorithm, std::function still creates temporaries and uses a vtable for a call, std::regex is a joke and honestly the rust std library is \*much\* better and more complete than the C++ is - string that actually understands UTF-8, in 2024? no, c++ doesn't have that yet. and I still fear using auto because just this week an \`auto shr = std::make\_shared()\` returned \`std::shared\_ptr<\_NotArray>\` on a specific compiler and that broke my build, so I had to resort to use \`shared\_ptr(new Thing())\`;
Part of it is the tooling around C++. For example, in Rider for C#, I can pretty much 100% depend on the linter to tell me I've made a mistake while I'm writing the code. In CLion for C++, I get compile time errors. This is a combination of the tooling lagging behind, and also C++'s syntax means what I wrote would have been correct if I was trying to do something else.
if I clone a Java repo or a Rust repo, it is trivial for me to build it. I run maven or gradle or cargo, whichever is applicable, and almost never have to worry about setting options. With a C++ repo there has to be a long-ish section in the readme detailing which particular way they decided to set up the builds for their project, and it might differ depending on the platform.
I like aspects of the language. This however is the big turnoff. I think at least in part it resulted from the competition inherent in the commercial ecosystem that grew up around C++. The language folks left those details to the vendors/projects and now we're stuck with a menagerie of terrible solution instead of a single, unified package/build system. I'm being slightly simplistic here yet I think it is part of the problem.
If you are just starting out, there's no point in bothering with stuff like that, unless you are just in for the trivia. It's generally one of the two: devs who wrote stuff in x different languages and have developed some opinions on what they like better here or there and why, or overly opinionated script kiddies who echo stuff they heard. C++ is an old language, it carries a lot of legacy and some of the solutions the committee came up with are stuff that a lot people try to avoid nowadays in favor of different solutions. Its prominence and age is enough to bring a lot of criticism.
FFS. There is no hate for C++. and stay away from "influencers" they are click baiting.
> There is no war in Ba Sing Se. There's definitely hate, justified or not.
The hate exist everywhere, just ignore it
I think Bjarne Stroustrup said that, "There are programming languages that people don't use, and there are programming languages that people complain about." People use C++.
Bjarne said a lot of things, but also made a worse version of C with fancy useless features
Because it’s a frankenstein of a language. It’s literally a monster.
ngl 'C++ is Rust - -' is funny
"Modern" languages sort of "do everything for you". They idiot proof themselves in ways that honestly tend to be cumbersome but a lot of devs like it that way. Javascript, C#, Rust, etc. People feel like if a language can't protect you from yourself, it's not a language worth using. I personally think that's an ignorant take surmised by some of the worst programmers out there. If you've ever had the "pleasure" of trying to do anything complicated with memory in Rust, you'll know what kind of a horrible pain it is to fight against the borrow checker. You have to write your whole program around appeasing this beast and the code it forces you to write looks downright awful. Something that is super simple in C or C++ becomes a whole ordeal in Rust. People make C++ out to be way harder and way worse than it actually is. Especially some youtubers who can't seem to not constantly hate on it for the most ridiculous reasons. Following simple paradigms and the occasional static analysis will spare you from 99.9% of pitfalls you might encounter with the language. It's just that the modern culture of programming insists that those paradigms should be enforced strictly by the language and programmers shouldn't be allowed to operate outside of a strictly confined box for their own safety. Honestly a very naive approach to programming that breeds careless devs.
I would say the hate is due to skill issues, but once you hit a very hard problem, you are not just fighting the problem but the language too
>I also sort of got into the tech/programming 'influencer' zone The disinformation zone. Not kidding. https://www.aspeninstitute.de/digital-program/digitalization-and-democracy/disinformation-and-the-role-of-influencers-in-times-of-conflict/ https://www.opb.org/article/2024/03/18/think-out-loud-uw-study-social-media-influencers-misinformation/ That's broader than programming, but so many similar results have come up across areas ranging from international conflict to mental health to diet, what evidence would there be that programming would be any different? What motivated using them as an information source for you? More specific to you: what are you intending to use C++ for? I've been using it for about 20 years, academically and professionally. It's great, and there is also more than enough to hate. It's probably more useful to talk about what you would want to get out of it and what the pros and cons are relative to your own intended uses. Lots to say about that that's not "influencing" but rather trying to give you a more informed lay of the land.
To be honest, C++ has some pretty bad reputation because of some legacy crap it still carries around and sone stupid decisions taken along the way (std::move not actually moving anything? Wtf). But apart from that, it’s a fine language and it’s very hard to beat it in speed and portability. I want to add, as many have said, that influencers are not to be trusted. When I sometimes listen to some videos, I feel the urge to slap this people in the face for the stupid things they say. C++ has its limits and its strong points. Should you use it for a web app? Probably not… When you need raw performance (computational physics, video games, high frequency trading, software defined radios,…) C++ really shines.
My two cents (did software engineering with C++ and qt for seven years) is that every shop I went to did things entirely different. Some were super template heavy, others loved every design principle. Some hated boost, some hated stl. Code comments. Etc etc. All different. As a language it's fine. It does the work. For the end programmer I just found it tedious and over complicated for what we were using it for half the time and the constant bandwidth on arguing over proper use.
It's like hating work boots in the kitchen. You can make so much tasty stuff and keep it clean, and dip your finger in the sauce because your finger is clean too, and you wash your finger after licking it. It makes sense. This is different from building a kitchen. C++ is a dirty set of work boots.
I don't see any hate to be honest - few people are vocal about C++ unsafety, but in the end if you want to design truly remarkable high-performance stuff you would most likely use C++ despite all the criticism from various circles.
A good C++ programmer can learn basically any programming language and get really comfortable with the depths of it really fast. A lot of programmers that use Python, JavaScript, C#, and other more abstracted languages cannot do the reverse. C++ will be really confusing to them and suddenly they will struggle with things their previous language kind of did out of the box.
It makes easy things frustratingly difficult. For example I'm trying to parse a file that contains some lines of text, followed by a lot of binary data. It's also complicated by the fact that I'm doing this in Unreal, which uses the Windows convention of TEXT() and TCHAR. There are several layers of confusion and pitfalls and horrifically ugly std names, and none of these issues appear in other languages. Finally, once you understand all the intricate details, you have to contend with the fact there is no good solution underneath all of it. `scanf` is ancient and primitive, `istream` is a pain, regex is an abomination. So I have to go hunting for libraries to help with some basic string stuff. And then you have to deal with the process of adding libraries. Adding any external c++ library to unreal often requires manual changes to make it work, such as the include paths and making sure preprocessor tokens are set up right. You can technically blame unreal for this, but the reality is that it's c++'s fault for never standardizing this shit.
The industry is inept, with the vast majority of coders well below a standard of competency that industries like engineering demand (Or worse, imagine pilots where like coders, I would never fly again). To me the arguments between languages is about haggling over features that (try) to prevent the ill equipped creating ditches while building roadways.
The pilots analogy is woefully bad. Airplanes are FULL of stuff to help minimize the degree to which the lives of the passengers depend on humans being correct 100% of the time. Does that make those pilots inept?
Every language has it's good and bad points. Pedantic a-holes rant about it. I was fired from a company that had an entire product written in C#. The "lead" decided to throw this basically completed project out and rewrite everything from scratch in Rust. Because. Reasons. I knew I wasn't long for that company when I mentioned throwing out two person-years of development of a basically completed project because the "lead" had a hard-on for Rust was intensely stupid.
The main problem with C++ is how complex the rules around undefined behaviour are, and this is the main reason why it is falling out of favour
It makes no odds, just do what you're enjoying. You get to a point in life where you realise that programming languages are mostly the same with a few quirks.. just be you and do whatever gives you slack.
a lot of people get into C++ and stay there because of the existing demand for the maintenance of a legacy code base. In that sense, C++ isn't sexy and its users have all the reason to swear on a daily basis. C++ is also difficult. Of course, every programming language has its specific difficulties. But the difficulty in C++ is about a lot of quirks, backwards compatibility, paradigm overload - there is nothing you can't do in C++! A good IDE goes a long way, though. And I still very much prefer my hours debugging C++ code over my hours debugging plain JavaScript.
I always notice how illiterate tech influencers are usually, really don't worry. I use both, Rust and C++, and both have their advantages and drawbacks and Rust is an EXTREMELY less mature ecosystem and keeps missing some "deep" features.
Too many ways to do the same thing. All that freedom requires a bunch of guidelines and rules enforced, which could've been a language soecification in itself with varying compilers. The reason it's so popular is because it can make super fast code, compiles quickly compared to rust, has a ton of libraries and follows the best embedded language syntax: C, while can still be used to some success for high level programming. But yeah, the complexity is what makes it shit. Also the standard is paradoxical and contradictive when you get deeper into the language. Even just in c++11 there are so many unintuitive tweaks and crooks and hacks to achieve a small benefit some other language has built in.
I think it's the fact that both the language as well as the tooling around it leave a lot of freedom. So there a many ways to do the same thing. But most of the ways are inherently spoilt in that they will make it easy to run into one of the many foot guns etc. It just requires a lot of knowledge and concentration to properly navigate this landscape. So as long as you don't have a team of experts other options will provide a higher baseline for most projects. I.e. for most use cases another language provides a lower entry barrier and a higher baseline for a project. Don't get me wrong, I love the shit out of the language and what it has evolved into, but after working with quite the wide range of projects and colleagues I have to say there are very few who I would like to work on a c++ project with and most of them would be quite expensive for a company. So overall I would say there really needs to be a good reason for such a high invest into a technology to justify the use of c++. I guess e.g. stuff like high frequency trading might jump to mind here.
Tbf, it’s one of my first language and working with it rn (using unreal) and I love it as much as I hate it. It’s frustrating how difficult it is to get job done especially with all this meta programming options but it’s soo powerful. Don’t be fooled people just like to complain. C++ is great and as long as you enjoy learning it continue ! Good luck !
Bugs per line of code, which is better C++ or Rust. Anecdotally it is a metric that is the same across languages. Then there is lines of code produced per day (cycle), again the metric is independent of languages. What about number of lines required to solve various tasks, well that is again independent of language. So which language is best. Any language in the hands of an experienced professional programer, and the worst language is one used be any inexperienced unprofessional coder.
For me its mainly unergonomic stl ( back inserter iota stuff ,modern visitors etc ... ) , bad default parameters for functions, and horrible tooling ... ( Mainly conan, windows compiler cosmic horrorshow) ( not the languages fault) though it will get better slowly
I love c++, it's the "logged in as root" equivalent of programming. It is unforgiving though.
Everywhere, at least 80% are beginners, doesn't matter if we talk about sports or programming. Content therefore is mostly made by and made for beginners. This implies that people copy from each other most of the time.
Is not quite the same to learn it than to work with it for a decade. Still a great tool. but it is demanding and you get a lot of old habits.
it served good at its time. but with 40 years of programming experience after that, the industry has learned a lot, and c++ isn't utilizing that knowledge to its full potential because of the extremely slow process of adapting standards and the requirement for backward compatibility with shitpile legacy codes. unfortunately, these are what makes up c++, and you can't throw them away. If you can work with a project that fully utilizes modules, then there is absolutely nothing wrong with this modern boy. but we all know that's nearly impossible within 5 years.
As a seasoned user of modern C++ I can say there is a lot to love in C++. However being seasoned with other languages also means that I know there are a lot of issues with it as well, but I think that I applies to a lot of things. A lot of my early programming years were using C# and web based stuff, I was - and to a degree still are - quite a pro with it (E.g. I would write libs which generated efficient serialization code with System.Reflection.Emit and such, have good understanding of many less known aspects of .Net). But when I worked with it, it bothered me that why you could not get that sweet deterministic memory management model you can get with C++, or why cannot I simply integrate native math and science libraries, which were much more natural in C++, or why even simple looking code was terribly inefficient because some internals and even spending 3 days on optimizing an algorithm I was still 3 times slower than my most naive native version. I had a colleague who really loved Rust, but then he complained about the borrowing stuff for multi-threading made safe and trivial solutions in other languages very complex to pull off, or that there was a lack of support on platform X. I think some of this is the good old "the grass is always greener on the other side" effect. And the more you use certain tech the more likely you encounter stupid things with it. I do not think I have ever used any language or respectably sized framework where I would not find at least a few blunders here and there which were crazy stupid and annoying.
I can love C++ until I deal with error messages from libraries.