I really wish the std would drop this pretense and focus on C++'s strong point: Continue being the fastest systems language possible.

Everywhere in the std lib you can see compromises that require rewriting substantial portions for any real time application.

Things like: shared_ptr eagerly using atomics whenever possible; std::string allocating; the lack of built-in faster std::allocator replacements like bump allocators, memory pools, etc; no lockless and wait free concurrency primitives; no architecture-aware thread pools or even architecture descriptions; no IPC primitives; etc.

Considering how many C++ developers are working on things like games, high performance server applications, databases, and operating systems, it's just bizarre how inappropriate the standard headers are for these tasks.

Even something trivial like casting bytes off the wire to a packed struct is an exercise in frustration due to aliasing rules that should have been encoded in the type system and invisible to the user.

  > Continue being the fastest systems language possible.

You'd need to smatter "_restrict" everywhere to skirt this.

True but the only practical competitor is Rust, and they gain some alias information (mut) and lose other aliasing information (type punning is fully allowed in unsafe code all the time).

That's separate from what I'm referring to. In C++ a float* and an int* can never alias. In Rust f32* and u32* are allowed to. Meaning in a situation where whether they can alias can't be established by provenance (e.g. in a separately compiled function where the compiler at compilation time can't tell where the float and int came from) then C++ is able to use types to rule out aliasing, but Rust cannot.

> I really wish the std would drop this pretense and focus on C++'s strong point: Continue being the fastest systems language possible.

You've essentially described C, not C++. C++ has a different philosophy and makes different trade-offs.

C++ is at least still pretty committed to the you only pay for what you use principle. As far as I know RTTI is the only real exception (corrections welcome), but even RTTI can be disabled in many compilers.

Some of your gripes with the standard library can be addressed with libraries, perhaps from the Boost project.

I'd disagree pretty strongly with that. C is more focused on being relatively simple to implement and backwards compatibility with the past 50 years. (I read a blog post by a C committee member talking about that recently, wish I could find the link)

Just look at the garbage fire which is the standard library. qsort. strtok. rand.

C++ should (in theory at least) be able to match or surpass C for _any_ performance benchmark, because it simply gives you more tools in your toolbox. For example, C is never going to be able to beat std::sort because it can't monomorphize in the compare function.

I'm not saying C++ is perfect either (looking at you unordered_map and regex). But I am saying people look at C with rose colored glasses.

To achieve that, you need stuff like monomorphized templates, actual arrays and slices being distinguished from pointers, well-defined rules on pointers (like Rust's rules about references and mutable references, or strict aliasing in C++), and the freedom to let the compiler reorder structure fields for better alignment and space usage. Runtime polymorphism, like virtual functions in C++, are better as a core language feature rather than something implemented as a struct of function pointers, because that way the compiler can devirtualize some calls.

All of these things, I think most C programmers would be against adding to C. And pointer rules are historically controversial; for example, Dennis Ritchie was against adding noalias to C in 1988[1].

[1]: https://www.yodaiken.com/2021/03/19/dennis-ritchie-on-alias-...

C++ templates allow for declarative nested inlining into a single compilation unit that is extremely difficult to achieve with C macros.

See elsewhere in this thread for discussion of boost, it's not applicable.

C macros are way simpler as they are only text. I still use them alot in C++.

If the target code is full of virtual function calls, yeah it gets gross. But if you need dynamic dispatch, C isn't going to be any better, you'll just be reinventing vtables by hand. Similarly, resource acquisition and release happens in C too, you just have to do it by hand instead of letting the destructor do it for you.

One ultra gross thing I see all the time in C++ disassembly though: constantly creating copies of a std::string, using them once for a comparison or something trivial, and then throwing them away. Multiple times in the same function. Its the developers fault, they shouldn't be creating new objects, they should be passing a pointer or a string_view or something. Unfortunately, C++ is copy rather than move by default, so its too easy to do this by accident.

Another gross thing? (Not C++ specific) 20 functions in a row that are just a single return instruction. Since functions have to have distinct addresses (that's my understanding at least) the compiler/linker can't easily fold identical functions together. Implementations can optimize as long as everything still works (the "as-if" rule). And I know some compilers do. But in practice, it seems they suck at it. So I get to look at 20 lines of assembly in a row that are just `bl`.

That tool is called Godbolt at gcc.godbolt.org. This is common enough that Godbolt is a verb with a lot of C++ programmers.

Compile time would also be an exception.

For me it mostly looks like a reject pile for a stdlib that I must also reject most of the time.

The alignment of incentives between these library authors and people that use C++ for high performance applications is just off.

It’s also the opposite: a place where possible candidates for the standard get tried out first.

But like you, I rarely use it.

https://www.youtube.com/watch?v=LIb3L4vKZ7U

std::allocator is to allocation what std::vector is to vexation (or: designing allocators that don't not-work)

I don't see that point because this is not a technical argument, is it?

> It's up to the allocator's user to call one of the several available varieties of placement new on the block of memory allocated.

This would have been a point if that's the control you don't have with the allocator interface. But you do.

I imagine that you're not suggesting invoking placement-new oneself all over the place whenever one allocates the backing storage?

> This would have been a point if that's the control you don't have with the allocator interface. But you do.

Well, std::allocator::construct() has been removed in C++20. You still have std::allocator_traits::construct but it just calls std::construct_at().

> you're not suggesting invoking placement-new oneself all over the place whenever one allocates the backing storage

Well, that's what all the standard containers do (vector, list, map, etc). Or you can use std::construct_at() instead but that effectively is a variant of the placement new. Of course, you'd better use std::make_unique()/make_shared() (which normally still devolves to placement new IIRC) instead of manipulating raw pointers and invoking constructors manually.

You and I must have a different definition of "easily "

  template<typename T>
  struct Foo {
    using value_type = T;
    Foo() = default;
 
    template<typename U>
    constexpr Foo(const Foo <U>&) noexcept {}
 
    T* allocate(std::size_t n) {
        if (n > std::numeric_limits<std::size_t>::max() / sizeof(T))
          throw std::bad_array_new_length();
        auto p = static_cast<T*>(std::malloc(n * sizeof(T)));
        if (!p) throw std::bad_alloc();
        return p;
    }
 
    void deallocate(T* p, std::size_t n) noexcept {
        std::free(p);
    }
  };

  std::vector<int, Foo<int>> v;

There's also a lack of traits that can describe what's required of a specialized allocator. For example, std::map only needs to allocate 1 object at a time in practice while std::vector needs to allocate a contiguous count of objects.

You mean you want string_view? It still calls strlen when you instantiate it with a literal though.

I don’t really agree with this. There’s also a group of developers that want more safety, but don’t feel like setting up (or in the case of Coverity purchasing) additional tooling. Some people just want a decent out of the box experience.

At some point, the deficiencies of a language becomes a concern for its end-users rather than its developers.

I think that this level of professional malpractice is something that can't be solved by language choice.

When someone encounters a crash, their actionable item isn’t to go ask the C++ committee for better safety. That’s an unassailable wall for most developers, assuming they even understand what’s happening and that there are better options out there.

1. Most of those who care about memory safety have already left the building.

2. Those who are still in the building and care don't speak up because their colleagues don't value it, and many of their colleagues will view them as having lower competence.

It is not about what we want. It is what we need

Not real.y "we". I have lost any interest in C++ now. I loved it, in the day. Time has moved on

The whole deal with interpreted languages was to avoid sitting there for a few minutes every time you make a god damn one letter change, with the unfortunate but usually acceptable trade-off of some execution speed.

Any recompile triggers a lot of recompilation.

And no, I can't change the code the other hundred devs are writing in my company.

In C++ there is no individual units. In C it's somewhat plausible with some discipline.

The problem with C++ templates is accurate, and is one of the several reasons why I avoid using templates in my own C++ code. I don't have that freedom in the code I write for my employer, though.

> In C++ there is no individual units.

Yes, there are. Those unit boundaries are often blurred by other C++ features, but they do exist.

There's a still a notion of the compilation unit, which is the cpp file on which you invoke the compiler. Due to templates being prevalent in C++, included files contain the implementation as well; so any changes you make there lead to re-compiling a lot more compilation units than, for example, in C.

As I understand it, C++’s slow compilation comes from the fact that it usually parses all of your header files n times instead of once. This isn’t a problem with static typing. It’s a problem with C++, and to a lesser extent C.

That's one of the things that can slow compilation down but it's definitely not the only one. It helps that precompiled headers (and maybe modules?) can go a long way towards reducing and possibly eliminating these costs as well.

I think some (most?) of the larger remaining costs revolve around template instantiation, especially it impacts link times as well due to the fact that the linker needs to do extra work to eliminate redundant instantiations.

Yeah, I see this as another consequence of C++'s poor compilation model:

- Compilation is slow because a template class in your header file gets compiled N times (maybe with precompiled headers). The compiler produces N object files filled with redundant code.

- Then the linker is slow because it needs to parse all those object files, and filter out all the redundant code that you just wasted time generating.

Its a bad design.

Somewhat related, there was some work in Rust about sharing monomorphized generics across crates, but it appears it was not a universal win at the time[0]. I'm not sure if anything has changed since that point, unfortunately, or if something similar could be applied to C++ somehow.

[0]: https://github.com/rust-lang/rust/issues/47317#issuecomment-...

It was a product of the design constraints in the 70s when memory was expensive, and compilers couldn't store a whole program in memory during compilation.

The problem C++ has now is that the preprocessor operates on the raw text of a header file (which is a relic from C). This means the same header file can generate totally different source code each time its included in your program. C++ can't change that behaviour without breaking backwards compatibility. So headers get parsed over and over again "just in case" - wasting time producing excess code that just gets stripped back out again by the linker.

The way C++ works doesn't make any sense now that memory is so much cheaper. Go, C#, java, rust, zig - basically every compiled language younger than C++ compiles faster than C++ because these languages don't contain C++'s design mistake.

Rust doesn't share monomorphized generics across crates, but at least each crate is compiled as a single compilation unit.

Sort of. The primary issues are:

1) The C/C++ grammar is garbage.

Note that every single modern language has grammatical constructs so that you can figure out what is "type" and what is "name" without parsing the universe. "typedef" makes that damn near impossible in C without parsing the universe, and C++ takes that to a whole new level of special.

2) C++ monomorphization

You basically compile up your tempate for the universe of every type that works, and then you optimize down to the one you actually use. This means that you can wind up with M*N*O*P versions of a function of which you use only 1. That's a lot of extra work that simply gets thrown away.

The monomorphization seems to be the biggest compile time problem. It's why Rust struggles with compile times while something like Zig blazes through things--both of those have modern grammars that don't suck.

2. This is incorrect. What's happening is that each template instantiation for a new set of template arguments requires reprocessing the template to check types and generate code, and also that is done per translation unit instead of per project. Each distinct template instantiation increases the compilation time a bit, much more than it takes to parse the use itself. That's why it's easy to have a small C++ source that takes several seconds to compile.

Sorry, the C++ grammar is terrible. There are lots of things where C++ can't figure out whether something is a class or name or template or constructor call until looking way far down the chain.

However, you are the first person I think I have ever heard claim that Rust is faster than C++. Rust is notoriously slow to compile.

Zig generally compiles much faster than most C projects I've used. However, that is difficult to lay at the hands of C as a lot of those are the build system being obtuse.

When did I say otherwise? What I said was that it's not the main cause of C++'s long compilation times. The grammar causes other problems, such as making it more difficult to write parsers for IDEs, and creating things like the most vexing parse.

>However, you are the first person I think I have ever heard claim that Rust is faster than C++. Rust is notoriously slow to compile.

It's kind of a mixed bag. Given two projects of similar complexity, one in C++ and one in Rust, the one written in Rust will take longer to compile if organized as a single crate, because right now there's no way to parallelize compilation within a single crate. However, compiling the C++ version will definitely be the larger computational task, and would take longer if done in a single thread. Both contain Turing-complete meta-languages, so both can make compiling a fixed length source take an arbitrarily long time. Rust's type system is more complex, but I think C++'s templates win out on computational load. You're running a little dynamically typed script inside the compiler every time you instantiate a template.

It's not always easy to use, but the focus on reproducible builds and caching is really nice.

Edit: I guess it doesn't fetch a specific compiler for you by default, but you could probably ship your toolchain somewhere and pin it in your WORKSPACE file.

This stopped working so well with Windows, where you usually can't just copy executables out of version control and run them (you have to run an installer instead), but it still works pretty well for the Unices.

Not in that pinning versions or the APIs or the actual contents of the packages we rely on, so much that every time we update a (rather small) set of dependencies there's nearly always some weirdness around vcpkg itself or the builds.

Just the last week we updated to a newer tag and building openssl failed setting up the nasm build dependency, claiming it already existed.

Which it did - there was a "nasm" folder in the tools directory it was trying to install it in, from the last time it was installed presumably and somehow got it's internal state messed up. But this caused a fatal error. I eventually worked around it by deleting the nasm directory from every build machine and letting it reinstall exactly the same package again.

But the time before there was also a "random" build error, claiming that xz wasn't installed, despite the log showing it was just installed as a dependency in the line above. I guess this was fixed upstream, as the "workaround" was to use a tag from a month or so previous, but now seems to be fixed.

Perhaps I'm using it wrong, perhaps you should "always" completely blast away the global vcpkg folder (and any vcpkg stuff cached in build directories from it's cmake integration) every time you touch it. But it's still time and effort for something that probably should be seamless.

1. It uses formalism to try to deny that there is some competition for brain-share and number-of-users among programming languages, or rather around the communities around programming languages.

2. It ignores how C++ has, multiple times, semi-reinvented itself rather than "being C++", spurred by features, idioms or use patterns in other languages, and even managed to mostly "eat their lunch", for better or worse (e.g. the D language).

3. A call for "aiming for coherence", while ignoring how it sometimes contradiction with other principles, such as: "What you don’t use, you don’t pay for" (the zero-overhead rule); and failure to argue even for a balance.

4. "In committee, we frequently spend time on things that only a small number of people care about." <- but these are sometimes extremely important things, relevant to many, and in the future perhaps most programmers; and a small number of people care about them because most people aren't aware of their current or future importance. This is especially poignant where those things will only become important if the committee adopts them, and otherwise can be argued retroactively to never have been worthy of any discussion.

etc. etc.

Sure you can write virgin code in C++ and choose some "modern" incarnation of the language or some subset thereof. But there exists billions of lines of legacy that most of us have to deal with. Daily or occasionally. Usually without the option of rewriting.

Then there's the tooling. The horrific, antiquated build process which we try to automate with tools that just make things even more complex. The lack of a practical standard library that says "you know, those things you often have to do, we should actually offer those". It is neither helpful nor useful that C++ doesn't have room for HTTP, JSON, basic networking abstractions etc.

I would not recommend a beginner learn C++ today. I'd recommend Rust or Go. Most people are going to be more productive AND produce more robust code in fewer years. One can be annoyed by that statement, but you would have an uphill battle claiming that it is wrong.

I don't think C++ is worth the investment for a new programmer. Dealing with C++ just gets more complex the more changes we make to it and the more we evolve it. C++ isn't just one spec - it is the aggregate of all specs and practices that have existed because that's what you risk ending up working on in real life.

It's a bit much history.

From the perspective of the programmer I think it is a much better idea to put some energy behind a fresh start. And try to remember the mistakes that were made. Right now, for C++ developers, Rust looks like the closest thing to a fresh start. But it may be that Go is going to make a lot of C++ programmers a lot happier too since not all C++ code lives in constrained environments or actually has to deliver bare metal performance.

I don't think the C++ community even wants C++ to turn into something that is comparable to Rust or Go. Doing that to C++ would require throwing things out and creating something very different.

And when you look into C++ libraries/stdlib, they often look like they're written in another language entirely. This is not normal.

Why would that be true? When you write a library, you are writing code to cover all possible uses; everything within the scope of your library should at least be considered, even if you personally have no need of that particular bit of functionality. But when you write a program it only has to do one thing, so of course it's going to be simpler. To me, it seems obvious that (good) library code will be very different from (good) application code.

(I've used libraries that were written like applications, but they were bad libraries; I was constantly fighting the fact that the library author wrote only for their own use-case, and didn't consider any other.)

This isn't always true, and can't be generally expected, but I think it is true in the case of Go's standard libraries. These are high quality, and are one of my top examples of good, real source code to study (along with the DOOM and Quake source code). A nice touch in Go's library documentation is that you can click any API element (type, function, etc.) to be brought directly to its source code.

Yes, there are differences between writing libraries and writing programs. But there is value in studying well-written source code, even when it has concerns and requirements that differ from yours. You can adapt what you learn to your needs.

Here’s std::vec: https://doc.rust-lang.org/src/alloc/vec/mod.rs.html

I tried to read C++’s vec class when I was learning C++ and I was confused and lost. I agree with the GP post - it feels like another language.

I see rust's safety guarantees like having a good static type system. Static type systems don't claim to prevent all bugs, but they do catch an awful lot of bugs at compile time in practice. Rust's default safety with opt-out unsafe blocks work the same way. Despite what some zealots would have you believe, the point isn't to make every single line of code "safe". Good rust code still uses unsafe code - for example your binary includes unsafe code whenever you use Vec or Box from std. But all unsafe code blocks are explicitly called out as such, tested thoroughly (eg with miri) and usually constrained to a small part of your program. You can think about it as, C or C++ programs are 100% unsafe. Rust programs are usually only ~2% unsafe or so. That makes a huge difference in practice.

Unsafe code can also usually be encapsulated in safe wrappers. (Eg std::io::File wraps the unsafe call to open(), and std::Vec wraps some raw pointer operations). Unsafe also doesn't turn off the borrow checker. The only difference is unsafe blocks allow you to dereference pointers, call unsafe functions, and a few other things like that.

The standard library has more unsafe than most programs, because "data structures that need a lot of unsafe" has historically been an argument for being put in the standard library, because that way they'll be reviewed very carefully by experts.

(I will admit I've felt profoundly stupid when I go from "how hard could it be to implement std::optional/reference counted pointers/etc., anyway?", to say GNU's implementation of it in libc++.)

What the feeling of security that new features giveth, having to work with large idiosyncratic codebases and a wide variety of toolchains taketh.

This may not have been the intent, but the way I read it, it's saying that language evolution is now pointless and only library additions can be considered. That would be a pretty dire situation for C++ overall.

Never mind that this means many language issues will never be fixed, it would also mean that implementations face the burden of yet more standard library additions which quickly fall behind external libraries because of the added burden of ABI lockin, and now multiplied by several vendors vs just one third party library.

In my view, C++'s biggest problem is its design-by-committee structure, leading to a lack of pragmatism - in other words, perfect is the enemy of good. Pragmatism is what you see when you look at the standard libraries of languages like Python and Java: are they perfect? Far from it. But they prioritize being at least good enough for a good amount of situations, over being perfect. Which ends up being far more useful for regular people. And being useful for regular people is what makes a programming language successful.

But design by committee means if your proposal isn't perfect, it will get shot down. So the language remains bad for everyone's use cases, rather than at least becoming somewhat good for some people's use cases.

In my opinion, the world is on standby until Anders Hejlsberg feels like tackling a modern, next generation systems language.

[1] https://github.com/hsutter/cppfront

It seems that in the eyes of most of corporate America's management, C++ is a legacy language, and should be replaced with Java (which tbh makes sense in many cases given that Java's tooling and libaries are better than those of C++). Other companies are looking at Rust as a successor to C++.

Even if Herbs's work was completed and implemented by major compilers, it's hard to see much uptake - who's going to be approving porting legacy C++ code to a new modern C++, yet alone approving C++ for new projects?

Maybe if there is a Sutter C++ successor, it should drop the "C++" name which carries legacy associations, and call itself something new. Present itself as C++ successor, even if it comes from a starting point of being 99% backwards compatible with modern (say C++11 or later) C++. Sounds superficial, but I bet it'd make a difference in perception!

I've been reading Functional Programming in C++ by Ivan Cukic and I'd like to adopt this - it does require a lot of refactoring of this massive codebase.

Perhaps this is a massive, ancient codebase issue more than a C++ issue, though.

Edit: I don't know how you can arrive at this conclusion given the history of the language. The STL isn't the C++ standard library.

I would love to discuss this more, but dang has limited and nerfed my account.

Ironically I’ve just learned, however, that lambdas are actually anonymous classes! I’m currently up to the bit in yhe book I referred to before that explains how to do currying in C++.

The more I read, the more I think I’m working against the code base than I am against C++. I’m actually very curious how ranges work, something the book talks about later.

Edit: send an email to news@ycombinator.com

So it will die a death by entropy where noone can know the language.

It is possible to have a network supporting IPv4 and IPv6. I don't think the speed of migration is an issue. It is not a tremendous success but it is not a failure either.

In Python forward compatibility was often impossible. The migration benefit was low and the cost was high. Python is a great example how not to break things. I am little surprised that whole language is still popular after such failure of leadership.

Then nobody will use the new compiler because nobody wants to rewrite millions of LOC and introduce new bugs.

It’s even worse. They happily introduce breaking changes for some things, but not others.

I have once wasted days of work updating a codebase to build with C++/20 because the new standard suddenly changed the type returned by `u8` string literals (available for a decade already, it was introduced in C++/11) from const char* into const char8_t*, and they made these types incompatible.

As an old timer, this kind of made me laugh. I remember when people found the old stream operators burdensome.

What "C++" means depends on the project. Maybe that's why it's so hard for the standard -- they have to consider more than one project.

If C++ is ok with being a small language used by and for geniuses - I have no problem with that.

If C++ wants to be popular - we need a breaking change between the world of 2023 and 1990 - they don't know what we know now.

I like some parts of C++... it's too bad the "good language" is shackled to a mountain of razor blades.

[1] https://github.com/carbon-language/carbon-lang

Carbon gets talked a lot by people that somehow miss the language goals.

I might be in the minority here, but I genuinely enjoy writing modern C++.

My complaints are about it's dependency management story and lack of integrated, standardized tools for things like dependencies, testing, logging, etc.

I used to love C++ (and still do if we're talking about older standards), but the new stuff is just a baroque torture.

I don't mond C++ evolving into some thing of its own beyond all recognition, but there is a distinct lack of modern "C with Classes" language. Basically, C on steroids. There are attempts at that, but none is perfect and/or has enough traction to be viable.

There's more viable coding styles in C++ than I can honestly even bother to count. There's absolutely no reason to limit the language to one specific coding style when doing so would alienate large groups of users and you can set those limits yourself on your project.

For example, there are cases where the existence of move semantics necessitates adding some boilerplate when working with STL containers. There's no functional reason for it, just something to please the compiler.

One shudders to think how many times variations of that template have been written in house.

- structured bindings

- auto parameters in lambdas

- init statements in if and switch clauses

- template argument deduction for constructors

I was just recently appreciating the if statement with an initializer in C++17, which helps me express exactly what I want for variable scope in one line instead of multiple awkward ones.

C++ is an engineer's language, and it's ridiculous to imagine that we'd ever need a C++2.0 that cleans it up. Subjectively, you could say that some features are "ugly", but this is an evolutionary process, and there are bound to be vestigial features.

Yes, there are memory safety issues, but in practice, these are isolated in very few places. Take a compiler like LLVM for instance: most developers are working on transforms or analyses, and they're exposed to zero manual memory management. Sure, the Pass Manager needs to build passes, and the IR needs to be allocated, but that's about all the manual memory management there is.

Personally, I couldn't care less about standardized argv-parsing, as each project has its own set of complex requirements. There are JSON parsing libraries available for C++, and I don't see why it should be standardized. Faster hashing in std could be a low-priority feature, but projects like LLVM have their own optimized version of std data structures and algorithms.

I suppose a module system could be useful; most C++ projects are built with CMake which is already very good at finding and linking dependencies. Personally, my biggest pain point is compile-times, but that's really an LLVM/Clang problem.

Overall, the article doesn't seem to be written by someone who has a lot of experience with large C++ codebases.

It is really easy to get use-after-free in LLVM passes due to using eraseFromParent() instead of removeFromParent(), etc. As I recall, in some places the optimization code goes through really awkward patterns in order to keep track of the IR nodes that are dead to avoid UAF, none of which would be necessary if LLVM were written in a GC'd language. (Note: I'm not saying LLVM should be written in a GC'd language.)

Compiler building frameworks in managed languages.

Yes, most likely LLVM will never be rewritten into something else, yet security is a concern also in compiler code.

I guess the C++ community is coming to terms with not being the top dog of "zero-cost abstraction" languages anymore.

Really I think it's too late for C++. They had literal decades to fix very basic flaws, and they just haven't done it.

Accidental octal literals. Case fall-through. Missing `return`s. Accidental string literal addition. The whole module system mess.

They focused way too much on adding complex features and not at all on fixing footguns. As a result C++ is painful and dangerous. Too late to fix IMO.

[1] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p20...

https://www.nsa.gov/Press-Room/Press-Releases-Statements/Pre...

Even without legislation, I could imagine that the US government could try to enact software procurement rules that favor or require memory-safe implementations.

It happened with Macromedia Flash and it happened with Microsoft's Visual Basic. The JVM and industry attitudes to Java. PHP.

We have lost some good technology over time, please don't let us lose the good parts of C++.

No, that is false. It is akin to arguing that Christianity must be true because 2.4 billion Christians can't be wrong. The fallacy is easy to see because the argument can be applied equally to the world's 1.9 billion Muslims and 1.2 billion Hindus and 500 million Buddhists, etc. And yet these groups hold mutually-exclusive positions and so at least N-1 of them must be wrong.

Humans are social animals. With only a few exceptions, we tend to conform to the group. That tends to make us get stuck in very deep ruts. "Everyone is doing it" is absolutely no indication that "it" is a good idea.

[UPDATE] A lot of people seem to be missing the point here, so I feel the need to clarify: I'm not saying C++ is analogous to a relgion. I'm using the exclusivity of religious belief just as a short-cut to show that it is possible for large groups of people to hold false beliefs without getting into the weeds of which of those beliefs are actually false. The point is not that C++ is analogous to a religion, just that "adoption by millions" is not a valid argument for its merits.

[UPDATE2] I am also not saying that religion has no value beyond the truth of its objective claims. I am only saying that (some of) the world's major religions do make objective claims, some of those claims are mutually exclusive, and so some of them must be objectively false, and therefore it is manifestly true that large groups of people can hold objectively false beliefs, and therefore the fact that large groups of people hold a position is not evidence that that position is objectively true. Being "fit as a general purpose programming language" is an objective claim.

There's actually a pretty complex matrix in religious disagreement with or without exclusivity. And not all religions are exclusive at all. Islam's views of other Abrahamic religions is complicated, but it is exclusive about non-Abrahamic religions. Christianity sees Judaism as having been correct, but incomplete. Hinduism isn't essentially exclusionary (particularly to other religions which evolved from old Vedic practices), but is often confused with modern Hindu nationalism, which is. And even within single "religions" there are complicated lines where e.g. some Christians consider themselves to be in "communion" with some Christians, but not others.

So, yeah, bad example. It's a terrible thing to have pulled out to try to show clear mutually exclusive groups.

The problem with trying to come up with examples of large numbers of people holding objectively false beliefs is that you have to look outside the realm of science. The whole point of science is that it provides a mechanism for resolving disagreements about objective truth objectively (i.e. experiment) and so you just don't get a lot of people holding objectively false beliefs, at least not for any length of time. Religion is all that's left.

But the point me and a few others were making is that you don't seem to know much about religion, so it's probably not a good thing to use in analogies. Religion is definitely not a set of neatly divided mutually exclusive beliefs. Almost all of the world's adherents come from two families of religions -- Abrahamic or Vedic -- and within those groups there's a whole lot of similarity and varying levels of theological exclusivity.

I feel like gambling or the stock market may be better examples. If one person takes a long position on a stock and another short, they have mutually exclusive beliefs about it, and one of them will be wrong.

It's easy to see that driving on the LEFT side of the road is a fit as a general mode of transportation. Adoption by millions is a testament to that.

Both statements are true. The author didn't say only C++ is fit. Nor did he say a program written in BOTH C++ AND python (i.e. a system of driving on both left and right sides of the road) is fit.

The counter-argument (C++ is NOT fit as a general purpose programming language) is invalidated by millions of programmers who use it as such in the same way that thumbs are not fit for grasping is invalidated by, well, grasping with your hands.

It doesn't mean pliers are not fit for grasping just because thumbs are fit for grasping.

You're conflating types of evidence and types of arguments.

The equivalent statement would be that "adoption by millions is a testament to the viability of X as a cohesive religion".

No, but if millions of people actually did manage to use Brainfuck for general purpose programming, then that would be evidence that it really is fit as a general purpose programming language, even if it's not ideal.

Brainfuck isn't in that position, hence no one thinks it's fit, but C++ is. People do use it for general purpose programming, even if their program could be rewritten in a garbage-collected language.

>memory overhead at runtime.

These statements are true. The rest is grandstanding.

Maybe not, but that's a function of available/standard/free libraries rather than the language itself.

Personally I do use C++ for quick and dirty projects, but OTOH I've spent the last 10 years building libraries that make that convenient.

[Edit: To respond to the actual point: For every claim that X is fit as a tool to do Y, the evidence that millions of people use X to do Y is in fact proof of the claim. If the claim had been "C++ is the best language for general purpose programming", then your argument would have merit. But that wasn't the claim.]

The claim from the article is not about their beliefs, it is about their activity. If a million people say that one can live many different lifestyles from a tent but those people actually live in suburban houses, they can potentially all be wrong. If a million people actually do live in tents while living many different lifestyles, QED, it is demonstrated - they aren't holding false beliefs, full stop. It's not a belief anymore, it's a fact. The fact that they are doing it shows it can be done at all, and the large numbers show it's not an extreme claim that only one or two weirdo obsessives could contort themselves enough to use, it's general enough for millions to do over many lifestyles.

> "Everyone is doing it" is absolutely no indication that "it" is a good idea.

It is too; "When in Rome" is advice because whatever the Romans are doing, it isn't killing them or getting them into fights or mugged or annoying someone powerful. If you don't have any reason to do otherwise, eating what the Romans eat, drinking what they drink, behaving how they behave, is a far far better starting point than almost any other. As a guest in someone's house, trying behave how the homeowners behave is a good idea; 90+% of starting points will be worse, most things you could try to eat will make you ill or kill you, most of the world's thousands of programming languages are toys or niche domain systems or wildly outdated or proprietary and gone out of business. The ones millions of people use? Pretty good idea to use one of those, unless you have very good reasons for doing otherwise.

No, the claim is about a property of a programming language. The activity is cited as evidence in support of the claim of the fitness of C++ as a general-purpose programming language.

The problem with C++ is that it is a legacy language, and so the fact that a zillion people use it today might be because it's a good language, but it might also be because it has so much institutional inertia behind it that this is enough to override the fact that it's a totally shit language. The Catholic Church has been around for 2000 years, but that doesn't necessarily mean that its factual claims have any merit. The Church's success might be because it is in communion with the truth, or it might be because it has so much institutional and societal inertia that it keeps chugging right along despite having no actual merit. The success of the Church might also be due to people subscribing to the logical fallacy that because a lot of people subscribe to it that it must have some merit, which after a while becomes a self-sustaining cycle. (Note that a self-sustaining cycle is different from a self-fulfilling prophecy because the latter actually becomes true if enough people subscribe to it.)

C++'s fitness as a general-purpose programming language is not an exclusive assertion.

The equivalent assertion is "Christianity is a good/useful belief system" (and "Islam is a good/useful belief system")

Now, you could endeavor to disprove that equivalent assertion, but your earlier argument doesn't.

To be clear, "fitness as a general purpose programming language" is also something about which reasonable people can (and manifestly do) disagree. All I'm saying is that having large numbers of adherents is not a valid argument in favor of fitness any more than it is an argument in favor of goodness or usefulness. It's possible that all it shows is that a lot of people drank the kool-aid.

[UPDATE] It's also possible that most of the people using C++ think that it sucks, and they are all just using it because everyone else is using it.

But metaphysics/religion is different than programming language utility.

We can expect a higher degree of accurate judgment in the latter.

Of course it is. But religions make mutually exclusive objective claims. Metaphysics has nothing to do with it.

If something is used by millions as a general-purpose programming language it is fit to the task, regardless of the alternatives or how ideal it is.

Is this a thing really or just FUD?

What is not a real thing: regulations requiring such.

Some think regulations may come, others don't.

https://news.ycombinator.com/item?id=33560227 - NSA urges orgs to use memory-safe programming languages

[0:23:57] SP: We're also discussing internally around pending legislation around safety and security, what Adobe's response is going to be. Right now our thinking is we would like to publish a roadmap on how we're going to address that. That is not finalized yet in any form, but I expect a component of that roadmap is going to be that some of our critical components will get rewritten into Rust or another memory-safe language.

[0:24:28] CH: When you say "pending legislation", is that a nod to some pending legislation that you actually know is on the horizon? Or just anticipating that it's going to happen at some point?

[0:24:38] SP: Oh yeah, no. There are two bills (sorry I don't have...)

[0:24:44] CH: It's all right, we'll find them and link them in the show notes afterward.

[0:24:48] SP: Yeah, I can hunt down the links. The one in the U.S. that's pending basically says that the Department of Defense is going to within 270 days of the bill passing (and it's a funding bill which means it will probably pass late this year - early next year) that the Department of Defense will establish guidelines around safety and security including memory safety for software products purchased by Department of Defense. The E.U. has a similar wording in a bill that's slowly winding its way through their channels. I don't have insight into when that will pass. The U.S. one will almost certainly pass here within a month or two.

[0:25:43] CH: Oh. Wow.

[0:25:44] SP: There's a long way between having a bill pass that says almost a year later they have to establish a plan for what they're going to do, right. So it's not hard legislation in any way. But I view this-- I can send you a link. There was a podcast I listened to recently on macOS folklore. [...] It's talking about how in the early '90s there was a somewhat similar round of legislation that went around around POSIX compliance. Basically the Department of Defense decided that in order to have portable software, every operating system that they purchased had to have POSIX compliance. And there was a roadmap put into place. That's why Apple pursued building their own UNIX which was A/UX and eventually partnered with IBM to do AIX. And Microsoft in the same timeframe had a big push to get POSIX compliance in Windows OS. The thinking was eventually in order to sell to the government your operating system it would require POSIX compliance. What actually happened, if you wanted to buy just traditional Macintosh operating system you would just say "well I require Photoshop or pick-your-application and there is no alternative that runs under UNIX so therefore I need an exception to buy macOS" and it was extra paperwork but it got signed off on. So really never materialized into hard restrictions on sales of non-POSIX-compliant OSes. I expect the safety legislation to take somewhat the same route, which is, there will be pressure to write more software in memory-safe languages. When you don't write software in memory-safe languages there is going to be more pressure for you to document what your process is to mitigate the risks. And this is initially all in the realm of government sales, although there is some discussion in both the E.U. legislation and on the U.S. side of extending this to a consumer safety issue. But there will be an escape hatch because you couldn't wave any kind of magic wand as a legislator and say "you can't sell software anymore if it's written in C++". The world would grind to a halt. So there will be an escape hatch, and there will be pressure. So as a company you have to look at how are you going to mitigate that risk going forward. And what's your plan going to be so that you can continue to sell products to the government. And how do you make sure that you're not opening up a competitive threat. If you've got a competitor that can say "well we're written entirely in Rust so we don't have to do the paperwork" that becomes a faster path. So you want to make sure that you're aware of those issues and that you've got a plan in place to mitigate them.

The legislation:

* https://www.congress.gov/bill/118th-congress/house-bill/2670

* https://digital-strategy.ec.europa.eu/en/library/cyber-resil...

c++ is with us for the near future, it needs an evolutionary path that provides a sane path forward

why not break with the past? anyone needing to compile c++11 can find the tools and still use them, they can live in the past as long as they like

just getting dependency/build management and integrated testing would be huge and really a small ask given what is happening in other tools

its crazy that you still can't make sane use of things like modules, even if you fully commit to "modern" c++

[1]: https://en.wikipedia.org/wiki/Unity_build

If you make big breaking changes, the community suffers - even if the changes are very well intentioned. Look at the long tail of Python 2 vs 3 issues. If it happens once it's not so bad, but the older the community and the greater the size of its existing ecosystem - the more that pain becomes. Rust, from what I've seen, understands this issue.