35 ms·

The two factions of C++

• KerrAvon 2y ago
  I feel the need to point out that `const` is a viral annotation in C++
• glitchc 2y ago
  So the gist of the article is this: The C++ committee should take charge of tooling and implement standardized tooling that matches the standards. Okay, but that won't stop the existence of other tooling, including old tooling, and it won't fix the problem of legacy code. So what's the point? Why bother? Plus unsafe memory calls are mainly found in libraries and applications, not the core language. How will standardized tooling fix that or any of the existing problems for that matter?
• munificent 2y ago
  I really really like this article. I think the two camps the author describes very much reflect my experience over the past couple of decades at a dotcom startup, then a game developer, and now at Google However, I think the author is a little off on the root cause. They emphasize tooling: the ability to build reliably and cleanly from source. That's a piece of it, but a relatively small piece. I think the real distinguishing factor between the two camps is automated testing. The author mentions testing a couple of times, but I want to emphasize how critical that is. If you don't have a comprehensive set of test suites that you are willing to rely on when making code changes, then your source code is a black box. It doesn't matter if you have the world's greatest automated refactoring tools that output the most beautiful looking code changes. If you don't have automated tests to validate that the change doesn't break an app and cost the company money, you won't be able to land it. Working on a "legacy C++ app" (like, for example, Madden NFL back when I was at EA) was like working on a giant black box. You could fairly confidently add new features and new code onto the side. But if you wanted to touch existing code, you needed a very compelling reason to do so in order to outweigh the risk of breaking something unexpectedly. Without automated tests, there was simply no reliable way to determine if a change caused a regression. And, because C++ is C++, even entirely harmless seeming code changes can cause regressions. Once you've got things like reinterpret_cast<>, damn near any change can break damn near anything else. So people working in these codebases behave sort of like surgeons with a "do no harm" philosophy. They touch as little as possible, as non-invasively as possible. Otherwise, the risk of harming the patient is too high. It's a miserable way to program long-term. But it's really hard to get out of that mess once you're in it. It takes a monumental amount of political capital from engineering leadership to build a strong testing culture, re-architect a codebase to be testable, and write all the tests. A lot of C++ committee changes aimed at legacy C++ developers are about "how can we help these people that are already in a mess survive?" That's a very different problem than asking, "Given a healthy, tested codebase, how can we make developers working in it go faster?"
  • badsectoracula 2y ago
    > A lot of C++ committee changes aimed at legacy C++ developers are about "how can we help these people that are already in a mess survive?" That's a very different problem than asking, "Given a healthy, tested codebase, how can we make developers working in it go faster?" Having also worked at a few gamedev studios, IME there isn't a real distinction between the two since it is always a matter of time for the former to become the latter. Sometimes it doesn't even take that long, all it takes is a single innocuous vertical slice with a pointlessly immovable deadline to inject enough harm in a codebase so you spend the next year fighting bugs that shouldn't have existed in the first place while also having to do everything else at the same time (and all planned timeframes made with only the "everything else" in mind, of course). IMO even if it doesn't sound good, it is much more practical to learn how to deal with the mud than assume pigs do not exist :-P
    • munificent 2y ago
      > Having also worked at a few gamedev studios, IME there isn't a real distinction between the two since it is always a matter of time for the former to become the latter. That was very much my experience at EA, but has definitely not been my experience at Google. While everyone struggles with tech debt, at Google I've worked in many codebases that have been continuously well-maintained with good test coverage for over a decade. Really, once you build a culture that says, "People not on your team may edit your code without asking and will rely on your tests to make sure they don't break things,", teams get highly incentivized to write tests.
  • jcalabro 2y ago
    Agreed. As much as I want it to be simpler to build C++ programs from source, it's pretty much always _possible_ in my experience, it can just a PITA frequently. I think that tests are a sure-fire way to improve the quality of your code, but I'd throw another piece in to the ring: sanitizers [0]. Projects that have good tests and run them regularly with TSan/ASan/UBSan in my experience are much better to work on because it means that it's much less likely there's deep seeded issues that are lurking. It gives you increased confidence that you're not introducing hard-to-detect issues as you go. These tools aren't just exclusive to C++. I've said the same thing about C, Go, Zig, Odin, etc. Projects that use them (and have good automated tests) tend to be in good shape, and projects that don't tend to take a long time to make any progress on. [0] https://github.com/google/sanitizers https://github.com/google/sanitizers
• Mond_ 2y ago
  Woah, my post made it to the front page and I'm late. Hi! In hindsight I would've probably written a few things differently, but I really didn't want to fall into a trap of getting stuck editing.
• titzer 2y ago
  Replace C++ with asbestos (no, I'm serious, not just stark), and we're basically having exactly the same conversation that's gone on over decades in the meatspace world, with analogous players, sunk cost/investment calculus, and migration consternation. The only part of the conversation that is missing is the liability conversation and damages. And I do take asbestos as a serious example. Asbestos is still manufactured and used! Believe or not there are "safe" uses of asbestos and there are protocols around using them. Nevermind the fact that there is a lot of FUD and dishonesty about where exactly the line cuts on what is safe versus not safe...for example we are finding out how brake dust affects the wider environment as we crawl out from under the tent of utter misinformation of a highly motivated entrenched industry. I feel like this is not a new human phenomenon. We made particularly poor choices in what tech we became dependent on, and lo and behold, the entrenched interests keep telling us it's not that bad and we should keep doing it because...reasons. It will eventually play out the way it must; C++ might seem a lot more innocuous than asbestos, and in some ways that's true, but it resists all effort to reform it and will probably end up needing to just be phased out.
  • einpoklum 2y ago
    Is asbestos superior to other established solutions in terms of "performance", and only lacking on safety?
    • summerlight 2y ago
      Asbestos was once considered one of the best material for the industry with many desirable properties like high durability, insulation, flexibility, cheap cost etc etc. I don't think human has found a drop-in replacement for asbestos yet.
• nuancebydefault 2y ago
  When I comment on HN topics that are related to C++, there's a very high chance that I get downvoted. Anyways I can't help it, I will comment here... I feel it would be best for the C++ language that its development would stop. There's no way to fix its current problems. The fact that it stayed compatible with previous iterations over so many years is an accomplishment, almost a miracle, it should be cherished. Deviating from that direction doesn't make sense. Keeping that does not make sense either.
• pphysch 2y ago
  The "standardization" of C++, SQL, et al. are some of the most catastrophic examples of premature abstraction in software development. Programming languages benefit far more from a robust implementation, tooling, and good technical documentation (which may read like a standard) than from a prescriptive standard. The latter generates enormous waste, for what?
• dillon 2y ago
  My naive opinion is a commitment to not break the ABI is a good thing not just for everyone else but for C++ as well. Languages like C#, Swift and Python (maybe even Rust?) have tools to integrate with C++ fairly deeply and cleanly. If C++ commits to being stable enough then there won’t be a reason to rewrite some amount of C++ into something else. It’s not a surprise that big tech is trying to move away from C++ and that’s not necessarily bad and remaining stable means the transition isn’t rushed. In the meantime people who enjoy and excel at writing C++ still can. Just seems like an overall positive thing to commit to.
  • nickelpro 2y ago
    This isn't about language ABI, which is the realm of the various implementations which have their own stability guarantees. ABI stability in the context of the standards committee is about library ABI, specifically the standard library. When the committee updated the wording about C++'s std::string in C++11, it meant implementers needed to change the layout of a std::string, making this "new" std::string incompatible with the "old" std::string. Any libraries passing std::string across API boundaries needed to be recompiled with the "new" std::string. This has no effect on FFIs for interop with other languages, which are not passing STL types across language boundaries to begin with (a std::string has no meaning in Python). ABI stability for the standard library is motivated by large, old, coroporate codebases which had poor API practices, passed STL types across ABI boundaries, and subsequently lost access to the source code of those libraries and applications or otherwise cannot recompile them for some reason. Many people question the wisdom of catering to such users.
    • dead_gunslinger 2y ago
      [dead]
    • account42 2y ago
      > ABI stability for the standard library is motivated by large, old, coroporate codebases which had poor API practices, passed STL types across ABI boundaries, and subsequently lost access to the source code of those libraries and applications or otherwise cannot recompile them for some reason. Many people question the wisdom of catering to such users. It's also motivated by Linux distributions and other complex systems where rebuilding and installing the world in one go is not possible/feasible.
• zamalek 2y ago
  > Relatively modern, capable tech corporations that understand that their code is an asset. I strongly disagree with this. The more code you have, the more resources you have to spend maintaining it. There is a very relevant example close by in the post: the bit about Google having a clang-based tool that can refqactor the entire codebase. Great! Problem is, an engineer had to spend their time writing that, and you had to pay that engineer money - all because you have an unmanageable amount of code. The real tech asset is processes: the things you have figured out in order to manage such an ungodly amount of code. Your most senior engineers, specifically what's in their heads, are an asset too.
• uluyol 2y ago
  I think the discussions in these threads show how accurate the framing of this article is. You have some people celebrating Google and friends (slowly) leaving the C++ ecosystem and those that continue to emphasize the flaws that have driven companies away from it in recent history (safety being #1) on the list.
• xdmr 2y ago
  A plague o' both both your houses!
• up2isomorphism 2y ago
  It does not require particular careful inspection to see that with all these zillions features comes into C++ 20, C++ still does not a have a straightforward string split function. And I still feel printf is more reliable and easier to use than all these “modern” fmt. There must be some extremely ideological reason behind these horrible “modern” C++ standards. There are some good trend happening during C++ 11, but now it is completely out of control now.
• vlovich123 2y ago
  I’m not sure I understand the whole ABI argument. Isn’t the raison d’être for namespace versions precisely to evolve the language? Why can’t the existing implementations be copied into a std::v2 but with a changed ABI. Existing ABI issues are non-issues because the old code remains while new code will by default compile against v2 picking up all the goodies and can downgrade the types they actually use across ABI in the places they need by changing the namespace version used for a given compilation unit via compile-time flags (or something along these lines)? Were namespace versions determined to not solve this problem? That would be the most ironic thing after all if the change management system introduced in c++11 to avoid std::string is either unused, untrusted, or unworkable for the purpose it was intended.
  • account42 2y ago
    The problem is libraries using the stdlib types. if your library has a public function that takes a string argument or returns a string or a struct containing a string then that implicitly is an ABI dependency on either std::v1 or std::v2. The library would have to actively add versions for both ABIs. And if the stdlib type is used in a struct/class it can't even differentiate between those types in the ABI.
    • vlovich123 2y ago
      > The library would have to actively add versions for both ABIs It would be up to the library to decide what to do. It could decide to only expose v1 or just v2. > And if the stdlib type is used in a struct/class it can't even differentiate between those types in the ABI. This could be solvable through annotations in the header (explicitly written or implicit through the use of flags) that indicate the version of the types used the std types are referenced implicitly (you could even have warnings and errors to that effect if you encounter it). It seems like a solvable problem to me.
• Mike4Online 2y ago
  C++ is not just C++ but also the C preprocessor, the STL, the linker, the C libraries and SDKs you can't help but depend on, the build system, the build scripts, the package manager, the IDEs and IDE add-ons, the various quirks on various platforms, etc. That's on top of knowing the code base of your application. Being really good at C++ almost demands that you surrender entire lobes of your brain to mastering the language. It is too demanding and too dehumanizing. Developers need a language and a complete tool chain that is designed as a cohesive whole, with as little implicit behavior, special cases and clever tricks as possible. Simple and straight-forward. Performance tweaks, memory optimizations and anything else that is not straightforward should be done exclusively by the compiler. I.E. we should be leveraging computers to do what they do best, freeing our attention so we can focus on the next nifty feature we're adding. Zig is trying to do much of this, and it is a huge undertaking. I think an even bigger undertaking than what Zig is attempting is needed. The new "language" would also include a sophisticated IDE/compiler/static-analyzer/AI-advisor/Unit-Test-Generator that could detect and block the vast majority of memory safety errors, data races and other difficult bugs, and reveal such issues as the code is being written. The tool chain would be sophisticated enough to handle the cognitive load rather than force the developer to bear that burden.
  • cemdervis 2y ago
    The "new" language you're describing sounds like Swift.
• 29athrowaway 2y ago
  C++ is dead by entropy. So complex nobody can truly learn it anymore.
• ramshanker 2y ago
  I am working on a new C++ project in 2024 for my part time project. And this article provided me enough information to battle future "Why not use XYZ instead" discussion. ;) My Rational for Using C++ in 2024: (A) Extreme computational performance desired. (B) I learned C++ 20 years back. (C) C++ has good enough Cross-Platform (OS) compatibility.
• alkonaut 2y ago
  What many newer programming platforms (I deliberately don't say "language") got right, is that you can't design a language in a vacuum. If you design a language and leave the implementation open you'll iterate too slowly and eventually you'll grind to a halt or diverge in implementations. A good programming platform has to consist of tooling which includes package managers, compilers, linters, etc. Ideally, in this orbit you would also have "Language Servers" or similar. At the very least, the compiler and language should be written with this in mind, e.g. written for the ground up to support incremental compilation and so on. Go, C#, and Rust all have tooling-first and more importantly first-party tooling. The people who design the language MUST be able to iterate quickly with the people who make the compiler, who in turn should be able to walk down the hall and talk to the people who make the package manager, the package manager repository, and so on.
• softwaredoug 2y ago
  Related - Is C doing anything about memory safety so it can be called memory safe?
  • steveklabnik 2y ago
    They’re doing some things but there’s no proposals to do anything in the large to move it towards memory safety by default.
  • Slyfox33 2y ago
    No, it would be impossible to make C memory safe without just making a new language.
• icameron 2y ago
  > The C++ committee seems pretty committed (committeed, if you will) I'll will not, thanks.
• Assassink786 2y ago
  https://security.googleblog.com/2024/11/retrofitting-spatial-safety-to-hundreds.html https://security.googleblog.com/2024/11/retrofitting-spatial...
• deleted 2y ago
  [deleted]
• minetest2048 2y ago
  Any mirrors/archives? DNS not resolving for me EDIT: found one on wayback: https://web.archive.org/web/20241124225457/https://herecomesthemoon.net/2024/11/two-factions-of-cpp/ https://web.archive.org/web/20241124225457/https://herecomes...
  • cyclopeanutopia 2y ago
    Weird, it works for me.
• bluGill 2y ago
  Languages should not have a package management system. They all have a all the world is my language blindspot and fail hard when you have anything else. Sometimes you can build plugins in a different language but they still assume the one true language is all you want. package management belongs to the os - or at least something else. don't get me wrong, package management is a real problem and needs to be solved. I'm arguing against a language package manager we need a language agnostic package manager.
  • poulpy123 2y ago
    ideally yes. In practice if they wnat to provide a reasonnably good experience they have to do it
  • kccqzy 2y ago
    Agreed. At least, languages should not require its own package management system to be used. There should be a way to invoke the compiler or interpreter without involving that language's own package management system, so that something else (like Bazel) can build on top. Fortunately, most common languages are all like that. You can invoke rustc without cargo. You can use python without pip. You can use javac without maven.
  • rileymat2 2y ago
    I think the term "package management system" is a bit over broad a term to talk about. If we are talking about global shared dependencies, sure it may belong in the OS. If we are talking about directly shared code, it may as well belong in the language layer. If we are talking about combining independent opaque libraries, then it might belong in a different "pseudo os" level like NPM.
  • the__alchemist 2y ago
    Interesting point, and I'm included to agree with your main point. I don't think the OS level is preferable, however: Point 1: I do not want my program to only run on only one OS, or to require custom code to make it multi-platform. Point 2: What if there's no OS?
• adambatkin 2y ago
  Something that Rust got _really_ right: Editions. And not just that they exist, but that they are specified per module, and you can mix and match modules with different Editions within a bigger project. This lets a language make backwards incompatible changes, and projects can adopt the new features piecemeal. If such a thing came to C++, there would obviously be limitations around module boundaries, when different modules used a different Edition. But perhaps this could be a way forward that could allow both camps to have their cake and eat it too. Imagine a world where the main difference between Python 2 and 3 was the frontend syntax parser, and each module could specifically which syntax ("Edition") it used...
  • steveklabnik 2y ago
    There was a similar proposal for C++, using rust’s original names: epochs. It stalled out.
    • ykonstant 2y ago
      They should call them 'eras'. Then they can explain that epochs did not lead to a new era in the language, but eras will mark the next epoch of C++.
  • CrendKing 2y ago
    But Edition can exist only because Rust intrinsically has the concept of package, which naturally defines the boundary. C++ has nothing. How do you denote a.cpp be of cpp_2017 edition which b.cpp be cpp_2026? Some per-file comment line at top of each file? C++ is a mess in that it has too much historic baggage while trying to adapt to a fiercely changing landscape. Like the article says, it has to make drastic changes to keep up, but such changes will probably kill 80% of its target audiences. I think putting C++ in maintenance mode and keep it as a "legacy" language is the way to go. It is time to either switch to Rust, or pick one of its successor languages and put effort into it.
    • hypeatei 2y ago
      > I think putting C++ in maintenance mode and keep it as a "legacy" language is the way to go I agree but also understand this is absolutely wishful thinking. There is so much inertia and natural resistance to change that C++ will be around for the next century barring nuclear armageddon.
• danpalmer 2y ago
  Python similarly has 2-3 factions in my experience: teams doing engineering in Python and using all the modern tooling, linting, packaging, types, testing, etc; teams doing data science and using modern but different tooling (i.e. Anaconda); and teams that don't get onboard in any of the language health initiatives and are on unsupported language versions with no packaging, tooling, linting, etc. Javascript/Node/Typescript has even more identifiable factions. I think developing factions around these things is unfortunately normal as languages grow up and get used in different ways. Rust has arguably tried to stay away from this, but the flip side is a higher learning curve because it just doesn't let certain factions exist. Go is probably the best attempt to prevent factions and gain wide adoption, but even then the generics crowd forced the language to adopt them.
  • bogeholm 2y ago
    The first two factions you describe in Python (types, testing etc. vs. data science and Anaconda) can work together just fine. Source: I am in both factions, as are my colleagues :)
  • dehrmann 2y ago
    When you put it this way, personas might be a better term than factions.
    • danpalmer 2y ago
      Yeah I think that's a much friendlier term. I do think language ecosystems have a hard time, because on the one hand they should be aiming to be as useful as possible, which means doing more, on the other hand they have to acknowledge that any given user will likely not use all the language and that the rest of it may hinder them, which means doing less. C++ does a lot, but has a big disengaged crowd, for many reasons, and that crowd will suffer from the push forward. Python and Node are similar.
• AlotOfReading 2y ago
  Profiles aren't a mess because they're intended for legacy codebases instead of big tech monorepos. They're a mess because they're not a serious effort. There's no actual vision of what problems they're trying to solve or what the use cases are, or even what kind of guarantee profiles are going to make.
• bagxrvxpepzn 2y ago
  To the people who work on C++ standards: I approve of the current C++ trajectory and please ignore all of the online noise about "the future of C++." To anyone that disagrees severely with the C++ trajectory as stated, please just consider another language, e.g. Rust. I don't want static lifetime checking in C++ and if you want static lifetime checking, please use Rust. I am not a government contractor, if you are a government contractor who must meet bureaucratic risk-averse government requirements, please use Rust. I have an existing development process that works for me and my customers, I have no significant demand for lifetime checking. If your development process is shiny and new and necessitates lifetime checking, then please use Rust. To Rust advocates, you can have the US government and big tech. You can even have Linux. Just leave my existing C++ process alone. It works and the trade offs we have chosen efficiently accomplish our goals.
  • lubesGordi 2y ago
    I don't know enough about what it would take to implement static lifetime checking. Is that fundamentally impossible to do in a backwards compatible way?
    • steveklabnik 2y ago
      It depends on what you mean by "backwards compatible," and what you mean by "static lifetime checking" :) The profiles proposal suggests adding static lifetime checking, "without viral annotations." I use quotations because I don't really agree with this framing, but whatever. The paper is here if you'd like to read it yourself: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3081r0.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p30... The core idea here is that you add annotations to opt in or out of certain checks. And opting in may be a compiler flag, requiring no changes to source code. So that would be "backwards compatibility" in that sense. Of course, code may fail these checks, so you'll have to add annotations to opt out, or re-write the code. We will see in practice how much change is required once implementations exist and are tried out. But the other part is, these profiles do not attempt to cover all valid cases. And what I mean by that is, there are some lifetime issues that this proposal does not attempt to analyze. And, where the analysis is similar, they offer a subset of what other proposals do. These decisions were made because the authors believe that they'll reduce a significant number of issues, and are easier to adopt. And that's worth it instead of going for more checks. The competing proposal, Safe C++, has you opt into safety checks on a file-per-file basis. So in that sense, it is also backwards compatible: all existing code compiles as-is. When you opt in to those checks, it adds new syntax, similar to Rust, to do the safety analysis checks. So you gain this benefit for only new code, but it also you get much more power. This syntax is necessary to communicate programmer intent to the checks, but is the "viral annotations" that the proponents of profiles don't like. So, basically, that's the thing: both are backwards compatible, but offer very different tradeoffs in the design space.
• chris_wot 2y ago
  I think he has this about right. The project I contribute to (and no, I'm not a massive contributor) is LibreOffice and it is a C++ codebase. It has a decent build system that is easy for anyone to run out of the box. It uses modern C++17+ code, and though it has a lot of legacy code, it is being constantly modified by people like Noel Grandin via clang plugins (along with a lot of manual effort). This code was originally developed in the late 1980s. A good packaging tool would have helped a lot.
  • einpoklum 2y ago
    > It uses modern C++17+ code Ha ha ha, that's funny. It uses pre-98 C++ code, that's set in stone because of extension/UNO APIs. Yes, you can use C++17 in a bunch of places, but not for the basic structures, classes, idioms etc. And - that's coming from a huge LibreOffice supporter. Speak at conventions, got the T-shirts, everything.
    • chris_wot 2y ago
      You are referring to the UNO API. The internal code is most definitely not stuck in "pre-98 C++ code".
  • School-Cotton 2y ago
    I'm stoked to hear they're on C++17 now. When I contributed to LibreOffice (GSoC 2012) they were still on C++03 !
    • badmintonbaseba 2y ago
      Well, can't really blame them in 2012. Especially that C++11 did bring an ABI break. Looks like they keep it fresh, although C++17 is getting a bit dated. Migration from C++17 to 20 or even 23 is probably a breeze though compared to migrating 03 to 11.
      • School-Cotton 2y ago
        IIRC it wasn't just the ABI break that was a problem, it was the fact that they wanted to build on systems that didn't have a C++11-compliant compiler available yet.
• hypeatei 2y ago
  One thing I cannot stand about C++ is the fractured nature of everything. Compilers, build tools, package management, etc... It feels like you need to be a wizard just to get a project compiling and start writing some code.
  • fsckboy 2y ago
    you DO need to be a wizard to launch a large C++ project. Yes, languages that are beginner friendly are ... friendlier. Yes, languages that stick to one or a small number of programming paradigms are friendlier. But if you want the "flexible efficiency and raw power of C" and "something higher level than C", C++ is your baby. Maybe it would be better if we all used Java, Rust, and Go, but C++ sings its siren von Neumann song to the wizards, and there will always be wizard musicologists who steer their projects toward those rocks and, when they have just enough wax in their ears, they sail right past the rocks and come out the other side of the straits leading the rest of the fleet. You can choose to follow them or not, for there's no shame in coming in 4th.
    • pjmlp 2y ago
      So much for the theory, then there is the hard reality how standard library is implemented, the variantions across implementations, and how the ongoing ABI drama is preventing any performance improvements to it.
    • lenkite 2y ago
      Even the wizards are moving to Rust/Zig since C++ stdlib performance is becoming terrible thanks to the ABI-frozen till heat-death of the universe decision. Even wizards don't want to build a stdlib of their own from scratch. Feel the committee was smoking weed that day in la-la land. You can ignore all the safety stuff from Sean Baxter, but saying no to performance on the altar of permanent, un-specified ABI backward compatibility - when such was never mentioned as a design goal of C++ - means its "Goodbye C++" for a long, long list of orgs and "wizards". The ABI was NEVER specified formally by the C++ standard - so why bother sacrificing the world for its immortal existence ? C++ is NO longer the choice of language for greenfield native projects and the committee takes the full blame.
• PittleyDunkin 2y ago
  > Nimble, modern, highly capable tech corporations that understand that their code is an asset. (This isn’t strictly big tech. Any sane greenfield C++ startup will also fall into this category.) Oh I see, this is a fantasy.
  • tucnak 2y ago
    The Rust people pursue "solidarity" as a virtue. They don't understand that factions is a way of life, so any sufficiently impactful technology will be "fractured" to some extent. This is a good thing. Unitarity, solidarity, homogenous philosophies—are not, but they would have to learn it the hard way like everybody else.
    • samatman 2y ago
      Good thing they aren't thin-skinned and censorious! Being able to take well-meant criticism in stride is so important, I'm glad that's a core value for them.
  • badmintonbaseba 2y ago
    Keyword is "sane". You can probably count all "sane greenfield C++ startups" on one hand.
  • mkoubaa 2y ago
    It's also just plain wrong. Even the cleanest most beautiful and efficient code is a liability. You sell software, not code. It's all about the magnitude of the liability, not the direction
    • fwip 2y ago
      Code is an asset in the same way that any process documents in your organization are. They represent codified solutions to problems. You do not need to re-solve this problem, and when a similar problem occurs, you can adapt the existing solution to the new problem. Another way to think about it: if code was not an asset, we would delete it immediately after compilation.
• saurik 2y ago
  I compile a lot of C++ code from a lot of places, and the only time I run into code that somehow simply doesn't work on newer versions of C++ and where the developers aren't even sure if they will accept any patches to fix the issue as they claim it "isn't supported" to use a newer version of C++--even for the public headers of a library--is, you guessed it: code from Google. Meanwhile, most of the C++ code from Google seems to be written in some mishmash of different ideas, always at some halfway point along a migration between something ancient and something passable... but never anything I would ever dare to call "modern", and thereby tends to be riddled with state machines and manual weak pointers that lead to memory corruption. So... I really am not sure I buy the entire premise of this article? Honestly, I am extremely glad that Google is finally leaving the ecosystem, as I generally do not enjoy it when Google engineers try to force their ridiculous use cases down peoples' throats, as they seem to believe they simply know better than everyone else how to develop software. Like... I honestly feel bad for the Rust people, as I do not think the increasing attention they are going to get from Google is going to be at all positive for that ecosystem, any more than I think the massive pressure Google has exerted on the web has been positive or any more than the pressure Google even exerted on Python was positive (not that Python caved to much of it, but the pressure was on and the fact that Python refused to play ball with Google was in no small part what caused Go to exist at all). (FWIW, I do miss Microsoft's being in the space, but they honestly left years ago -- Herb's existence until recent being kind of a token consideration -- as they have been trying to figure out a tactical exit to C++ ever since Visual J++ and, arguably, Visual Basic, having largely managed to pivot to C# and TypeScript for SDKs long ago. That said... Sun kicking Microsoft out of Java might have been really smart, despite the ramifications?)
  • groos 2y ago
    Whatever gave you the idea Microsoft "left" C++ years ago? It has massive code bases in C++ and continues to invest in its compiler teams and actively tracks the C++ standard. It was the first compiler to implement C++20 mostly completely, including modules, which other compilers have yet to catch up to. Like other mature companies, Microsoft realized decades ago that they can be a one-tech-dependent company and hence has code in C++ and .NET, and is now exploring Rust.
• moralestapia 2y ago
  [flagged]
  • klempner 2y ago
    The idea that RAII covers "99% of your ass" is "the low-IQ level statement". Temporal safety is the primary hard problem from a memory safety standpoint, and RAII does nothing to solve it at least the moment a memory allocation crosses abstraction boundaries.
    • moralestapia 2y ago
      No, if you have temporal safety issues you didn't understand RAII. That is pretty much the whole point of RAII.
      • AnimalMuppet 2y ago
        If you want anyone to believe you, you're going to have to give more than just a blank assertion. Can you give at least a sketch of your reason for your claim?
        • moralestapia 2y ago
          Reasoning is, if your objects outlive the scope of your class, then they most likely belong to a class that's higher in the hierarchy (they already do, de facto).
          • SoothingSorbet 2y ago
            Please explain how you would solve the iterator invalidation problem using only C++ and RAII. Thanks.
            • moralestapia 2y ago
              This small thread is about temporal safety so you're out of luck.
• __d 2y ago
  The author doesn’t appear to consider the use of binary-only (typically commercial licensed) libraries. There’s still a need for an ABI and “modern tooling” isn’t a magic wand.
  • kkert 2y ago
    I'd guess that majority of such binary-only libraries use C ABI interfaces. The entire Windows ecosystem of COM modules works on top of C ABI's.
    • rfoo 2y ago
      Until the moment when you are forced to use a third-party SDK with std:: and boost:: (yeah, WTF?) types in the interface. Oh, and you can't avoid that, say, you are working on a trading bot and that's the only "supported" way to connect to an exchange. In the end people usually just reverse engineer and reimplement to get rid of such cursed blob. Fortunately, it works - the vendor can't effectively push all clients to update their SDK too, so all wire protocols are infinitely backward compatible.
      • gary_0 2y ago
        The last time I was forced to deal with such a proprietary SDK (that required an ancient Windows C++ runtime, and segfaulted like crazy, natch), rather than waste months reverse-engineering it, I wrapped it in a separate process and talked to it via IPC. That got the job done, and every time their shitty code locked up or crashed, I just restarted the wrapper process from the main application.
        • marcosdumay 2y ago
          Serialized data over stdin/stdout is becoming my favorite protocol for ABI compatibility. The amount of problems this solves is incredible, and it creates none of the ops issues with configuring and launching some new kind of Docker image.
      • HelloNurse 2y ago
• mgaunard 2y ago
  The main problem with bad C++ tooling is often the same, it's having a modular system that relies on importing/exporting binaries, then tracking binary versions when combining applications. You should only track source versions and build things from source as needed.
• shultays 2y ago
  “We must minimize the need to change existing code. For adoption in existing code, decades of experience has consistently shown that most customers with large code bases cannot and will not change even 1% of their lines of code in order to satisfy strictness rules, not even for safety reasons unless regulatory requirements compel them to do so.” – Herb Sutter with large code bases cannot and will not change even 1% of their lines of code in order to satisfy strictness rules Do people really say this? Voice this in committee? I have been in a few companies, and one fairly large one, and all are happy to and looking forward to upgrade newer standards and already spend a lot of time updating their build systems. Changing 1% of code on top of that is probably not really that much compared
  • MathMonkeyMan 2y ago
    A company that I worked at had a few very large C++ related migrations, and they were all very very expensive. The first was removing `long` from the code, since a lot of code assumed its size (is it like `int` or like `long long int`?) and as machines were upgraded it caused problems. The second was moving to C++11/14/17. Most of the difficulty was toolchains on unixen that did not support the new versions of the language, or for which support was incomplete, or for which upgrading to a version with support broke existing builds. The third was moving to Linux from big iron unixen. As far as I understand, this initiative is still underway. It was already underway in 2011 when I joined the company. This is a rich company with a large, healthy engineering department. I imagine that most other companies would not or could not bother.
    • ModernMech 2y ago
      That old joke about Stroustrup inventing C++ to keep developers perpetually employed keeps ringing true.
  • Hilift 2y ago
    Are you referring to his book written 20 years ago or 25 years ago? "customers with large [C++] code bases" there aren't that many of these. Vendors, government. With code bases that have stewards, not programmers.
• mgaunard 2y ago
  If you're comparing Herb Sutter and the Google people at the standard committee, there is one thing that was clear: Herb was good at getting people to agree on compromises that served everybody, while Google was mostly claiming they knew better than everybody else and pushing their own agenda.
• seanhunter 2y ago
  Ports of massive legacy codebases are possible and they happen. They can be extremely difficult, they take will and effort but they can get done. The idea that you have to slow down the development of the language standard for people who won't port to the new version is weird- Those people won't be updating compilers anyway. How do I know this? I migrated a codebase of about 20m lines of C++ at a major investment bank from pre-ansi compilers to ansi conformance across 3 platforms (Linux, Solaris and Windows). Not all the code ran on all 3 platforms (I'm looking at you, Solaris) but the vast majority did. Some of it was 20 years old before I touched it - we're talking pre-STL not even just pre ansi. The team was me + one other dude for Linux and Solaris and me + one other different dude for windows, and to give you an idea the target for gcc went from gcc 2.7[1] to gcc 4[2], so a pretty massive change. The build tooling was all CMake + a bunch of special custom shell we had developed to set env vars etc and a CI/CD pipeline that was all custom (and years ahead of its time). Version control was CVS. So, single central code repo and if there was a version conflict an expert (of which I was one but it gives me cold sweats) had to go in, edit the RCS files by hand and if they screwed up all version control for everyone was totally hosed until someone restored from backup and redid the fix successfully. While we were doing the port to make things harder there was a community of 667 developers[3] actively developing features on this codebase and it had to get pushed out come hell or high water every 2 weeks. Also, this being the securities division of a major investment bank, if anything screwed up real money would be lost. It was a lot of work, but it got done. I did all my work using vim and quickfix lists (not any fancy pants tooling) including on windows but my windows colleague used visual C++ for his work.[4] [1] Released in 1995 [2] Released in 2005 [3] yes. The CTO once memorably described it to me as "The number of the beast plus Kirat". Referring to one particularly prolific developer who is somewhat of a legend on Wall Street. [4] This was in the era of "debugging the error novel" so you're talking 70 pages of ascii sometimes for a single error message with a template backtrace, and of course when you're porting you're getting tens of thousands of these errors. I actually wrote FAQs (for myself as much as anything) about when you were supposed to change "class" to "typename", when you needed "typedef typename" and when you just needed "typedef" etc. So glad I don't do that any more.
  • throwaway2037 2y ago
    Was it Morgan Stanley? That is the only shop I can think of that is so focused on C++. Hell, they hired Bjarne Stroustrup. But since you say version control was CVS, then I guess it was Goldman. They still have that sheizen for SecDB/Slang today. And I assume that "Kirat" is Kirat Singh of Goldman SecDB/JPM Athena/BofA Quartz/Beacon?
• nottorp 2y ago
  Two factions? Considering C++ has everything, I'd assume there are tens of factions.
  • humanrebar 2y ago
    This is true. That is why there is no leadership committee for the C++ ecosystem. There is no way to select one.
• liontwist 2y ago
  “Governments are telling you to stop using C++”. This invokes the imagery of a 1950s Apollo era scientist saying something serious. But I promise you there is no visionary low level language authority in the background. It’s just a staffer being influenced by the circle of blogs prominent on programming Reddit and twitter. > no overhead principle It’s actually nice to hear they are asserting a more conservative outlook and have some guiding design principle. Bjarne is more of a super-bureaucrat than a designer. In the early days he pulled C++ into whatever language movements were popular. For a while it looked like Rust was having that influence. But the outcome has been a refinement of C++ library safety features which are moderate and easy to adopt.
• pornel 2y ago
  There will be eventually only one faction left using C++ — the legacy too-big-to-refactor one. The other faction that has lost faith in WG21, and wants newer, safer, nimble language with powerful tooling is already heading for the exits. Herb has even directly said that adding lifetime annotations to C++ would create "an off-ramp from C++"[1] to the other languages — and he's right, painful C++ interop is the primary thing slowing down adoption of Rust for new code in mixed codebases. [1]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3465r0.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p34...
  • jmull 2y ago
    > newer, safer, nimble "newer" is hopefully a non-goal. Unfortunately, an option that is both safer and nimble doesn't appear to exist. I'm still hopeful, but at the moment it looks like rust is our future. A fate only marginally better than C++.
    • marcosdumay 2y ago
      Everything out there is nimbler than C++. So you only have to select for safer to get those, and anything with managed memory and Rust are safer. (Not an exclusive set, but you'll need to actually evaluate other options.)
• bayindirh 2y ago
  I personally like these discussions about C++. Yes, I think C++ should continue to be C++. I also like it that way. On the other hand, having a bit more transparency into the workgroups and their way of doing things may allow the process become a bit more efficient, approachable, and maybe would allow shedding some of the problems which have accumulated due to being so isolated from the world. Some of the alleged events really leave a bad taste in the mouth, and really casts a shade of doubt for the future of C++. Lastly, alienating people by shredding their work and bullying them emotionally is not the best way to build a next generation of caretakers for one of the biggest languages in the world. It might not fall overnight, but it'll certainly rot from its core if not tended properly. Nothing is too big to fail.
• torginus 2y ago
  I have been saying this for a more than a decade, but the number one thing that killed C++ as an attractive modern language is (the lack of) modules - the ability to include C++ code and libraries from others (perhaps with transitive dependencies), would allow an actual community of devs and companies spring up around the language. Instead we have greybeards and lone warriors, and million-line legacy codebases, half of which have their own idea on what a string or a thread is.
  • shortrounddev2 2y ago
    Vcpkg has really improved the experience of linking 3rd party dependencies for me
  • fsloth 2y ago
    ” killed C++ as an attractive modern language” I’m not sure were you got this perception that it’s dead. C++ remains the only game in town in many domains. That said, _unless you work in those domains_ there is no good reason to use C++ IMHO. Apart from the legacy codebases, there’s lots of C++ greenfield development. ” the ability to include C++ code and libraries from others ” Libraries in vcpkg - a large number - are compatible enough to be used in this sense. It’s possible your specific domain is lacking contributions or you’ve been looking from the wrong places?
    • ghosty141 2y ago
      > I’m not sure were you got this perception that it’s dead. > C++ remains the only game in town in many domains. Yeah but not because people like the language but because there is no alternative. At work almost every one of us devs doesn't enjoy working with C++ but since many dependencies in the embedded space are written in C++ you don't have much of a saying which language you choose. For example, Qt supports basically only C++. Rust is the only mature contender in that space currently.
    • MichaelZuo 2y ago
      Yeah, a ‘module’ based system of various language is so much less efficient that it seems absurd to compare them for anything that actually requires that performance.
• fefe23 2y ago
  Oh no! Herb Sutter is leaving Microsoft?! That does not bode well for Microsoft. At least from the outside perspective it looks like he was the adult in the room, the driving force behind standards adoption and even trying to steer C++-the-language towards a better vision of the future. If he is gone, MSVC will again be the unloved bastard child it has long been before Herb's efforts started to pay off. This is very disheartening news. I'm happy he held out for this long even though he was being stonewalled every step of the way, like when Microsoft proposed std::span and it was adopted but minus the range checking (which was the whole point of std::span). Now he has been pushing for a C++ preprocessor. Consider how desperate you have to be to even consider that as a potential solution for naysayers blocking your every move.
  • ghosty141 2y ago
    Wait, why does std::span not do the range checking? We ran into that exact thing at work and were really confused why the hell it doesn't do it currently.
    • steveklabnik 2y ago
      I believe this is because [] doesn’t do checking normally, so this is seen as a consistency. I am not 100% sure, but I do remember it being a contentious decision. .at() is added in C++26.
  • bluGill 2y ago
    > Now he has been pushing for a C++ preprocessor. He has been showing it, but not pushing it. the difference is subtle but important. He is showing a lot of "what ifs" trying them, and pushing the useful ones back into the language. Reflection is on track for C++26 in large part because he inspired a lot of people with his metaclasses talk (a long time ago, but doing things right takes time)
  • chrsig 2y ago
    It looks like he's staying on the committee and what not, just changing his day job. That's actually one of the benefits of having a committee & iso standardization process -- things aren't so reliant on a single engineer staying employed at a single company. I'm sure it's never as clean a situation as anyone would like, but hey, world is a rough place sometimes.
• BD103 2y ago
  Also see "On 'Safe' C++", which goes deeper into many of the insights brought up by this article. <https://news.ycombinator.com/item?id=42186475 https://news.ycombinator.com/item?id=42186475>
  • vacuity 2y ago
    Having skimmed it, I hope more people read that article.
    • imp0cat 2y ago
      Several months later, I learned I had experienced slight brain damage due to hypoxia and I’ve been slowly recovering ever since. The worst part of all of this is that I said in that post that I was enjoying golang. In other words, I had brain damage and suddenly found writing Go to be fun. Take from that what you will OMG. ;) It's an interesting rant nonetheless.
    • imp0cat 2y ago
      One example of this is [...] the new proposed (but not yet approved) Boost website. This is located at boost.io and I’m not going to turn that into a clickable link, and that’s because this proposed website brings with it a new logo. [...] This logo features a Nazi dog whistle. The Nazi SS lightning bolts. The thing about dog whistles like this is that you can feign ignorance or act like someone is seeing something that isn’t there, but for something egregious it’s very hard to defend it in this case. Of course, there’s other political dog whistles out there in the tech world right now. Justine Tunney named her C library, cosmopolitan5, which I personally believe is named after the term Rootless Cosmopolitan. This is a pejorative Soviet epithet which was used primarily during Joseph Stalin’s antisemitic campaign in the late 40s and early 50s. This is obviously much harder to prove6 as Justine has done a very good job of deleting some very eyebrow raising tweets over the years, even having them scrubbed from The Internet Archive’s Wayback Machine [...] Justine, unfortunately, doesn’t appear to have made any amends either, at least publicly, or even acknowledged her past behavior, though she is more than happy to reference her time in the Occupy Wall Street movement. These days however, she’s busy working on llamafiles for Mozilla. For those of you not in the know, a llamafile is basically for turning an LLM’s weights into an executable. And then he makes (yet another!) detour to AI and C++ which I am going to follow. It's a massive post though. Right now I am an hour in and probably about 75% done and I am skipping most of the linked articles. Except for the Ender's game parts. I highly recommend those.
• serjts 2y ago
  The real, everpresent and probably future nail in the coffin of C++ is the lack of a standard apckage manager and build system. The rest is just what happened to be picked up by social/news as it is easier and flashier to talk about.
  • matt3210 2y ago
    Conan and cmake problem solved
    • serjts 2y ago
      Ah, we are from the same tribes! Let's go talk to the the bazel and to the vcpkg tribes. But what about the fact that cmake isn't a build system, also conan 2.0 was a bit rough the last I saw.. maybe thats why clion/intellij dropped support for it out of the box and now uses vcpkg?
      • einpoklum 2y ago
        There is a Bazel tribe? I've heard it mentioned a couple of time but I have yet to encounter a C++ project I need to build which supports Bazel but not CMake. In fact, just _any_ Bazel support seems to me quite rare. Am I living in a bubble? As for vcpkg - yeah, that's popular, for sure.
        • Conscat 2y ago
          Daisy Hollman says she has "drunk the Bazel kool-aid" and is a big proponent of its usage outside Google.
          • einpoklum 2y ago
            Bazel is a project created by Google, and Hollman works for Google. So - perhaps the Bazel tribe is people working at Google? There _are_ quite a few of those....
      • Conscat 2y ago
• EVa5I7bHFq9mnYK 2y ago
  What about performance? The appeal of C was that it translated nicely to pdp-11 instructions with virtually no overhead. Then the appeal of C++ was that it translated nicely to C code (in fact, first versions of C++ were just a preprocessor, passing the job down to the actual C compiler), and you could still insert ASM code if needed. All these new features introduce some run-time overhead, it seems.
  • gollum999 2y ago
    Which features in particular? One of C++'s core tenants is (and has been since the 90's) zero-cost abstractions. Or really, "zero-runtime-cost abstractions"; compile times tend to increase. Obviously some abstractions necessarily require more computation (e.g. raw pointers vs reference-counted smart pointers). But in many cases new features (if implemented correctly!) give better semantics and additional compile-time safety while still compiling down to equivalent binary.
    • einpoklum 2y ago
      So, here's the thing: Officially, C++ is committed to "What you don’t use, you don’t pay for (zero-overhead rule)”. This is item 2.4 in the reaffirmed design goals: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3466r0.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p34... but the current ABI _forces_ some abstractions to have unnecessary cost. For example: "Why can a T* be passed in register, but a unique_ptr<T> cannot?" https://stackoverflow.com/q/58339165/1593077 https://stackoverflow.com/q/58339165/1593077 another example is improvements in the implementation of parts of the standard library. And that is not the only thing that prevents zero-cost abstraction. C++ does not support pointer restrction, see: https://stackoverflow.com/tags/restrict-qualifier/info https://stackoverflow.com/tags/restrict-qualifier/info in practice, compilers support it for some contexts. (Anoter, minor issue is the discrepancy of "No viral annotation" and "no heavy annotation" with the need to mark things noexcept to avoid exceptio handling overhead.)
      • nickelpro 2y ago
        For unique_ptr: This is not a problem that can be solved by the standards committee, they don't control the SysV / Itanium / Win64 standards. You can still use raw pointers if you want to, nothing has been lost from C. For restrict: Universally supported as `__restrict`, thus not a priority for anyone to "officially" solve. Most major performance complaints fall into this category. Eg, std::regex is bad, sure, but nobody uses std::regex so fixing it doesn't matter.
• cryptonector 2y ago
  > Speaking of big tech, did you notice that Herb Sutter is leaving Microsoft, and that it seems like MSVC is slow to implement C++23 features, and asking the community for prioritization. Uh, they took decades to implement a bunch of C99 features. Is that predictive? I suspect it is.
• deleted 2y ago
  [deleted]
• omoikane 2y ago
  > Stories of people trying their best to participate in the C++-standard committee process across multiple years This links to: https://thephd.dev/finally-embed-in-c23 https://thephd.dev/finally-embed-in-c23 It was a fascinating story, particularly about how people finally coming to terms with accepting that a seemly ugly way of doing things really is the best way (you just can't "parse better"). The feature itself is interesting too. https://gcc.godbolt.org/z/jGajc6xd5 https://gcc.godbolt.org/z/jGajc6xd5
  • tialaramex 2y ago
    It's fascinating how much more complicated this ends up being to deliver in the C and C++ ecosystem. #embed has to pretend - in principle - that we're going to conjure all these byte values into existence, as actual numbers, and then by the "as if" rule the compiler is not really going to do that because it would be crazy slow. The reality that we're just going to shove the data into the program as if it was an array is an (obviously, implemented everywhere) optimisation, rather than part of the language specification. The analogous Rust `include_bytes!` just gets you a &'static [u8; N] -- an immutable reference to an array of N bytes which lives forever. At first I thought OK, well, maybe the C approach lets you do some clever compile stuff that Rust can't do. Nope. If I have a compile time function checksum which calculates a 64-bit checksum of the slice passed by immutable reference - and a file of 128MB of data called firmware.bin, Rust is completely fine with let sum = checksum(include_bytes!("firmware.bin")); and that results in a 64-bit value, the 128MB file evaporated after being checksummed.
• physicsguy 2y ago
  C++ is still important in domains where performance is really critical. I also think there's a place where it can easily be supplanted, but currently cross platform native software has Qt and bindings for it in other languages are mixed. In performance critical things, Rust still doesn't feel like the final answer since you end up cloning a lot and refactors are very painful. Go obviously has it's issues since SIMD support is non-existent and there is limited control over garbage collection, though it works well for web APIs.
  • Conscat 2y ago
    You can write SIMD in Go asm, and wrap it up in a normal Go API. It's not great though.
    • physicsguy 2y ago
      I'm well aware, but in practice there needs to be some way of at least autovectorising loops built in to the compiler, even JIT/GC'd languages like C# will do this for you.
      • neonsunset 2y ago
        .NET's compiler does not perform loop autovectorization as it has not been as profitable of a compiler throughput investment as other optimizations (but it does many small optimizations that employ SIMD operations otherwise like unrolling string and span comparisons, copies, moving large structs, zeroing, etc., it also optimizes the SIMD operations themselves ala LLVM). .NET does however offer best-in-class portable SIMD API and large API surface of platform intrinsics both of which are heavily used by CoreLib and many performance-oriented libraries. You can usually port intrinsified implementations hand-written in C++ to C# while making the code more readable and portable and not losing any performance (though sometimes you have to make different choices to make the compiler happy). https://github.com/dotnet/runtime/blob/main/docs/coding-guidelines/vectorization-guidelines.md https://github.com/dotnet/runtime/blob/main/docs/coding-guid...
        • 2y ago
• paulddraper 2y ago
  > We’re basically seeing a conflict between two starkly different camps of C++-users: > * Relatively modern, capable tech corporations that understand that their code is an asset. (This isn’t strictly big tech. Any sane greenfield C++ startup will also fall into this category.) > * Everyone else. Every ancient corporation where people are still fighting over how to indent their code, and some young engineer is begging management to allow him to set up a linter. Well said. And because of this, a lot of the first is leaving for greener pastures.