Lessons from Zig(vinniefalco.com)
vinniefalco.com
Lessons from Zig
https://www.vinniefalco.com/p/lessons-from-zig
27 comments
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.
Edit: Andrew confirmed that the HTTP client and server will stay in the standard library.
Regarding HTTP in Zig, it might be removed in 1.0, if I am reading this correctly. Though Zig std does have both an HTTP client and an HTTP server.
https://github.com/ziglang/zig/issues/910#issuecomment-39548...
Regarding HTTP in Zig, it might be removed in 1.0, if I am reading this correctly. Though Zig std does have both an HTTP client and an HTTP server.
https://github.com/ziglang/zig/issues/910#issuecomment-39548...
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.
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.
There are already several frozen versions of C++ and there are projects that stick to compiling using an older standard.
This is a fairly normal practice and is supported by the major compilers.
I don't see why C++ should stop seeing development.
This is a fairly normal practice and is supported by the major compilers.
I don't see why C++ should stop seeing development.
> There is a much simpler solution to the C++ language: just freeze it.
That would go against everything the language has stood for over the years: we have a problem, here is a solution
(... which creates twice the problems, but there's always next year!)
That would go against everything the language has stood for over the years: we have a problem, here is a solution
(... which creates twice the problems, but there's always next year!)
> just freeze it.
They did. It's called C++14.
> Fork it if you want or just create your own language.
They did. It's called C++17, etc.
They did. It's called C++14.
> Fork it if you want or just create your own language.
They did. It's called C++17, etc.
C++ instead needs language editions, legacy and modern. Let compilers implement a switch for which edition you're targeting. Legacy does not touch backwards incompatibly changes or language features. Modern cleans up everything.
I don't think that would be a silver bullet nor without drawbacks. It can be a rather bitter footgun when the same code can have different semantics in different editions or epochs. Automatic or semi-automatic conversion, as Rust has, helps it a bit, but not fully.
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.
> 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.
Bjarne just visited us recently. The vibe I got from him is that the language has escaped him and he does not agree with all the things that did or didn't make into the language. But I suppose he's getting to that age where he would have to release the reigns anyway.
> 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.
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.
Not to mention that Rust too had "let's have the minimalistic stdlib for now, let the community figure out the rest" approach and the results are somewhat mixed.
In what way? There was an stdx[1] crate that was basically extra stuff like regex, http client/server, json parsers but there was little desire to maintain it.
[1] https://github.com/brson/stdx?tab=readme-ov-file#stdx---the-...
[1] https://github.com/brson/stdx?tab=readme-ov-file#stdx---the-...
Edit: Andrew confirmed that the HTTP client and server will stay in the standard library.
Regarding HTTP in Zig std library, might some of the API not be removed in the future?
https://github.com/ziglang/zig/issues/910#issuecomment-39548...
Regarding HTTP in Zig std library, might some of the API not be removed in the future?
https://github.com/ziglang/zig/issues/910#issuecomment-39548...
That's from 2018. I think it's unlikely. Also zig's package manager needs a HTTP client.
I looked at Zig again recently as an alternative to C, but I wasn't too sure about the tone on the introduction page, thinking some points are exagerrated and some I disagree with.
It's also not that minimalistic when it includes a package manager.
I like C because it's a bare-bones language providing only the necessities and nothing more. It's independent from libraries and build environment. Let people who have experience in those things work on that. Remeber the do only one thing and do it well? I think the urge to still add extra features is the reason why there's no real successor to C.
I like C because it's a bare-bones language providing only the necessities and nothing more. It's independent from libraries and build environment. Let people who have experience in those things work on that. Remeber the do only one thing and do it well? I think the urge to still add extra features is the reason why there's no real successor to C.
> Every ABI concern constrains future evolution permanently
Why caring about ABI stability? It's easier just to link anything statically. Benefits of dynamic linking are negligible or even negative and thus it doesn't have any sense to have headache maintaining ABI stability. That's exactly what Rust does.
Why caring about ABI stability? It's easier just to link anything statically. Benefits of dynamic linking are negligible or even negative and thus it doesn't have any sense to have headache maintaining ABI stability. That's exactly what Rust does.
I think there are some smaller Rust ecosystems where they try to have some kind of ABI stability or dynamic linking. For instance, Bevy has some support for dynamic linking.
Edit:
Redox OS might be a better example, though its dynamic linking is for its Rust implementation of the C standard library.
https://www.redox-os.org/news/release-0.9.0/
> Relibc is also now key to our “stable ABI” strategy. The plan is for files to dynamically link against Relibc, which will provide a stable ABI for the dynamic linker. New POSIX functions will be added to Relibc, but none will be removed. That will leave us free to change the implementation of the services as Redox evolves, but still be able to run binaries compiled for older Redox versions.
Edit:
Redox OS might be a better example, though its dynamic linking is for its Rust implementation of the C standard library.
https://www.redox-os.org/news/release-0.9.0/
> Relibc is also now key to our “stable ABI” strategy. The plan is for files to dynamically link against Relibc, which will provide a stable ABI for the dynamic linker. New POSIX functions will be added to Relibc, but none will be removed. That will leave us free to change the implementation of the services as Redox evolves, but still be able to run binaries compiled for older Redox versions.
Almost by definition, you have ABI stability as long as all artifacts are compiled with the same version of the same toolchain on the same platform with all the same compiler flags. That's not enough to let you generally ship pre-compiled artifacts with the intent for users to dynamically link them, but it might be enough to let you leverage dynamic linking for hot-reloading within a single developer's workflow.
> The Zig language, created by Andrew Kelley, takes a deliberate position on standard library scope.
I'm missing the significance of this callout. Is Andrew Kelley synonymous with/well known as a representative of a particular approach to language or software design?
I'm missing the significance of this callout. Is Andrew Kelley synonymous with/well known as a representative of a particular approach to language or software design?
...yes? Does he need to create more than one language to take stance on library scope?
I meant that the name of the language creator is irrelevant to the point being made in the article, unless the name has some out of band meaning that the intended audience knows and I do not.
Turns out the article is AI slop, so makes sense.
Turns out the article is AI slop, so makes sense.
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...
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...
flagged for being slop
Sorry to bother you, but I couldn't find any news on this, only a comment you made back in 2018 on GitHub; do you know if the HTTP APIs in Zig's standard library are here to stay, or if some of them might be removed? Another commenter wrote that the HTTP client is used for Zig's package management, but there is also the HTTP server.
HTTP client and server stay for sure.
please stop posting stuff from a blog titled "my very best ai slop"
it's full of wrong assertions about zig
it's full of wrong assertions about zig