> code from Google.

I spilled my coffee, I was just talking the other day to some coworkers how I don't trust google open source. Sure they open their code but they don't give a damn about contributions or making it easy for you to use the projects. I feel a lot of this sentiment extends to GCP as well.

So many google projects are better than your average community one, but they never gain traction outside of google because it is just too damn hard to use them outside of google infra.

The only Google project that seems to evade this rule that I know of is Go.

The issue with Microsoft until recently, has been the power of WinDev, which are the ones responsible for anything C++ on Microsoft dungeons.

Hence the failure of Longhorn, or any attempt coming out from Microsoft Research.

Ironically, given your Sun remark, Microsoft is back into the Java game, having their own distribution of OpenJDK, and Java is usually the only ecosystem that has day one parity with anything Azure puts out as .NET SDK.

> 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.

Well, you may be celebrating a bit prematurely then. Google still has a ton of C++ and they haven't stopped writing it. It's going to take ~forever until Google has left the C++ ecosystem. What did happen was that Google majorly scaled down their efforts in the committee.

When it comes to the current schism on how to improve the safety of C++ there are largely two factions:

* The Bjarne/Herb [1] side that focuses on minimal changes to the code. The idea here is to add different profiles to the language and then [draw the rest of the fucking owl]. The big issue here is that it's entirely unclear on how they will achieve temporal and spatial memory safety.

* The other side is represented by Sean Baxter and his work on Safe C++. This is basically a whole-sale adoption of Rust's semantics. The big issue here is that it's effectively introducing a new language that isn't C++.

Google decided to pursue Carbon and isn't a major playing in either of the above efforts. Last time I checked, that language is not not meant to be memory safe.

[1] https://github.com/BjarneStroustrup/profiles [2] https://safecpp.org/draft.html

    > riddled with state machines

I think the article is pretty interesting. There are so many more interesting takes than just another boring Hacker News moan about Google.

Google has such proficient programmers that they had to invent a language for dummies (Go) for them not to get lost.

The farther they step from languages for professionals, the better!

Thank you for this. C++ should NOT try to be Rust. I find modern C++ really nice to program in, for the work I'm doing - 3D graphics. The combination of very powerful abstractions and excellent performance is what I'm looking for. I'm more than willing to endure percived lack of safety in the language.

C++ has lifetime rules just like Rust. They're simply implicit in the code and not enforced by the compiler. Do you prefer the uncertainty of silent miscompilations and undefined behavior to upfront compiler errors?

You're already using a language with a strong type system, so it's confusing to me why you would choose to draw the line here.

While programming in Rust, I've never thought to myself, "man, this would be so much easier to express in C++". I've plenty of times thought the reverse while programming in C++ though.

Edit: except when interfacing with C APIs.

On the contrary, why would I not want these things in C++ if I'm developing every project with -fsanitize=address,undefined to catch these types of errors anyway?

What I don't understand is why you demand that C++ evolution be halted in a clearly suboptimal position so you don't need to change your processes. Just use the version of C++ that meets your needs, you clearly don't want nor need new developments. You are fine with being locked into bad designs for hash maps and unique ptr due to the (newly invented, in 2011/13) ABI stability being made inviolable, you clearly need no new developments in usability and security.

So why not be honest and just use C++01, or 11, or whatever it is that works for you, and let the rest of the ecosystem actually evolve and keep the language we invested so much effort into as a viable alternative? There's zero benefit, except to MS who want to sell this year's Visual Studio to all the companies with 80's-era C++...

Ok. Please, just use your current C++ standard. But we will go to use the new one with all features we want to use.

But why say so under a pseudonym and avoid clarifying what products the process is for? Even if open source and not productized surely the interest goes simply beyond the the US presidents executive order regarding memory safety.

I don't disagree with the implication that order relies on oversimplification and misunderstanding of the ask but surely it and Rust do not mean as a theme C++ standards must not take anything from it no?

The parts of the government that think everything should be written in a memory-safe language (like Rust) are the same parts that already write everything in Java. Most of the high-end systems work is in C++, and that is the type of software where lifetimes and ownership are frequently unknowable at compile-time, obviating Rust's main selling point.

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.

> And not just that they exist, but that they are specified per module

Nitpick: editions are specified per crate, not per module.

---

Also note that editions allow to make mostly syntactic changes (add/remove syntax or change the meaning of existing ones), however it is greatly limited in what can be changed in the standard library because ultimately that is a crate dependency shared by all other crates.

There was a similar proposal for C++, using rust’s original names: epochs. It stalled out.

Many of my customers are in an industry with a huge C++ code base and it's all under active development. Safety certification requirements are onerous and lead-times for development are long: many are now experimenting with C++17 and C++20 is on the long-term horizon but not yet a requirement. Because of the safety certification requirements and the fact that the expected lifecycle of the software is the order of decades after their products have been released, changing any lines of their code for any reason is always risky. Lives can be at stake.

But this is a multi-billion-dollar industry. If you're working on scripting a little browser "app" for a phone things may be different.

> Changing 1% of code on top of that is probably not really that much compared

Quite a few companies have millions and millions of lines of code. Changing 1% of it would mean changing more than 10K lines of code, perhaps even more than 100K. In much bigger code bases, where changing anything has a risk of breaking something — not just because you might make a mistake, but because your program is full of Undefined Behaviour, and changing anything might manifest latent bugs.

Given that, I'm not surprised people say that Sutter quote with a straight face.

People just don't make mass changes to existing working code. Mostly they cannot. Even if the tooling was available, which it's not, it's also about reeducating their developers, who don't want to or can't change. Plus it'd have to be recertified. It's all cost with no benefit.

Except, allegedly, at Google. But is there any evidence they actually do this, eg. in public code bases? Or is it just hype?

Could be selection bias. Companies (or departments within companies) who are still actively developing their C++ code probably tend to hire more developers and consultants than companies who are doing minimal maintenance on their code base, and that might correlate well with the “two factions of C++” discussed here.

“Our code is an asset” ⇒ code kept up-to-date

“Our code is a burden, but we need it” ⇒ change averse

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.

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?

When you put it this way, personas might be a better term than factions.

The worst part is when you want to bring along people that are not as much of a wizard as you are. I've been prototyping some multiplayer, online video game with MMO-like sharding for a while now, mostly the backend and core stuff for the project and wanted to get two of my friends on the project to develop the gameplay logic which is largely done through a dynamic scripting language, but some features (that, say, I did not foresee needed yet), require source changes to expose the APIs to the scripting language, now, these guys are capable of doing these changes but the onboarding process for a single potential co-developer is such a pain, I basically have to explain to them how to download a compiler, a package manager like vcpkg (which wasn't even that much usable for these types of things pre-versioning, and is still not working properly - i.e. trying to pin LuaJIT version to 2.0.5 for VM bytecode compatibility will attempt to build LuaJIT with cl.exe on Linux), a build system like CMake, and so on, then guide them through all the steps to get the compiler, the build system, and the libraries working, and then hope that in the end they will actually work and not force you to spend an entire day over a remote desktop software trying to get them to become productive.

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.

Keyword is "sane". You can probably count all "sane greenfield C++ startups" on one hand.

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.

I think C++ is a living proof that not having a standard tooling around the language makes the language a complete pain in the ass to use, with any other language that does standard package managing/tooling out of the box, I can just pin the versions, commit a file to the repository, and on any computer that I'm working on I just issue a single command and everything is handled for me; meanwhile one of the C++ projects I've been working on, it turned out that I cannot build it on my server because one of the libraries I'm using only worked with clang17 which my desktop OS provides but the Debian I'm using on my server is shipping with clang16, and the library was not compatible with the earlier version of some C++ implementation, meanwhile Arch on my desktop updated to clang18, which also broke the library in some fashion, so now I'm sitting here with two systems, one where I want to deploy my software, and one where I want to develop the software, both of which are completely defunct and unable to build my project anymore; now I have to figure out how to build the specific version of clang on both systems and ensure I override a bunch of environment variables when configuring the builds on both of these systems, and then do the same on every new computer I'm developing/deploying on - with a proper tool I could just tell the project file to "use this compiler with this version with this standard" and things would just work. Some people will tell you "yeah bro just use docker with this and that and you will have a reproducible build system everywhere", but the thing is - I do not want to learn a completely unrelated tool and spend hours writing some scripts just to be able to continue working on my project when in any other programming language (like Go, Rust, JS), I can just install the runtime, clone the repo, run a command, and everything is handled for me seamlessly like it should be in 2024.

Specifications for package interchange are absolutely essential, which is distinct from language endorsed package managers.

Python doesn't have a language package manager, you're free to use pip or poetry or uv or whatever, but it does have PEP 517/518, which allow all Python package managers to interact with a common package ecosystem which encompasses polyglot codebases.

C++ is only starting to address this problem with efforts like CPS. We have a plethora of packaging formats, Debian, pkg-config, conan, CMake configs, but they cannot speak fluently to one another so the package ecosystem is fractured, presenting an immense obstacle to any integration effort.

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?

But like…why?

Let’s say we make a “thing” which contains packages for all participating languages.

98% of the time, aren’t users just going to go “filter down to my language” and just continue what they’re doing, except with a somewhat worse overall experience, depending on whatever the “lowest common denominator” API + semantics we use for this shared package management solution.

Multi-language build systems already exist, which happily serve the needs to those projects which find themselves needing cross-language (+distributed) builds. Could there be some easier versions of these? Sure, but I don’t feel like “throw everyone in the same big box” is the solution here.

This sets up an untenable N*M explosion:

Will the GhostBSD maintainers pin the right version of Haskell's aeson package?

Will the Fedora Asahi devs stay on top of the latest Ocaml TLS developments?

Will MS package PureScript's code for DOM manipulation?

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.

> package management belongs to the os

It clearly doesn't except if you're a fan of dll hell and outdated packages.

Disagree completely. OS package managers are one of the biggest sources of problems.

Basically, once you have an OS level package manager, you have issues of versioning and ABI. You have people writing to the lowest common denominator - see for example being limited to the compiler and libraries available on an old Red Hat version. This need to maintain ABI compatibility has been one of the hugest issues with evolving C++.

The OS package manager ends up being a Procrustean bed forcing everything into its mold whether or not it actually fits.

Also, this doesn't even have the issue of multiple operating systems and even distros which have different package managers.

Rust and Go having their own package managers has helped greatly with real world usage and evolution.

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.

Honestly I don’t know why more languages don’t just adopt e.g. npm, maven or NuGet. They’re largely language independent at the binary level anyway.

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.

Weird, it works for me.

I'm stoked to hear they're on C++17 now.

When I contributed to LibreOffice (GSoC 2012) they were still on C++03 !