Full-time open source with Andrew Kelley(corecursive.com)
corecursive.com
Full-time open source with Andrew Kelley
https://corecursive.com/067-zig-with-andrew-kelley/
59 comments
I listened to this the other day. I usually don't listen to podcasts like this and when I do occasionally click on one I rarely follow through and finish the episode. I enjoyed this one and finished it -- though, I was already interested in the subject matter.
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?
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?
I've been listening through the podcast's episodes and find it very interesting! It hits all the right marks for me. It's well structured, the audio quality is good (better in more recent episodes), length is appropriate, solid pacing.
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.
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.
Thanks for listening and thanks for supporting me!
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.
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.
Thanks for the transcript! I'm not usually a fan of audio/video so I love that I can just read the interview.
How is it generated? Speech recognition? Much in the way of hand editing necessary?
How is it generated? Speech recognition? Much in the way of hand editing necessary?
I tried machine translation but it just isn't there for technical content. I use rev.com, which is a human transcription service. I supply them with a thesaurus of terms used and then proof read it and correct it myself after. The headings and jump points I add manually.
I have some feedback about the transcription. There are some places where you are transcribing a conversation with Andrew, and you're labeled as Adam. There are some other places where you are not having a conversation with Andrew, but are instead acting as a narrator to insert context or clarification. These are also labeled as Adam.
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.
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.
Thanks for reading. Interesting idea! I did have this thought myself at some point and went and checked on some other narrated podcasts and found they kept it all under one label, but I can see how that could be confusing. Maybe I'll try that for the next one.
> THE language to replace C.
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.
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 respect the hell out of Andrew and what he’s accomplished with Zig, but to an extent I think it’s counterproductive to be creating new languages that aren’t memory safe. What niche does Zig fit? As far as I can tell, it seems to be people who find Rust cumbersome, and don’t think it’s worth the benefits in memory safety.
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.
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.
I think Andrew would contend that it is memory safe, it just defines that safety in a different way than Rust:
> [...] 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.
> [...] 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.
> it just defines that safety in a different way than Rust
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?
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?
Can rust _gaurantee_ memory safety? A lot of the core features are built on-top of unsafe {} blocks after all. Zig has it's own memory safe features which will catch a lot of memory safe bugs compared to Vanilla C.
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.
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.
Rust proof is coming - https://www.eurekalert.org/news-releases/610682
The formal proof doesn’t exist yet but the language was designed from the ground up with memory safety as a key principle.
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.
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.
I think the horizontal vs vertical memory safety argument needs to be better marketed. Because right now Memory safety PL is quite literally trademarked by Rust in any discussions.
I don't find the horizontal vs vertical nomenclature very helpful. The chart here spelled it out for me very clearly.
https://scattered-thoughts.net/writing/how-safe-is-zig/
https://scattered-thoughts.net/writing/how-safe-is-zig/
In my (admittedly) very limited usage/understanding of Zig, this is a fairly accurate description of where the memory safety comes from.
now please translate it into non-marketing words, please.
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).
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).
The safety guarantees don't come for free. There are tradeoffs. That should be clear from the fact that Rust as a language is still changing, i.e. relaxing ownership rules and adding new mechanisms to the type system. If there were no problems, then there would be no language changes necessary.
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.
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.
This comment is a perfect example of what Andrew was talking about here:
> 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.
> 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.
Well, I feel pretty strongly about this issue as someone who cares about security. It is a question of ethics to me. I mean, saying Rust is unsafe because it has the unsafe block is like saying Haskell isn’t a pure language because it has IO. Yes, but it totally misses the point. The language is designed to minimize and constrain usage of unsafe features. And, outside of unsafe blocks, you know your code is safe. This is an important guarantee.
> outside of unsafe blocks, you know your code is safe
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.
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.
> Only for some common memory mistakes.
Yes, I’m talking about memory safety, because memory bugs cause most vulnerabilities.
Yes, I’m talking about memory safety, because memory bugs cause most vulnerabilities.
Morality and ethics seem odd to apply if a programming language should be developed, which seems to be the context Andrew was mentioning. Some use cases might apply (ex. medical devices).
I wonder if this type of debate came up when C++ was introduced amongst C developers.
I wonder if this type of debate came up when C++ was introduced amongst C developers.
> Rust is "Safe"
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.
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.
> Any Rust code that goes low level liberally uses unsafe{} blocks
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.
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.
> 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.
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.
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.
Why aren't you using Ada then? Serious question. Those of us that have been around a while notice all this safety rhetoric around rust and immediately think of Ada.
Ada is missing the borrowing/moving guarantees. Whenever I use dynamically allocated memory, I have to do manual memory management, with the 'unsafe' (it's called 'unchecked' deallocation for a reason) coming in then, and also even without dynamic allocation, the myriad problems coming with aliasing (pointers / 'access types'). You can handle the first one with scoped allocation ('controlled types') and the second one by 'being careful with pointers'...
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.
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.
There's two things going on here.
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.
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.
> even though its brand new and barely tested out in production
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"?
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"?
1) More time. Rust is what, 6ish years old now? And in those years its continued to evovle and grow.
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?
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?
All of this is still relative, what is "more"? is it four more years? Ten more years? Twenty? How much software is "more" software?
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.
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.
Something about your Ada post was rubbing me the wrong way, and I figured it out. I'm not trying to be negative or insulting or anything like that, and I'm not trying to make it personal since I think this observation is not limited to you but is endemic in software development, but I don't know a better way to phrase this.
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.
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.
Still dodging my questions ;)
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.
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.
If you want numbers, it's sadly more like Stewart's "I know it when I see it" comment. But I think we're also talking about reaching different bars.
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.
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.
> I work with a bunch of C folks who don't like C++ but love Rust
There are literally dozens of us!
There are literally dozens of us!
Ada has destructors and can limit pointer type to lifetimes of large memory pools, but as far as I know it doesn’t prevent use-after-free for single objects the way Rust does. Lots of Ada is embedded on small platforms where they statically allocate a fixed number of objects anyway.
"Lots of Ada is embedded on small platforms where they statically allocate a fixed number of objects anyway."
Which is what a lot of c code does too. And zig might too?
Which is what a lot of c code does too. And zig might too?
>Is it just because Ada syntax is unfamilar to todays programmers or is there something fundamentally unsound about Ada?
Every time I asked the same question the answer was syntax.
Every time I asked the same question the answer was syntax.
Which I think is the silliest thing in the programming world, what with all the * soup and all the undecipherable template gibberish, and the love for haskell, scala and erlang around here.
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
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
I'm reading a page about Zig from the official documentation and it says:
> 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/
> 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/
> First there is an official package manager for Windows (winget
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.
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.
I just want to mention that it was delightful working with you. I would definitely recommend anyone invited to come on your show to accept the offer. I've become a sponsor of the podcast and I invite others to join me :)
My only question is why nobody can seem to keep track of whether your name is Kelly or Kelley.
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?
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?
Some people who use C don't want a destructor like feature for performance reasons. They would prefer everything is cleaned up in some global context rather than each object in a chain of stack frames having to clean themselves up when an error somewhere buried deep in code.
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.
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.
I do all that in C++: substantial allocations, like ring buffers, are mmapped with a MAP_HUGETLB flag or on /dev/hugepages. And, I use a destructor to unmap them.
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.
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.
Because there is people that think defer is a good solution (which it isn't).
Coming from C, it's a bit better than nothing at all.
Compile with a C++ compiler, and suddenly you have a great deal more than nothing. For free.
Hey hey hey, GNU C has __attribute__((cleanup(fn)))!
His understanding of undefined behavior seems off. Undefined behavior does not imply that the program crashes. I agree with him though that this would be a nice feature.
> Andrew: In release fast mode, which is unsafe, you will get actual undefined behavior. So, you might crash or you might get overflow. You might go down to zero or you might run an unrelated function.
Are you perhaps confusing this with statements made about the debug and release safe build modes?
Are you perhaps confusing this with statements made about the debug and release safe build modes?
I misread another section. Thanks.
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.