19 ms·
Some of these aren't true anymore. I'd say some things improved from that document. But, I'd also say a lot of things got worse that aren't mentioned. We could
by spoiler 5y ago
Some of these aren't true anymore. I'd say some things improved from that document. But, I'd also say a lot of things got worse that aren't mentioned.
We could nitpick at specific sentences/questions, but at the end of the day the spirit/gist of the document remains true, sadly.
I used to quite like C++ in my younger days (highschool, uni), but once you start working with multiple people on a team, or a larger project, the illusion quickly unravels.
The problem in C++ comes when you always have to make a poor value trade.
If you wanted readability, or maintainability you have to sacrifice performance.
Of you want performance, you have to sacrifice everything else.
A great and easy example of this is that the most succinct/readable usage of std::variant has the most morbid performance, and the visitor API is just... Well, if people find that elegant, then beauty really is in the eye of the beholder.
I still write C++ at my job, but I've no illusions about its grandeur.
I have met a few profiles of people in my life/career who defended C++, and they seem to be present on HN too, so please don't take these gross over-generalisations personally; they're imperfect as all generalisations are, and they're just anecdotal anyway:
Some just like feeling like powerful mystic wizards who have mastered the arcane syntax of invoking eldritch features. An additional layer is people who enjoys feeling like heroes when stuff goes wrong in production and they fix it with gdb keyslaps to dump core and transmute memory.
Another profile, that seems way more common, are people stuck with C++. It's kind of a sunk cost fallacy, they already have a career in C++. And there really was nothing better for a long time (ok there was, but not on the job market, and C++ is heavily lobbied at unis). It's also hard to know anything other than C++, because of how taxing the language is; there's little energy left in you to learn something else.
- dig1 5y agoDon't forget you have a complete market of C++ consultants and their companies that will do nothing but explain to you how partial template specialization works. Only for $$$$ per seat ;) Meyers, Alexandrescu, Sutter et al. built their careers by writing books and explaining arcane C++ details.
- spacechild1 5y ago> built their careers by writing books and explaining arcane C++ details. This is only true of Meyers. Alexandrescu and Sutter are accomplished software architects and have been working for large companies.
- lpapez 5y agoFully agree that the language is very taxing on the braincells and I think this is the main reason why Senior C++ Wizards tend to hate Rust. Imagine spending 10 years learning the little details about lifetimes, thread safety, million different UB cases etc. and then seeing a kid fresh out of college fearlessly writing performant code by leveraging the amazing Rust compiler. I bet it must be an infuriating feeling which is why I'm glad that I bailed out on C++ early in my carreer.
- deeringc 5y agoI'm not sure about that. I've spent 18 years programming in C++, for much of that time in a senior professional capacity and am excited to learn Rust for whatever my next project will be. Most of my colleagues and peers feel the same. I think the person you are characterising is quite rare. I like C++ but don't love all of the baggage and am delighted that things are moving forward.
- spoiler 5y ago> I think the person you are characterising is quite rare. You could be right... I hope you are right, but I'm afraid you're not... > I'm not sure about that. I've spent 18 years programming in C++, for much of that time in a senior professional capacity and am excited to learn Rust for whatever my next project will be. Most of my colleagues and peers feel the same. [...] I like C++ but don't love all of the baggage and am delighted that things are moving forward. I don't know what the "split" is regarding mentality, and I've definitely seen a lot of experienced C++ devs in Rust communities, but then there's also a lot of people in "Rust bad"[1] circles (you see them on Reddit and HN). I think it might be an even split (as with most polarised opinions), but I don't think that either sort is rate. [1]: I don't blame these people, btw. If you're in a senior or leadership position and you choose C++ for a new project, because C++ is your strong suit. Then you read online "C++ bad" comments that glorify Rust. It's hard to not take these things personally, when it might be affecting your livelihood. Especially if semi-technical management "drinks the Rust Kool-Aid" (for a lack of better expression) and grills you over your decision. It's not a very disheartening situation to be in, and that frustration can fester into contempt, and so on.
- gefhfffh 5y agoI defended C++ as well, because - even if it's ugly and error prone - I felt like you can express almost any in C++ while every other language felt pretty limited, and from C++11 on and research from Herb Sutter, I thought it would only be a matter of time until C++ would become a actually a modern & safe language. Well, still waiting for that...
- praptak 5y agoThe best C++ developers are those who violently oppose extending the subset of C++ features used in a project. "Template specialization and traits? This belongs in library code. The resulting code is actually more bloated than the copy-pasted version. Nope."
- aaaaaaaaaaab 5y agoThis kind of restraint and level-headedness is the most important trait of a senior developer. The industry sorely needs more of them, not just in C++…
- protomolecule 5y ago"The resulting code is actually more bloated than the copy-pasted version" How is that possible?
- turminal 5y agoMore bloated != more lines of code
- protomolecule 5y agoUnless you mean 'More complicated != more lines of code' I don't understand you.
- ChrisLomont 5y agoTemplates expand, and can generate arbitrary amounts of code. If you, as a developer, don't see what happens, then you might miss it. Templates can also expand on each type they use, or combination of types, generating much more code, when non-template solutions could have avoided it. Of course, templates could avoid it too, but they're much harder to write and see how they expand. That said, templates also allow making code shorter and cleaner. So some people, once bitten by bad templates or bad usage, complain without learning how to use them. Yet another C++ ocean of complexity :)
- praptak 5y ago
- minipci1321 5y ago> It's also hard to know anything other than C++, because of how taxing the language is; there's little energy left in you to learn something else. When I think that in my industry, good mastership of C++ is, what, 30% of what it takes... Throw in real-time design principles and a few different kernels, several CPU architectures, unavoidable Linux and a one or two build systems (Yocto anyone?). And only then comes the real problem domain, communications protocol stacks or image-processing algos, or what have you.
- captainmuon 5y agoSure, but is there any alternative to C++ if you are looking for an object-oriented language that compiles to native code? Many modern languages don't have "proper" object-orientation, with subclasses, polymorphism, liskov substitution principle and so on. Rather, they have compile-time polymorphism, or opinionated other ways of doing it (composition in Go, traits in Rust. Methods in Nim are wierdly attached to the language, and if you want interfaces, the author recommends you use a closure and function pointers...) Other "classic" object-oriented languages are all managed (C#, Java). What I'd want from a language is: - a powerful but ergonomic type system (stuff like Nims "distinct" types are nice). Maybe we can even get simple dependent types. - Class-based object orientation is nice for 1) writing UI code and 2) getting rid of duplicated ifs everywhere. - Generics. Bonus if we can control contra/co/invariance of type arguments. (A Ptr<ToggleButton> is a Ptr<Button>, but a List<ToggleButton> might not be a good List<Button> everywhere, since you can add ToolbarButtons for example.) - Functional programming: Functions and methods as first-class-citizens, built-in understanding of pure functions and const data - Async programming: async/await as first class citizen - Compiles to native code - No frickin UB.
- tored 5y agoProbably a dialect either of Pascal or BASIC.
- pjmlp 5y ago> Other "classic" object-oriented languages are all managed (C#, Java). True, but there have been always ways to compile them to native code, granted not all of them as free beer.
- codeflo 5y agoYou probably know this, but for reference, while Rust doesn’t support implementation inheritance, it has inheritance and runtime polymorphism at the interface level. You put your dynamic components into references and smart pointers of the form Box<dyn Component>, where Component is a so-called “object-safe trait” (which is exactly what you’d call an interface in the OO world). These traits can inherit from each other, and you can upcast a Box<ConcreteType> into a Box<dyn Interface> into a Box<dyn ParentInterface>.
- pjmlp 5y agoI moved into Java/.NET back in 2006, but still keep C++ skills relatively up to date, because for better or worse that is the native language I can use when plugging native libraries into them. No way I am going to use bare bones C unless it is a project requirement from customers or higher level. Still, the improvements on those eco-systems, increasingly make it so that I need turn to it less and less. C++ is one of my favourite languages, it was thanks to it I some major milestones in my career took place, however it is starting to feel like all those critics than one would find talking about PL/I and Algol 68. The "C++" that is heavily lobbied at unis is still what I would call C+, with some exceptions at what are probably elite universities. Just yesterday I was reading an ISO C++ paper that touches this issue, P2000R3 - Direction for ISO C++. We need replacements, because no matter how modern C++ one might want to write in clean C++20, there are millions of lines of gone that go back to the pre-C++98 days, and plenty of mixed quality projects. However, until Apple, Google, NVidia, AMD, Intel, Sony, Nintendo, Microsoft, ARM decide for something else on their SDKs, C++ is going to keep to be one of the tools to reach for on their platforms alongside the other platform languages, it is what it is.
- tialaramex 5y agoThe University where I studied didn't teach C++ to undergraduates, and as I understand it (I work there today, via a circuitous route, but not for the Computer Science department) it still doesn't. A friend teaches Haskell, and I believe their introduction course is in Java (mine was in ML). I can't say that I'd think C++ would be a good choice. Perhaps someone who teaches C++ to undergraduates can offer their opinion about how that works out. P2000 is an interesting document, and so thanks for causing me to read the current revision - but I'm not sure what you meant by "We need replacements". What is it that you want to replace? The C++ language? The C++ programmers?
- secondaryacct 5y agoI learned it myself while at Uni because we only did C and Java. I d say it s important to learn a bit just for the C with classes aspect. Sometimes you want to do a moderately complex C program that Java dev will have to help with, and it helps knowing C++ (as in: I did a 3D engine in it, using no overly fancy language feature, for me that s good enough to get an ability to produce something useful enough). It's a bit sad Rust and Go are so far from C. Might as well just go to Java, a paradise for team work and problem solving.
- turminal 5y ago> If you wanted readability, or maintainability you have to sacrifice performance. If you want performance, you have to sacrifice everything else. This is true in every programming language to some extent. What makes it worse in C++ is that the language markets itself as being performant without any trade offs (zero cost abstractions!) and the reality is very different from that.
- TheMonarchist 5y ago> (zero cost abstractions!) You probably mean zero overhead abstractions. The idea is that you can't outperform it by handwritten equivalent code.
- turminal 5y agoThe name is irrelevant, the point is that it's a blatant lie.
- einpoklum 5y ago> If you wanted readability, or maintainability you have to sacrifice performance. I would say that, at least as of 2011, this is not true. However - I would posit a 3-parameter tradeoff: 1. Better Readability-and-maintainability 2. Better Performance 3. Less coding effort If you want (1.)+(2.) you won't get (3.), i.e. you'll have to work hard. You may be able to write performant code relatively quickly, but it will tend to be more difficult to read and maintain; and you can write readable, maintainable code relatively quickly, but it may not squeeze out what it can in terms of performance.
- spoiler 5y agoI admit that I did over-generalise with those two statements. There's different tradeoffs one needs to do in any language regarding performance/maintenance/effort. But for C++ there is little effort to bridge those gaps, or at least it feels that way. Maybe that's unfair of me, because C++ is very keen on backwards compatibility, though; I disagree with how religious they are about that goal, too. Rust on the other hand strives to make idiomatic and easy-to-maintain/write/read code perform well. There are obviously high-level decision that play a role in performance, but I'm talking more about "vocabulary features" of the language/ecosystem, not the highlevel decision of "Do I use a List, a Map, or a Vector for this?" Sure, there's ugly/unsafe and hard-to-understand parts in Rust libraries (and stdlib) too, but those warts don't leak into the "consumer" code (at least not as much). Also there's consistent effort to add DX polish to tooling, that's not such a "cultural thing" in the C++ ecosystem
- tialaramex 5y agoThere's some small effort to land quality-of-life improvements to the C++ standard library but it feels like too-little too-late. As an example, for years C++ didn't have std::string::contains() because you could write find(x) != npos -- and so the argument is why carry around this unnecessary function? Well, because that's what programmers often actually wanted. C++ 23 will finally get std::string::contains()
- einpoklum 5y ago
- flykespice 5y ago