I know more about Zig than C++ at this point, but it's hard to read the article seriously, if it starts with such mistakes. Zig does in fact have an HTTP client in the standard library, there is a tar reader, and realpath hasn't been removed, it still exists even in the std.Io namespace.

> The Zig programming language maintains an intentionally small standard library.

Zig's standard library is not that small to be honest. It has lots of useful tools that do not exist in other languages. The compiler uses the std.

> HTTP clients, for example, are considered inappropriate for a general-purpose systems language’s standard library.

The std has both HTTP client, server, TLS and in development branch even a DNS resolver.

> C++ cannot replicate Zig’s approach exactly—ABI stability and decades of deployed code make removal far more complex.

Wild to hear C++ and ABI stability in same sentence.

Though the article seems LLM generated and even website title is "My Very Best AI Slop", I'm not sure what to expect or why this is even on HN front page.

There is a much simpler solution to the C++ language: just freeze it.

Fork it if you want or just create your own language. This is what zig creator did.

The idea is that C++ can’t move because of its own weight. Too much history, too much responsibility.

Just freeze it, let new languages create new ways.

It’s not that software written in it will become unmantainable. A frozen, feature complete language can still work. Libraries can implement new protocols.

Leave the name, do something new! Fork it, call it nib, or peeb or zag or even ziggy. Create a new language, call it go, bo, or just pi.

Given enough time Zig will become what C++ is today: its creator long gone, its responsibilities too much, its backward compatibility a weight too heavy.

FWIW, and errors aside, I think I agree with the general sentiment. Things added to the C++ library ossify. The ABI concerns, and the general unwillingness to do anything about it, is a big reason why Google largely exited the C++ standard business.

But the conspiracy brained part of me can't help to think that part of this is sour grapes. Vinnie contributed a lot to the failed proposal to add networking (loosely based on ASIO) to the C++ standard. That proposal eventually lost out to the sender/receiver library[0] which is getting added in C++26. That still doesn't have actual networking, but lays the groundwork.

It remains to be seen how well sender/receiver turns out. Given ranges (another Niebler addition), I'm not super optimistic.

[0] https://en.cppreference.com/w/cpp/experimental/execution.htm...

In comparison to c++ everything is minimal. The Zig std lib doesn't seem that minimal to me. The package manager makes it easy to add dependencies, but whether that's even a good thing is controversial. std::regex might suck, but the maintainer won't disappear overnight leaving you to find a new regex library.

> Raise the Bar for Inclusion

The bar for inclusion in c++ is more political than it is technical. You have to write a paper that outlines all the details of your proposal, then go to some meeting, defend your paper and then the committee votes on it. Unless you're special you're required to have a reference implementation. If the bar for c++ inclusion was technical, we wouldn't have gotten the response we did from Sutter regarding Baxter's safe c++ proposal. The bar for inclusion in Zig is whether Andrew likes it or not, which is fine, but it isn't possible for c++ to revert to that model.