hpr-knowledge-base/hpr_transcripts/hpr3559.txt

Episode: 3559
Title: HPR3559: Linux Inlaws S01E52: The Zig Project
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr3559/hpr3559.mp3
Transcribed: 2025-10-25 01:26:28

---

This is Hacker Public Radio Episode 3559 for the first time at 24th of March 2022.
Today's show is entitled, Linux in-laws S01252, the ZIG project and its part of the series,
Linux in-laws, it is hosted by Monochrome, and it's about 69 minutes long, and carries
an explicit flag. The summary is an interview with LORIS TROOXID game.
This is Linux in-laws, a podcast on topics around free and open-source software, any associated
contraband, communism, the revolution in general, and whatever else, fans is critical. Please
note that this and other episodes may contain strong language, offensive humor, and other certainly
not politically correct language. You have been warned. Our parents insisted on this disclaimer.
Happy mom? Thus the content is not suitable for consumption in the workplace, especially when
played back on a speaker in an open-plan office or similar environments. Any miners under the age
of 35, or any pets including fluffy little killer bunnies, your trusted guide dog, unless on speed,
and Q2T Rexys or other associated dinosaurs. Welcome to Linux in-laws season one episode 52.
Martin, how are things? Yeah, I think so. Good. How are you? And more importantly, that was our guest.
Can't complain Martin, can't complain, but before we go into our guest, how is this situation shaping
up at the UK? I understand that Lizzie hasn't stepped down yet? No, she won't anyway.
This is comes with a job right. I see. To resign. So you can't resign. You simply don't know
whatever. I see. Okay. Unlike her name, Merkel, she resigned. Yeah, she resigned. That's
unofficial. Yeah, she's going back into physics. There's an episode of 2016. No, no, of next
government negotiations happen now. About 12. If you want to know, by the way, people,
if you want to know about the future of Mrs. Merkel, as in the external transfer, there's an
episode of the dark side last year that gives a little bit of a clue at what's going to happen.
And more specifically, the episode of the Halloween episode of last year. But this is not
about the past, but rather about the future. So Martin, why don't you welcome all guests?
Yes. Tonight we have a special guest who is someone we know from a few years ago.
The past. Yes. Yes. Yes. Yes. Well, a bit of recent past. Let's put it that way.
He's heavily involved with a programming language. Yes.
Comes to tell us all about tonight. Yeah, that was the point in time.
I think even before you defected, right? I think Laura's defected first. He did. Sorry,
I wouldn't. I wouldn't. I wouldn't. I wouldn't. I wouldn't use the term defected now,
but just for the why don't you introduce yourself and all results will be resolved very soon.
Hello, guys. Um, well, uh, wait, Martin, you defected?
Yes. Yes. I left. That's a straight. It's not an army. There's no defection possible.
I guess he's run by, yeah, let's not go into the details of who's run by.
Laura, sorry, sorry. Maybe. Before we drift into the internals, into the internals right away,
why don't you introduce yourself? And then I'm going to, I'm going to set on, I'm going to
set some of that on all the defections that happened since you left. Oh, okay. Yeah. Let me
well, okay. So hello, everybody. I'm Laurie Scrawl. And I'm currently with PEOPLE Community
at the zix of a foundation. And, uh, well, we were saying that we were talking about the
faction a moment ago. So I joined the zix of a foundation after leaving red slabs where I was a
developer advocate. And I don't know, I guess I put my marketing skills that I gained at red slabs,
at use now. I mean, I'm putting them at use now at the zix of a foundation. Yeah, this is,
and this is how we all met. Martin, myself and Laura's, of course, were working at red slabs
and we also called red slabs. Uh, Martin has defected and he has defected since again. I'm still
with redis as it's not called these days, but this, but this episode is not about redis or, or,
or VMware or bright light, whatever it was called Martin, but rather about the zix programming language
and the zix foundation. So, Laura, further ado, why don't you tell us a little bit about the
foundation as a programming language as such? Sure. Um, and also, I, I guess I need to do a good job
right to convince you guys because I, I listened to your last podcast. You did it. I did it. Martin,
that's a listener. Excellent. Sorry. Good. You guys didn't sound super stoked by ZIG when you were
discussing it the last night episode. Well, we don't know anything about it. So what do you
do? Indeed, we don't. Otherwise, it's a problem language. Yes. So, okay, ZIG is a programming language.
We on, on the website, we have the stagline where we say that it's a general purpose programming
language. Um, you know what? I'm bringing up, I'm going to bring it up and read it, uh, directly.
That doesn't sound glorious. But, uh, here's the thing. I can justify each word, uh, which I think it's
more interesting and concise. So, ZIG is a general purpose programming language and to change for
maintaining robust, optimal and reusable software. So, the idea behind ZIG being a general purpose
programming language is that it's a programming language that doesn't have like a runtime,
and it doesn't have dependencies on things that you can find on like full blown
personal computers, but then maybe you wouldn't find in embedded devices. So, uh, for example,
you can't really program a tiny embedded devices with Python without weird compromises in ZIG.
You don't have that. It's a tool chain because you can use ZIG to compile CNC plus plus code
and cross compile it. So, like Linux windows are 2x86. And that, that it's known, that is
non-trivial. It's weird, but CNC plus plus have always been weirdly hard to cross compile.
And finally, the robust optimal and reusable is just how we like to describe
how an ideal Z program should look like because ZIG puts a lot of emphasis in handling errors.
It doesn't have exceptions, for example. So, whenever online can error out, you know it because
error is part of the return time and stuff like this. Also, we as a language ZIG is very explicit.
There is no hidden control flow, no macros, and like the general ethos of the language is to be
easier to read than it is to write. Sometimes you write a bit more, but the idea is that who comes
in and reads should not be confused by your code, normally.
It's like a modern C slash C plus plus slash rust container, if you will. It's in the same
ballpark, roughly speaking. And how does it come about? I guess, did someone just decide on
they were going to invent a new program language or was there something specific that I thought
or this is not good in C or C plus plus? So, I think that the story is, okay, do you want to know
the story that I like to tell people or do you want to know the real story?
The truth and the whole truth.
Okay, so I'll start with the one that I like to tell. The one that I like to tell is that
the creator of the language is Andrew Kelly, who at the time was working at OKCupid.
And apparently, OKCupid is a giant C plus plus code base.
Even though it's a website, at least that's the part that everybody knows about, right?
But apparently it's implemented in C plus plus. So, the story that I like to tell is that
Andrew, when they was put in charge of a messy C plus plus code base, and he told him, well,
you need to maintain this. And he did the only rational thing, like the shortest path to maintain
a C plus plus to maintaining a C plus plus code base, it's doing that in your language and
rewrite it in that. That's what I like to tell. But the reality is that I believe that Andrew
has always been interested in audio processing stuff. So, like, making digital music, right?
And if you want to do tooling the works with sound, it needs to be very efficient. You cannot
have like garbage collection poses, stuff like this. And so, he looked at a few languages,
and he wasn't happy with any that he tried. And so, he ended up basically working on C.
So, this is the official version. What's the unofficial one?
Well, no, the second one about how the stuff is the official version.
Ah, the version is to tell is the OKCupid one, the one where he had to work on a C plus plus
code base, but that one is not true. OK, so no facilities involved, no money changing, and that's
the sort of thing. Not yet. OK, I fully stosure, I had a very brief look at the language over the
last couple of years. Let's start at the beginning. Zick was invented about 2015, 2016, something like this.
Yeah, I think he checks out. I don't remember precisely when there's also, you know,
the initial part where like it's a private repo, so nobody knows about it. Then he becomes a public
repo, but then still nobody knows about it. OK, I'm not exactly clear on that period, I guess.
I joined Zick more or less around release 0.4, I believe. Got it.
Going back about 10, 12, 13 years ago, I was just invented by Google.
Mozilla had just dreamt up this or somebody at Mozilla. Sorry, I should probably be more precise.
Somebody at Mozilla had just dreamt up this requirement for a new language, because C plus plus
and C didn't cut it anymore in terms of total cost of ownership of the code base,
you could have to know the rest of it. Hence go lang or affectionately also known as go was
and rust were born. Now, if I take a closer look at Zick, it does remind me in certain quarters
of both rust and go lang. It's not fully object oriented. It does support structs that
reminds me pretty much of rust. Enums are very close to rust. For example, if I take a look at the
other type and we're not getting too technical here, that reminds me of really of rust.
Where do you see the differentiator between say go lang and rust in a Z context?
I think that there is some difference. There are parts of the Zick syntax that kind of
remind of rust, but I know Zick, I've been doing Zick professionally now for a while, for more than a year.
I still, given that, I don't have an easy time reading rust programs. Even though parts of the
Zick syntax are similar, there are some big differences when it comes to how progress I end up
written in the end of the day. I would personally say as a still imprecise way of describing
the differences, but just to as a first approximation. I think that rust is a language that
loves abstractions and complicated stuff in the same vein that C++ does, while Zick is more on
the C side of the equation. On the side where you don't want to go to insane with abstractions.
Now, that said, while I personally, clearly, definitely in the camp of simplicity, so I definitely
prefer the Zick approach compared to the rust one. Obviously, there are some advantages to each
approach. There's people who can make the C++ work for them beautifully, and so
more power to them, that's my point. But yeah, so that's the bigger difference. I would say then,
if you were to compare rust and go and see where Z is in that spectrum, yeah, maybe it's
in between in some ways, although it doesn't map perfectly because Go is garbage collected, Zick
isn't. I would say that Zick is a simpler rust. It's a systems programming language in a way that
I don't think Go truly 100% is, but on the other hand, it does share with Go on appreciation for
simplicity. That said, Go like simplicity to a minimalistic level that I think it's kind of
unique of Go, and even though I like Go a lot, I really like Go, but I don't know, some things
are a little bit minimalistic for my days nowadays. Interesting perspective, Flores,
many people do say that rust has a very steep learning curve. Having learned rust myself and
full disclosure, I'm not. I wouldn't because I wouldn't consider myself a rust expert by no means.
I dabble and rust a little bit here and there, but that's about as far as it goes. I can
concur with the entry into the program language, not the easiest one, especially given the concepts
like ownership of variables, how memory is managed and rust and all the rest of it. I fully
concur with your observation that probably rust is too heavy on abstractions, and it's an
interesting perspective that you see this closer to see. Now, again, full disclosure, I'm really old,
so I learned to see about 30 years ago, give or take a few years. When I take a look at the
programs and the website tells me, apparently, because of the LLVM backend, you consider Zik to
be a drop-in replacement, and a lower level to be very similar or rather off-sea. How do you see
this relationship from the huge code base that is out there with regards to see Zik maybe being
a logical successor to see in the regard? Yeah, so we have an actual slogan for this.
The slogan is, maintain it with Zik, and it's on the website, but it's also the title of a blog
post that I wrote a while ago, and I think that we're going to use it for something else
in the future. So the idea is this. You can use Zik as an in-place replacement for clang. So there's
CC command. If you do Zik CC, then that's a flag-compatible interface with clang. So you have a
C project. You compile it with clang. You use to compile it with clang. You can swap in Zik CC.
Now, that alone doesn't sound too interesting. Why would you do that?
Clang is plenty good. Why toss in another thing? Well, here's how it works. You toss in Zik CC
and your stuff keeps working. Then with a tiny little bit of work, depending on how complicated
the project is, you can tweak a little bit in your make files to remove, for example,
target specific capability checks. Like, for example, you know how sometimes build scripts
are trying to look if your system supports a given feature or not, but those are tied to your
system. So if you remove those, and clearly you, as I'm going to say, you do that in a reasonable
way so that you don't remove a check and then assume that something through is through when it's
not. But the point is, you do it correctly, and you can now cross-compile your project. We actually
brought a blog post series where we actually did this with Radys. So step one, replace your
GCC or whatever your C compiler with Zik CC. Step two, tweak a tiny little bit the variables
that you feed into the make file and add the appropriate flags to Zik. And it's literally just
dashed target x86, Windows x86, Linux, whatever you want. And now you can cross-compile. And we
actually, in that blog post, cross-compile renders. So we did it on three actually while testing
this out the first time. So like I was on a Mac and I cross-compiled a version for Linux and I
sent to Enru and he was able to run. And that's step two. So cross-compilation, enabling cross-compilation.
And by the way, if you were to try to cross-compile a C project by yourself without Zik,
it's a bit more complicated than just setting the target variable. You need to bring your own
C-sroot, you need to bring your own C-library for the target. And there's a lot of work that you
have to do the Zik does for you automatically. Step three, though. And here things are becoming
more interesting. The build scripts are sometimes like there's a soup. Projects have soups
of build scripts like they have a make file, but then make doesn't work on Windows. So they also
add C-nake because somebody likes C-nake. Then somebody else likes something else. Windows needs
its own batch files or whatever curse thing people do on Windows. So you have always this project
where they have sometimes they commit the autocomps stuff. Sometimes they don't, I don't know, it's a mess.
Zik has a build system integrated in the language. So you create a build a Zik file and Zik can
use that to basically do what you would do with make files. Now this is interesting because if you
do that, you remove your dependency from make C-maker all this stuff. So now the compiler is also
the build system for you. So you reduce the dependency and made your project a little bit more
multi-platform. And that's actually something that it's already being used by, I can think of WASM3
and a few other projects in that space. They have a build Zik file in their
repo. So if you have Zik, you can just run that and you're good. And that brings us to the final
step. So here you can see the maintaining it with Zik story fully complete. You have a Z
project. You keep it in Z. You don't start rewriting it right away. But when you want to add
functionality, you can create a Zik compilation unit that the Zik compiler will be able to compile.
You will be able to export C-A-B-I symbols, functions,
Ives, tracks and stuff that interoperate with everything. So it's like it's one extra compilation
unit like any other compilation, C or C++ compilation unit that you would have.
Although we are limited to the C-A-B-I, no C++ A-B-I. So let's say that Zik is more friendly towards
in that perspective. But you have your Zik compilation unit and now you can link everything
together. And we do that, for example, in the blog posts. We take Redis and implement a new
command in Zik that then we link into Redis. That's maybe not the correct way of adding comments
to Redis. But when we wrote the blog post, the perspective was of us being the maintainer of
a C-project where we don't start rewriting everything. We just add stuff as a separate compilation
unit. And if you like Zik a lot, you can, if you want, start tackling your C-project with one
compilation unit at a time, like you replace it with an equivalent Zik implementation. And so you
swap one piece at a time. And if you want over time, you can rewrite it in Z. If that's your goal.
If that's not your goal, that's perfectly fine too. Because the point is that since Zik can
compile C code. And we have maybe a compatibility. For example, there are projects out there that are
just basically packaging a C-project into a repo that has a built-up Zik file and maybe a Zik
syntax sugar layer so that you can use the Zik file that gives you, you know, nice Zik types
instead of what the C API would return to you. But the second step is not even necessary.
Even just having a build file would be amazing. And Zik would be able to use it.
Okay, sorry, before we go any further, I should probably have prefixed this part of the episode,
like the really technical deep down stuff. Before we lose the two of members of the audience
maybe we should probably clarify a couple of things. L&VM, of course, is a compiler framework.
Let's put it this way. That is our available GitHub and also has a fancy project website.
You'll find the link in the show notes. Essentially, it's comparable to the GNU compiler suite
in terms of it has a backend that is in charge of code generation for a couple of things. And then
it has a program language specific front ends for the various program languages. Rust is using
L&VM, sorry, if you invoke Rust C, which is the Rust compiler, you essentially invoke the L&VM
backend for code generation. Similar, the C-lang, or Clang that Laura's just mentioned,
would actually be the C-lang plus plus would be the C plus plus front end for C and C plus plus
program languages feed directly into L&VM. Now, Laura's the build system you mentioned,
that sounds pretty much like something called cargo for Rust. For those few people out there
listening who don't know it. No, what cargo is essentially cargo is the Rust equivalent. I'm
simplifying things here. Of the make or auto make build system for Rust. cargo can pull down
dependencies, can compile dependencies in all the rest of it. So what make and auto make and
all the GNU tool chain equivalence took about, I'm tempted to say 10, 15, 20 years to really be
user friendly. In terms of simplifying things, it only took cargo about what, 5, 10 years max.
That's my personal opinion on the whole thing. But maybe Laura's you have an opinion of yourself,
with regards to this build system that you just described in comparison for example to cargo.
Yeah, no, I think that's a fairly comparison. To be a bit more precise, cargo is also a
package manager. Correct. Yes. We don't have yet the package manager part, but
see, start working on it in like, I don't know, probably three months from now. So we want to also
have that. It's just that we are slightly, it's a bit too early. But there's one thing that cargo
cannot do, that they can do, which is compile secode. Cargo can fetch your dependencies.
It's so Rust projects can depend on secode, and they do do that. But when Rust sees, when cargo
sees that you have a seat dependency, it uses the systems compiler, the system, the
system. So in a sense, cargo cannot fully work as a, if you will, build system and package manager
for see projects. Well, they can compile and cross compile sea dependencies. So let me give you
one example of how this is critical. And by the way, what this is, if you in from this perspective,
one thing that cargo cannot do, it's not the end of the world, though, because, because you can
use zig cc from cargo. There are a couple of blog posts out there. When I wrote myself called
zig makes go cross compilation, just work. And somebody else saw my blog post and did the same
with Rust. And so there's another blog post called titled zig makes rust cross compilation
just work where basically they had this Rust project that depended on a C library. And they
configured cargo to use zig cc as the systems c compiler and c++ also. And now they were able to
cross compile. So the what going back to the package manager slash build system perspective,
the aim for the zig build system and package manager is to become a major C build system and
package manager. If you want an example of this, I'm going to share a link with you both.
There's a tweet by Mitchell Ashimoto from HaxiCorp, which recently went public. So apparently Mitchell,
I don't know, instead of enjoying the big money that comes from going public, I would assume
started packaging c application, c libraries with z.
Shifting back from technical things a little bit. If I take a look at GitHub, the code base that is
out there with regards to go lang and Rust is just overwhelming, especially the adoption of Rust
in the in the last, I'm tempted to say two years never mind the adoption of go lang.
In the last seven years has been amazing projects that are come to mind. And other are more like
system oriented projects that require a more like a low level language like C or more. I'm almost
tempted to say C++ have adopted these two languages left right and center. Where do you see zig in
this context? And if I take a look at the at the code on GitHub, there are not that many projects
out there that use dig as the main implementation language. And by the way, of course, the language
apparently is self hosted. If I'm not completely mistaken. The factor of it being quite a young
language as well, right? So. Well, true. Yes. And that's the reason why I'm asking about the
roadmap here. Yeah. So, okay, maybe, so first of all, let me acknowledge that yes, you're right.
There are not that many z packages out there yet. That is fair. It's also because in part,
there is no package manager. So you can imagine how surely it reflects the level of adoption,
not out there. But also you start having a proliferation of libraries and packages once you
start having a package manager that allows you to easily leverage them. So we don't have that yet.
So I think it's normal for these numbers to not be exploding yet. We'll see after we publish the
package manager. What happens now? Okay. So this is libraries on GitHub. As for the language itself
being self-hosting. So the language at the moment is not self-hosted yet. Sure. But we are about to.
That's the current main piece of work that we are doing right now. Long story short,
Z is implemented in C++. But if we like C++, we wouldn't be doing Z. So we are trying to replace
the current implementation in C++ with that self-hosted implementation. These are false
implementations. Aside from being more to our taste, has a couple of interesting aspects to it.
One is that it's going to be considerably faster than the current implementation. Z is not that slow
at compiling. But the new self-hosted implementation is really designed to be much faster. It implements
many of the data-oriented tricks in case people have heard this term. It's like just techniques to
make your stuff go fast. And on top of that, we also want to implement incremental compilation
with basically, let's say, a new way of doing incremental compilation. There should be
also allow, it should also allow us to basically do rebuilds of arbitrarily big projects in less
than a millisecond. So the idea is you have a big project. You've compiled it once. Obviously,
the bigger the project, the more it takes to compile it. There's no escape from that. But you have
this giant project. Let's say it's, I don't know, Chrome or Zig Chrome. And you change one file,
one definition somewhere. Recompiling the project after that one change should be basically
instantaneous. That's what we aim for. And there are a lot of tricks that are necessary to get there.
So this is the self-hosted work that we're doing right now. I'm personally working on implementing
the doc system for the self-hosted compiler. That's what I'm working on right now. So the thing that
basically generates documentation automatically for Zig projects. But it will take a while before
all this stuff is complete. So as I was saying, I don't know, three or four months, something like
this, after that Zig will be self-hosted. Interesting. So with regards to the overall ecosystem,
you have a foundation in place for enough. So does Rust. So does, I'm almost tempted to say
go along, but we have this kind of tiny search engine brand go. So that's for me, an effort,
an effort, a compression. Are you sure to go as a foundation? No, that's what I'm saying,
but it has a search engine backing it. I will think one thing though. The Rust foundation is
very different from the Z software foundation. Do you want me to go into the lily's?
By all means, just go ahead. So Zig is a 503 non-profit foundation.
Sorry, 501 C3. While Rust is a 501 C6. So these letters, 501 C3, 501 C6, these are like,
it's a pointer, if you will, into the specific paragraph and the line inside
some kind of American legal document that defines. For the two people in the audience who are not
American text lawyers, lots of course referring to the text legislation in the US with regards to
non-profits. Yeah, this may be the show notes. Good luck finding them. I don't even know where to start.
I guess you can go to the side, but the point is, the point is, 501 C6, 501 C3. Now,
this is a tiny number of the changes, but a 501 C3, it's a non-profit foundation that can accept
donations. A 501 C6 cannot accept donations. So, not even the ones under the table.
I mean, you mean a lot being. Joking laws, I'm joking.
So they cannot accept donations. So the rest of the donation is not allowed to accept donations.
The only thing that they can do, well, I guess they can do work, just like the Z-Soft Reformation,
can do work and being paid for work. But the last foundation, basically, the way they get money
is by having member companies pay a fee. So in some ways, they are more like a consortium.
I think that here in Europe, we would think of that type of organization as a consortium.
So they are a group of companies with a shared interest. Companies pay a fee to
getting to the foundation, and that's it. One interesting side effect of this is that the Z-Soft
Reformation is paying its developers. I am being paid by the Z-Soft Reformation to work full
time on Z, and so are a couple more people. At the REST Foundation, nobody is paid to work on REST,
except maybe a couple of people who have administrative tasks. So the developers are not paid to work on REST.
I think the fundamental difference is, similar to Linux, the people on the foundation,
I'm part of different companies who are just chipping in with regards to making the project work,
whereas Zix seem to be different, apparently, in that case.
Yeah. Okay. Yes. Also because there are sometimes, I think, some interesting conflicts of interest,
I think, when you have the second approach, the one where you have companies, sorry,
the first approach is to say, the one where you have companies basically higher your court
contributors, because on one hand you have this, if you will, natural misalignment of incentives,
where companies paying these people to work on their stuff, and secondly to work on REST,
or the other open source project, whatever that is. But it's not just that. One thing that
happened recently with the REST Foundation, which I found not very nice, was that REST had an
executive director that was somebody from the REST project itself. They had been there for,
had been there for a long time. And basically, this person was, was the executive director
at Interim, so only temporarily, while they were searching for somebody to take the position
full time, but it basically never renewed her contract after it expired the first time.
And the foundation remained without an executive director for something like six months or something
like that. And in the meantime, when you don't have an executive director, the highest authority
is the president of the board of directors, who was the, the person in charge of the REST
team at AWS. So AWS basically, it's one of the biggest member companies. They have a bunch of
board seats. They have the executive, they're sorry, the president, the chairwoman of the
board of directors at the REST Foundation, and they also employ a good chunk of the key
developers of the REST project. And I don't know. I think that when you have an external organization,
whoever that is, it, for me, it's very easy to hate on AWS. But whatever the company is,
even if it's not a company, you know, where, where they ask employees to be in bottles,
even if it's a much nicer company, it's still a problem in my opinion. So one thing that we do in
the self-reformation is that we know upfront, we are never going to give board seats to any big
that company period. Okay, interesting. Okay.
Although now you might say, well, okay, then how do you guys ever expect, ever expect to become
big? That's an interesting thing. Well, what is the, I guess, what is the objective, but
just to go? Yeah, I mean, you mentioned the donations. So these are sort of no strings attached,
donations to the project, is that right? Yeah, correct. And then the second question that
follows on from now is, you know, obviously the people like yourself and people developing
their language, how do they earn their bread on the table? That's put it that way, right?
This is where, you know, organizations that sponsor Rust programmers that helps the,
or any open source project helps the project move along, right? So that's, if in your case,
it's mainly done on the voluntary basis or as a sideline, then you can perhaps imagine it
will take longer to take off, is that fair to say? Or how do you see that? Yeah, so I think that from
my, from the development, the velocity perspective, I don't think that not having a big company
sponsor Rust makes much more difference. I think it does make a gigantic difference more
from a marketing perspective, because even though, for example, Rust deserves, I think,
to be regarded as a very interesting new language and absolutely innovative when it comes to
the borrow checker, et cetera. Well, I mean, you can also see that, especially now that AWS
is in charge, there's a lot of marketing money being spent into Rust stuff, like the hype,
level is pretty high, and marketing money is being invested into, you know, keeping the
temperature high. In some ways, if you argue the same about Go, I don't know precisely
how much marketing investment that has been in Go, but, you know, the fact that Google uses it,
and then once it starts being used for one big project, then, and the fact that it's
baked by Google, then that all stuff that helps, for sure. For Z, when it comes to paying
for contributors, it works this way. We have three contributors that work full-time,
in our pay-to-work full-time. I'm one, another one is Jacob Conka, who left Microsoft to basically
work on a in-house linker that we are using in Z. I won't get too much into detail, but the idea
of course, compiling, like, making a program, compiling a program on Windows for macOS, it's not
intriguing, and especially with the new macOS, is that came out, there was no linker able to do that,
and so Jacob started working on this stuff. But, aside from these technicalities,
and the third person, of course, is Andrew. Our three are the full-time contributors right now.
Then there is a group of about, let's say, 10 people who are not working full-time, but who have
contracts where they are allowed to build hours to the software formation. So they do some work,
and they are allowed to build a few hours every week. I don't remember the precise details,
but you can think of it as, like, lower than part-time, something like this.
These are pretty safe. Obviously, the more donations we get, the more people we would like to bring
on board to work full-time. But, the general idea is that we would want to always stay small,
like a tiny organization, no overhead as much as we can, so that we can stay tiny, and more
importantly, that we don't end up, like, depending too much on one donor, on one big company,
something like this. We don't want to end up, like, Mozilla, who, at one point, had to fire a bunch
of very good people just because they end up, just because then one deal that they had with Google
ended up not being renewed, and there was a disaster. From a marketing perspective,
obviously, yeah, not having a big company in your border direct towards its stuff, because
well, they have money, and money is easily translatable into marketing muscle.
I don't know, you can have a ZIG conference organized and entirely paid by this giant company,
and that surely helps. We're not going to have that, but at the same time, I think that we are
solving problems that are interesting enough, that people have started to notice. I showed you earlier
a tweet from Mitchell Hashimoto, but we started, for example, recently getting being paid to do
offer a support contract to Uber, where they started basically to use the ZIG CC to cross-compile
some stuff on their end, and they wanted us to fix some corner cases with, like, old Linux
G-lib C versions and stuff like this. And I think that, if we play our cards right,
for example, I'm not really being paid to work on ZIG the compiler. I do that as well,
but my job is more marketing focused. So if you look for ZIG on Hacker News, you will find a good
number of things that I've written in the path that has reached the front page. I'm not the only one,
but this is part of our strategy. So we are more, I don't know, guerrilla style marketing,
you will, which is an interesting question. And of course, the links will be in the show notes
with regards to the stuff that Laura has just mentioned.
Laura, if I take a look at this spreadsheet, I see quite a few companies
outside the realm of the user's aspects that have picked up on ZIG. But of course, that pays with
regards to the Google stuff of the world and the musilas of the world and the Microsoft world.
I mean, there was a statement last year, what was it before? I can't remember where somebody from,
officially for Microsoft said that in a nutshell, I'm simplifying things, of course,
that Rust basically will be the next C++ at Microsoft in terms of, it's that, it's that
analogy stack that will be replacing the workhorse that has served Microsoft for at least 10 to 15
years as the main implementation language for office software for some other quite interesting
stuff over the years. Where do you see this in terms of the overall interesting adoption going
for ZIG? That's a good question. I don't have, so I didn't know about this,
Microsoft stuff, it doesn't surprise me, it kind of makes sense. I can tell you that my
knee-jerk reaction is, I don't honestly care which language they use to implement ads in my
start menu, so I'm kind of jaded when it comes to Microsoft specifically, but this is not about
Rust, this is about Microsoft specifically. But if you want another example, another recent example,
where Rust started being adopted by an important project, and actually in this one ZIG apparently
was in the race too, but we lost two Rust in a sense, if you will, is Ruby. There was a discussion
in the Ruby forum discussions with the creator, Mats, where they were discussing re-implementing
the component of the compiler, the GIT part of the compiler from C to either Rust or ZIG, and
they were, and then the contributors were asking the Mats, the owner of the project, if it was fine
to use Rust or Z, and they may end up choosing Rust. So that's fine too. Honestly, from that
perspective, I think that Rust and ZIG are different enough that people that would want to choose
Rust should choose, and they really like Rust, they are not going to be happier by choosing ZIG.
I do think that there are a lot of people though out there who would not be super happy to use Rust,
and that would be happier to use ZIG. In interesting perspective, taking a step back now,
if I take a look at the ecosystem, starting, for example, with Python, Python has been run for
the last 30 years, Golan has been run for 15, 17 years, some of that, Rust has been run for 10 years
plus, give or take. When I take a look at the crates that I owe ecosystem, it reminds me of
PyPy, as in the Python package index, that took in terms of functionality and packages
overall available for any purpose, parsing websites, anything basically. If I take a look at Rust,
I'm tempted to say that it took the Rust community about 10 to 11 years to get to the point
that the Python community took over 25 years to get there. If I take a look at the ZIG ecosystem,
I don't think it's quite there yet. Okay, fair enough, you have been run for seven years,
so it takes a while to build an ecosystem. But as far as I'm concerned, actually, a language
and the adoption of a language, or text, in general, lives by the ecosystem as such,
where do you see ZIG going in terms of our community adoption, especially when it comes down to
the module ecosystem? I can tell you very easily how we're going to do much better than Rust.
So here's the idea. Rust is a fuzzy language in a sense. So fuzzy is in
because when you're using Rust, if you want to make good use of all the things that Rust gives you,
you cannot really, you don't really want to jump into C code, do you? Because C isn't safe,
right? And you have to close everything in and save brackets and it makes
interpretation hard. In ZIG, we're not that fuzzy. In ZIG, we don't mind bitfiddling. We don't like
on the fine behavior. So some C stuff maybe won't compile correctly. ZIG, by the way,
compiles everything with on the fine behavior sanitization. So not every C library can be used
right away, but the ones that don't have on the fine behavior in them can be used. And we are not
as picky as Rust. Surely we would prefer as implementation over a simple implementation of
something, but there is less of an like impedance mismatch between ZIG and C than it is between
Rust and C. So long story short, from ZIG, you can make use much more easily of 40 years of C libraries.
And for this, this is how it's going to start. The start is not going to be, let's say,
re-implement everything in ZIG. The start is going to be, let's package already good C libraries
that have been out there since forever. They are basically currently being used everywhere.
There are like critical infrastructure of modern technology. Let's re-pack it up from ZIG so
that we can use it more easily. And boom, now you have everything. It won't necessarily work in
every single case, but the point is we are not rejecting existing C libraries. We are embracing them.
And it's much more easy to just fix the build script so that it uses Build.ZIG of an
existing C libraries than it is to library, than it is to re-implement it from scratch.
Interesting perspective, especially from, okay, full distortion, I'm a little bit of Rust
hand, but for enough, apparently we both share that passion to some extent, Laura, but let me take a
look at it from a Rust perspective. Rust gives you, I'm tempted to say a very low technical depth.
In terms of if you can convince the Rust compiler to generate code, the QA phase in terms of
fixing bugs and especially when it comes on to memory stuff is pretty short. See on the other
hand, you just go ahead. If you want to shoot yourself on the foot, that's fine. Now I see ZIG,
if I understand the language correctly, somewhere in the middle, you can do a lot of things that
you can do in C, and what you just said confirms this to a certain extent, if you want to reuse
C libraries, but Rust is explicitly on the other hand basically tells you, sorry, you have to know
what you're doing in terms of if you're using the answer of Crate, you better know what the implications
are, because normally, and that especially goes for the ecosystem that is out there for us,
you are bound to save code, and so combining the Crates, and this is very similar to Python
these days when our program Rust, first of all, I'm going to take a look at Crates and I owe to see
what's out there. Similar, if I want to do a code based in Python, I'm normally checking out the
Python Package Index, because most of the time, and that goes for Rust and Python, I simply end
up writing glue code, but if I check out Rust in terms of a stick to Rust, once I basically have
my cargo definition file, as in cargo.tomel done, which is, I'm simplifying things in the
equivalent of a make file for C, the Rust compiler basically, because we're also talking about
save code, guarantees me a short turnaround times in terms of debugging, especially when it comes
on to memory issues. Now, where do you see this total cost of ownership, especially with the gods,
to technical depth going in terms of zik adoption? Yeah, if that makes any sense. It does.
That's definitely an open question, and obviously, Rust makes a very good,
makes a very good proposition when it comes to safety, and ultimately, I agree with you.
The ultimate point is, what is the total cost of ownership?
Let me ask you a counter question, but I would like to reiterate, I do believe that Rust is making
a good offer, so I don't want to dismiss that. That said, which one would you prefer? Also,
from a perspective, maybe of ease of use, being able to just import a Rust
crate into your Rust project is obviously super easy, but from a perspective of total cost of ownership,
or the risk of bugs, you mentioned risk of issues with memory management, but memory management
is one source of bugs. There are also many other ones. Of course, would you trust more
using a newly minted Rust crate, that basically is a re-implementation of...
Curl, that's what I wanted. Curl, yes. From the perspective of total cost of ownership and bugs,
yes, Rust covers memory bugs, memory usage bugs beautifully, but those are just one source of bugs.
So, which one would you prefer? A newly minted crate that is a re-implementation of Curl,
or Curl itself? Because Curl itself is surely... it's a C project with all the...
the inner that comes with that, but at the same time, it's very, very battle-tested.
So, which one would you prefer?
Interesting question there. I'll go for the original curl.
I would take a look at the guitar. Issues page, yes.
No, total sight, Laura. That's a tough one.
I would probably take a look at the adoption figures of Craitorio to see who's using this newly minted
Curl implementation. To see what's happening. I don't know. Give it a half a year, but for the
meantime, I probably would be... I'm reluctant to say this. But I would concur with Martin, yes.
So, my answer is code. It is. It is answer code, yes. But at the end of the day, my point is that
there's a lot of good outcomes from Rust, but it's unclear to me that is the ultimate silver bullet
when it comes to total ownership cost of something. And I don't believe that throwing
immediately in the trash 40 years of C code is the right choice. I'm being a bit too extreme here,
maybe, because it's on with you. Yes. Rust can intervene if we see. But I think that more in general,
especially for domains where memory management is not that complicated, while other sources of bugs
are really more the problem, like I don't know, distributed systems. Memory management,
most of the time, is not complicated, like you have a request, and memory has to leave
for as long as the request survives, and you can do that with an arena locator is super easy.
The problem, though, is that in distributed systems, you have a bunch of problems that come from
the nature of distributed systems. And those are bugs where Rust can help you to some degree,
but not 100%. And again, not to dismiss Rust. Rust is amazing. This is all good. The point is,
it's not the ultimate growth that nobody ever will able to agree. Yes, absolutely.
Because that hasn't been invented yet. Exactly. Now, I mean, jokes aside, Laura, I mean,
these three languages, and GoLang goes along the same line to some extent, are targeting one
specific area, namely system languages, for system-oriented programming.
Zika is in that area of C, C, this is where C comes from, Udings was implemented in C,
and that's exactly what Mozilla had in mind, when they more than 10 years ago,
but took a very serious look at something called Rust. A system language designed for
system-specific things. And if you take a look at the crates that are out there, much of the
stuff is actually targeting a system programming, goes without saying, like the one you just mentioned,
like curl. Yeah. So, I think that the idea of packaging curl is a stocking point, and then maybe
slowly over time, after you have come to an understanding of how you think it can be improved,
because I think that rewriting without improving the interface, it's a,
well, maybe it's not the best use of time. Let's just, let me just put it that way. So,
the plan is to have people just reuse what's already over there, that's already pretty good,
and then only rewrite once you know how to improve on the original interface, on the original APIs
and stuff. Okay. Yes. You're listening now to the additive version of this episode. The original
version went about for four hours. We went into the, you know, the compatibility details, but this,
of course, has been edited out. You may find the original version on something called Linus
in Laws.eu, but jokes aside, no lawyers, let's wrap this up. It has to be more than interesting
to, here, here you perspective on things, especially where you see this going. There is, if
you've listened to a couple of episodes, there's something called The Poxes of the Week,
where we simply discuss things outside the topic of the current episode as an ending goes.
The pox basically are about things that you think worth mentioning, like books Martin normally
refers to movies, especially his dark habits and some other stuff, like designer rock since
and so forth, but really anything goes. So, Laura, what is your pick of the week also known as a pox?
Let me think.
Oh, man, I don't know. I can only think about what I knew for the pox.
The pox on the spot, okay. But why didn't you go first, Chris?
You see, I'm almost happy to say, my new vice as in the TV series from the 18s.
I've just just got a lot of ideas for them all. It's a little more, I'm just okay.
No, I just decided. I've just discovered this recently and I used to watch this left run
in the 20s and it brings back fun memories, but without the fire, it's Martin, what's your pox?
That's a good question. I'll have to have a think as well. I don't think anything specific.
You have about 10 seconds.
So, if we talk about movies, I watch this week and I rewatch this week and the original
lot of the ring of the ring's trilogy and it was nice. I don't understand, though,
why certain phrases became memes? Like, they are taking the hobbits to
Isengard. Why? Why that phrase became so much of a meme that they made songs with it?
Did it? Okay. Yeah, there were like YouTube videos which basically this sentence
repeated as part of a song, but that was only one, right? Also, the other one, you don't simply
walk into Mordor, something like this. It goes to show Laura's that you're about 30 years younger,
than Martin and myself are. Oh, I'm sure you're not going to get any letters.
Give her a take if you had any way.
Okay. One does not simply walk into Mordor. I think there has been memes so many times.
I can't even count how many have so I've seen of those.
But yeah, anyway, it shows that I guess intercultural culture has changed from that time to today
because nowadays I don't know. In some ways, the memes seem weirder. The movie's worse,
but the memes are at least more relatable, I think, than in the past. I never understood them.
The past ones. Okay. Martin. Okay. Since we're sticking with
movies, I'll go with a movie called Land of the Blind, which is I watched at the weekend.
It's from 2007. It's a BBC production.
I don't think so. It was part of the show. In that, it's basically about someone
overthrowing a dictator with a revolution, and then the revolution becomes the new dictator.
Which is even worse than the original dictator. So it's kind of, you know, your enemy really is
this moral. Okay. To the modern world, like, back number one for a McSyriot and McSyriot
Joshua Worth, up purely, what's the word I'm looking for, incidental? Coincidental?
Inspiration, whatever.
Jokes aside. No, links may be in the show notes.
Loris, that has been more than inspiring.
Thank you for taking the time. Actually, what we missed is, if people want to become involved in ZIG,
yes, the club. Let's go ahead. How can people help? How can people help?
People can help, I think, in three ways. One, by contributing code, if that's what I like to do,
because it's an open source project, you can go to github.com slash ZIGLANG, and you will find
our organization with repositories, and we have weekly meetings to help people contribute to
the language. Number two is, of course, donating money. We have a github sponsors page,
still on github. Also, on the website, there's a big link at the top. So if you go to ZIGLANG.com
or at the top, there's a big link that tells you how to sponsor the ZIG software foundation.
I think it's also an interesting page to read, because it explains how the organization works,
even if you don't plan to donate. Number three, and this is actually my favorite, you can contribute,
just by paying attention, because all these things that happen in open source,
and how open source organizations interact with one another, having people see what's happening,
really can make a difference. When nobody's watching, organizations, open source organizations
can behave in ways that you wouldn't expect from an open source organization. Recent events
in the dotnet foundation, for example, are relevant to this point. And more in general,
knowing what we are doing helps us, you know, helps us also protect ourselves from people
misinterpreting, deliberately or not, our intentions and actions. So that's my favorite.
Great. Last question for my side-law is, what is the license for ZIGLANG?
What is a liberal one like Apache or MIT or something?
Good question. Yes, it's MIT. MIT, you're the first people. It's a very liberal
license. So you can take the source code and do pretty much whatever you want with it.
Yeah, and it's deliberately non-GPL, like it's deliberately non-complicated for companies,
let's just say. Yes. People, this is a non-communist license, of course, because it's not GPL,
as it's not part of the GPL license family, but that's okay. We do make exceptions on this podcast.
Well, that's a very complicated story, maybe for another episode.
People, the lyrics in laws is. Is the is the go-to source for the episode list?
Pick and choose your episodes with regards to communism. We do have a five-year plan.
There are regular cadence updates on the podcast, how we do it with our five-year plan. Yes,
exactly. And don't forget to check out the dark side, just in case. But enough plugs.
Lawrence, thanks again for being here. I hope to have you back soon for an update on Zik
and all the best with the project. Thank you. It's a pleasure. This is the Linux in laws.
You come for the knowledge. But stay for the madness. Thank you for listening.
This podcast is licensed under the latest version of the creative comments license.
Type attribution share like credits for the intro music go to blue zero stirs for the song
summit market to twin flames for their peace called the flow used for the segment intros.
And finally to the lesser ground for the songs we just use by the dark side. You find these
and other dd's licensed under cc achamando or website dedicated to liberate the music industry
from choking copyright legislation and other crap concepts.
In the Zik community we start calling this stuff like that's a Linux moment.
Uh when you're using Linux and like your mic doesn't work or your screen share doesn't work.
And it's a little moment. Have you copyrighted this term because it'll be in an hour?
I'm joking.
You've been listening to hacker public radio at hackerpublicradio.org.
Today's show was contributed by an hbr listener like yourself.
If you ever thought of recording a podcast then click on our contribute link to find out
how easy it really is. Hosting for hbr is kindly provided by an honesthost.com.
The internet archive and our sync.net unless otherwise stated today's show is released under
creative comments, attribution, share-like, dd's o-license.