Full-time open source with Andrew Kelley
corecursive.com
corecursive.com
Andrew shared the backstory behind why he created Zig, why he decided to leave his job to work on it full time and why he is confident he can build THE language to replace C.
Let me know what you think of the episode.
The topic of funding Zig came up during the podcast. So, Andrew, if you come across this post: can you have zig foundation accept cryptocoin donations? Not sure how hard that is to do but if you toss up an bitcoin/monero/etc address I will donate some.
Also, Andrew - you should consider giving a talk at an upcoming US or Euro LLVM conference. Even if it's just a lightning talk, it would be valuable for the community to hear about a non-clang compiler (or a super-clang compiler). I think US Bay Area will have one in ~October 2021?
In fact, I just became a "Junior Engineer" supporter on Patreon. Keep up the great work. Hopefully one day I'll have done something worth talking about on your show.
Yeah, the further you go back into the back catalog the more you are listening to my learning-to-podcast phase. Hopefully they aren't too bad... I am a slow but persistent learner.
How is it generated? Speech recognition? Much in the way of hand editing necessary?
It becomes clear which are which from context after a couple sentences, but it's a little jarring. It would be nice if the second kind were labeled Narration or Voiceover or something.
One thing I think people keep getting hung up on is this idea of there being a pure replacement for C. Consider the fact that C has already been displaced in many areas. Consider C++ as the first big one, it didn’t add memory safety over C, but for many it was more ergonomic and easier to reuse code across different systems (the STL is a big advancement here). That took a huge number of users away from C. Then you have Java that added memory safety and that pulled away even more folks.
What’s been left is a particular niche for C that is being being targeted by new features in C++, Rust, and possibly Zig.
The question really becomes what niches will each of these languages carve out from the existing C usage? Why would users adopt one over the other? There’s plenty of space for all of these languages to thrive, what I don’t think we’ll ever see is “the one true C replacement”, first because C itself will continue for a long time, but also because each of the existing C replacement languages are already are doing well. Will Zig capture the last C uses? I doubt it, but that’s nothing against Zig, it’s just the plain truth about how the computing world works. See the continued devotion to FORTRAN as an example.
I don’t personally understand why I would choose Zig over Rust. I think it’s long past time we closed the book on unsafe languages as a profession.
> Andrew: It’s funny how it just kind of changes course as the language gets taken more and more seriously. And now, all the comments are even starting to shift to kind of like the philosophy of memory safety and whether Zig is immoral.
I'd suggest you go listen to the podcast or at least read the "Zig Is Immoral and Unsafe" section of the transcript as well as the following one.
Only for some common memory mistakes. And ony if the compiler doesn't have a bug. This sounds like a nitpic, but let's be clear that Rust is not "safe" as if it was some global quality that covered all of the language.
Yes, I’m talking about memory safety, because memory bugs cause most vulnerabilities.
I wonder if this type of debate came up when C++ was introduced amongst C developers.
I'm tired of this meme. It's not true. Any Rust code that goes low level liberally uses unsafe{} blocks. There are also debugging and test modes in Zig that will sniff out leaks for you.
This isn't an accurate statement. Liberal use of unsafe is not common or best practice in Rust. My favorite educational series that shows how little unsafe is required to work in low-level spaces is Phil Opperman's, "Writing an OS in Rust": https://os.phil-opp.com/
That being said, I don't think most people use "Rust is safe" in an particular way that's different from saying Java is safe. Rust in many ways offers similar (and stronger) safety guarantees than Java (one of the safest langauges to date). Is Java safe? We all know that bugs can be created in every language, it's really the different classes of bugs that each language offers some defense against that sets them apart from each other.
> [...] So, the way I would describe it is that Rust has a kind of like vertical memory safety approach where on the top, it’s safe. And then, on the bottom, you hit the unsafe block, and it’s not safe, right? [...] Zig is more of I would say horizontal safety approach. So, there’s no unsafe blocks where it’s all contained in, but each feature of the language models safety in a different way. So, as an example, the pointer type in Zig actually can represent alignment. In Rust, if you want to mess with pointer alignment, you have to use an unsafe block and you’ve turned off safety for alignment. In Zig, you have pointer alignment in the type. So, it’s actually completely safe, and in Rust it’s not.
And of course the reason it doesn't use anything like a borrow checker:
> [...] Zig also wants to be optimal and optimal means you want to fully use the hardware that you have. So, my hardware lets me use virtual memory and it lets me use intrusive data structures. And it lets me write code in a certain way that’s the most efficient way to use all the CPU and all the memory. So, if my language doesn’t let me use all my hardware features, it’s not optimal.
I can't help but agree. We should strive to allow optimal code to work, and we should also do our best to prevent the programmer from doing unsafe things unless they are explicit about what they're doing. Are programmers sometimes going to do the wrong thing anyway? Yes, of course. The same way that someone can get frustrated and wrap their code in unsafe, they can use @ptrToInt without thinking it through.
He says Rust is on the top safe (vertical), but not at the bottom, because the bottom isn't fully proven.
He also says Zig is horizontally safe -> there is unsafe code on any layer, but also safe code. Also, it doesn't seem like there is something like "unsafe" for Zig. How can you say anything is safe then?
So Zig has one feature that makes it harder (impossible?) to write broken code than with Rust in UNSAFE code. How does this bring anything to the table besides eloquently dismiss Rusts safety guarantees? E.g. allowing to state libraries to only have safe code in them>
Afaik Rust let's you fully use the HW as well (and as much as possible within safe code).
Examples of people writing Rust code and hitting problems of expressiveness and performance:
My experience crafting an interpreter with Rust https://ceronman.com/2021/07/22/my-experience-crafting-an-in... (I'd be interested in experiences from others who have implemented a GC'd language runtime in Rust)
Also see Why I rewrote my Rust keyboard firmware in Zig: consistency, mastery, and fun https://news.ycombinator.com/item?id=26374268
You can argue about how much the tradeoffs matter, which is heavily domain specific. But you can't argue that the tradeoffs don't exist.
Memory safety is already well-defined, though. It means that you can’t write code that mishandles memory in a dangerous way. In Rust, code outside of unsafe blocks is guaranteed to have this property. As far as I know, no such feature exists in Zig. So Zig is starting from a point where it can’t guarantee the safety of any nontrivial program, right?
asan/valgrind/etc. will also pick up a lot of memory bugs for C and C++.
Outside of maybe formal proofs in languages that only exist in research labs there isn't anything that is _provably safe_. This discussion and worship of languages which advertsie themselves as "memory safe" seems a bit zealous and often not useful. I do prefer rust over C++, mainly due to better defaults (immutable variables) and stripping out the object orientated paradigm which just gets abused after 25 years of "enterprise design patterns".
After a few years, rust is going to have just as much dodgy software as much established languages. You can see it now with people trying to write in rust as pythonic as possible and littering the place with .unwrap(). That's not a sign of quality/stable software, even if it is written in a 'memory safe' language.
I should note, Rust is not the only safe language. Python is safe, as are most modern languages with garbage collection. Most code can afford a garbage collector and should probably use one. My day job is real-time network + web services with Elixir/Erlang, and it works great. Rust gets brought up in contrast to Zig because it brings the benefits of those higher-level languages down to the metal.
1) We need to move to safer languages
2) Rust is the way, the truth, and the light of safe languages even though its brand new and barely tested out in production.
The first is a defensible position, the second is why people can have a reflexively negative reaction to anybody pushing Rust.
What would get you to change your mind on this? Like, Rust has been heavily tested in serious production for years at this point. 1.0 was six years ago. Where is the bar? How much usage counts? What is no longer "brand new"?
2) More software. Particularly older software, watching Rust code bases evolve over time.
3) Most topical to this thread, watching how other approaches to safer programming shake out. Its hard to have confidence in a solution to a generic problem when you can only evaluate a single solution. For example I find Zig to be a potentially much better solution since it has a far smaller surface area.
Somebody on HN said: Rust is what you get when C++ programmers try and fix memory safety, Zig is what you get when a C programmer tries to do it, and based on the Rust and Zig code I've seen this really rings true.
Rust is on a great track, but it seems way way too early to declare victory and start claiming that everybody exploring the same safe programming space is functioning as an unethical professional.
EDIT: As an aside I enjoyed your blog post on learning Ada, stream of consciousness and all. You ask what the bar is, the bar is Ada. Decades in the market, formal standard, multiple implementations. I wish somebody would dig into why we need Rust, Zig, or something else when Ada exists. Is it just because Ada syntax is unfamilar to todays programmers or is there something fundamentally unsound about Ada?
I always find that C++ vs C comparison to be amusing, given I work with a bunch of C folks who don't like C++ but love Rust... not everyone likes languages for the same reasons. There's a grain of truth in sayings like this, but it's not the whole picture.
(I am also not saying Rust is the only thing, or that Rust should "win" over Zig, whatever that means, or anything more broadly. My comment is purely about how Rust is too "new" and "untested", in a vacuum.)
Thanks for the comment about the blog post. It was a fun one to write.
There are literally dozens of us!
The fact that the man who literally wrote the book on what is supposed to be the future of memory safe software engineering is not an expert on the past/current state of the art is deeply concerning. Rust is a large collaborative project that has explicitly avoided having a BDFL, and maybe there are others involved with deeper expertise in the existing state of the art in memory safe languages. Maybe the problem Rust is trying to solve is fundamentally new, but I'm skeptical of that.
For all the projects out there that casually look as if they are reinventing the wheel, I wish part of their communication would be to frame themselves in terms of what came before and explain why they are different or why the world has changed or why what came before got something crucial wrong.
I think there's a few ways to tease apart what you're saying here. First of all, I think that, even if we take this at face value:
> The fact that the man who literally wrote the book on what is supposed to be the future of memory safe software engineering is not an expert on the past/current state of the art is deeply concerning.
Not having tons of practical experience with one language is not the same as "not an expert on the past/current state of the art." I am a student of programming language history, I just hadn't spent a ton of time with Ada specifically. There are a lot of programming languages out there, and unless that is your sole focus, you'll miss some.
That being said, Graydon is that kind of person, and as far as I can tell, knows everything about every language. While he hasn't been involved in Rust for a while, and Rust looked very different back when he started it, that knowledge was expressly there.
> I wish part of their communication would be to frame themselves in terms of what came before and explain why they are different
I mean, we have. "memory safety without garbage collection" was our slogan for a very long time. While Ada does have many mitigations here, fundamentally, heap allocation is unchecked, and can cause double-frees or use after frees. SPARK does give you memory saftey, but does this by being an aggressive subset that, as far as I know, doesn't let you use dynamic allocation or pointers at all.
But, moreover, it is true that we do not often compare ourselves to other languages directly. This is more of a cultural issue than anything else. Programming languages are very tribal, and even well-meaning comparisons can come across as very aggressive. We don't discourage people making these kinds of comparisons themselves, but as a project, we prefer to talk about what Rust can do, rather than about what other languages can't do. These social reasons blend into technical reasons; programming language cultures that become obsessed with talking about why they're better than others often miss out on the good parts of those other languages. In the end, I think we get better cross-pollination with other languages by not explicitly comparing and contrasting with them in our public-facing marketing. Comparisons, in, say, an RFC are fantastic. These often do get made. But that's internal facing communication, not external.
My comment was in reaction to jolux's assertion that those exploring other solutions to safety are acting in an irresponsible, unprofessional, and unethical manner. I've been digging into Zig and Ada on the side for personal projects, and thus spending time on their respective reddits and forums. And dealing with the Rust zealots trolling these communities is verging on intolerable. Like you point out, "Why Reddit is like this" is a whole other issue, but there's a reason people are reflexively defensive. This issue comes up in the content of the podcast under discussion as well. So my bar in this case was the point where we should converge on some single solution, which I don't think is representative of Rust's official stance, but it is an issue with Rust's larger informal community. Or maybe it's just a problem with Reddit and HN.
The bar I suspect you are talking about is more along the lines of should people be using Rust in production, and clearly Rust has reached that point. People with far more at stake than I have are successfully using Rust in production, and that is a necessary step forward to things like a formal standard and multiple implementations.
Your point around the outward facing marketing is interesting. It's a shame and I don't think it speaks well of us as in industry that we tend to be so tribal around discussing the deficiency and comparisons of our tools, but I can see where the idea to focus on what your own project can do is more effective messaging. Its interesting how that kind of ties back to this post https://steveklabnik.com/writing/rust-is-more-than-safety in which you dig into some of the issues marketing Rust.
FWIW you now have me wondering the same question of why does Zig deserve to exist when Ada exists as well and start to see if I can put together a decent comparison to understand the spaces they all function in.
Every time I asked the same question the answer was syntax.
I wonder if we should have gone the typescript way to make the language less readable, as joked about in this post: https://blog.adacore.com/a-modern-syntax-for-ada
Which is what a lot of c code does too. And zig might too?
You might be interested in looking at the CVE list for Rust programs before you conclude that safety (programming as a safe space?) is the highest principle we should aspire to. http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=Rust
From a first principles basis: Time will probably reveal that languages that give us accurate insights into what the hardware is doing, and thus give us better control of hardware, will yield higher programmer productivity and software quality, in the long run.
With the borrow checker those two kinds of problems mostly evaporate, or at least are statically handled by a harsh compiler. There's been some great progress (mostly from the amazing Claire Dross iirc) bringing ownership concepts to SPARK and I really hope the Ada community can focus on those concepts for a serious, ambitious next revision, a bit more dense than all the sugar we've seen for now.
Ada has lots of safety features, and to be honest, in real-time embedded software, dynamic allocation/deallocation is a big no-no, and aliasing/pointers tend to be avoided whenever one can. I sure rant a lot at review when I see some new code with pointers instead of copying, if performance is not an issue.
> For C/C++ projects, having dependencies can be fatal, especially on Windows, where there is no package manager.
Which is doubly wrong. First there is an official package manager for Windows (winget), but there is also vcpkg, a package manager for C and C++ libraries, also developed by Microsoft.
Otherwise the language seems to have good design, so it's bit regretful to use strawman argument about package managers.
PS: the doc page is https://ziglang.org/learn/why_zig_rust_d_cpp/
Just calling half finished product "official" doesn't really mean much. On my linux server from operating system to thousands of utilities are packaged in native format and available via package manager like yum. On Windows forget dependency management etc not even basic installation of one percent of ecosystem is covered by package manger.
Even in the podcast transcript it is both.
Actually that's not true, I have another question. The single greatest strength of both C++ and Rust is the destructor: it makes them viable. Its lack is all that keeps me from thinking Zig is something I might want to use. Why doesn't Zig have an analog of the destructor / Drop trait?
I don't have any benchmarks because I don't work on low level code all day, but apparently it can be slow enough that it puts people off using destructors. This isn't a joke.
In fact, some people will not use new/delete. Some people will also go further and not even use malloc but prefer to use the syscalls for getting a block of memory directly from the operating system and managing it completely themselves. These are usually the people who don't use the standard library/libc.
Suggesting destructors slow down execution really is a joke. The joke is on people who believe it. People will grasp at any straw to avoid need to learn anything new.
Are you perhaps confusing this with statements made about the debug and release safe build modes?