Community, Compilers & the Rust Story with Steve Klabnik

Kostas (00:02.43)
All right, hello everyone. I'm super excited for the guest we have today here. First of all, for some personal reasons, our guest is like someone that I've met for the first time 11 years ago. I don't know if he remembers that, we'll see later. And it was actually in Israel. He was there to present at Ruby on Rails conference. That's how I first met with him.

And then through like all the years, something like today, somehow whenever I reached out to this guy and asked for some advice or like some help, he was always there, which I find like very fascinating and says a lot about the person. But outside of like the personal reasons, there are some reasons that he was the audience, like should be excited. He's a big contributor in some very important technologies in our industry, starting with Ruby on Rails and having...

rust and now he's doing some other thing that he's going to talk about. But I should stop now and let the actual guest talk about himself. So Steve, welcome and tell us a little bit about yourself.

Steve (01:17.644)
Yeah, hey everybody, I'm Steve. Thanks for all the kind words. So yeah, as you mentioned, I started working on Ruby and Rails sort of after college and then did that for a very long time and then eventually kind of learned about this little programming language called Rust and I thought it sounded kind of cool so I got involved and ended up eventually working on that for almost 10 years afterwards and so, you know.

and now I'm kind of like using Rust at my job, so it's fun to sort of like build a tool and then get to use the tool after you put in so much time of like actually building it. But yeah, I've been a big open source contributor over the years, because GitHub sort of came out of the Ruby world. I got involved in GitHub really early, so I think I got my GitHub account like six months after they had first like went public, so you know, I've been on there for...

way, way too long and you know, now I'm just as I sort of hit middle age, trying to like figure out what I'm doing next and where things are going. So there's definitely a bunch of stuff I'm excited about, but you know, we'll see what happens. So yeah, it's great to be on.

Kostas (02:16.802)
All right, first question. So Ruby on Rails, it's like, obviously like a framework on top of like Ruby. And from there, you go into like more actual like language itself and compilers and all the tooling around that, right? What attracted you into that instead of doing...

Any other stuff, I don't know. There are many things that happened in the past 15 years in tech. A lot of exciting technology out there. So what attracted you into this type of technologies?

Steve (02:51.448)
Totally. So I started learning programming when I was seven. I learned GW Basic first, and then I actually learned C as my second language, and eventually C++, and then Java, and then Perl, and then a whole bunch of other stuff. C was sort of the first language I really, really, truly loved using. But then when I went to college, I was really interested in compilers. I actually scheduled my first classes to get to compilers as quickly as possible.

but it sort of had kind of become obvious while I was in school that there's not really a lot of compiler jobs. I think actually there are more than I thought at the time, but it sort of was like, it didn't feel like a viable career path. And so I ended up getting an internship at a company called Libsyn, which still exists today. They host a lot of podcasts actually. And so at the time it was like 80 % of the podcasts on iTunes where I was at the Libsyn. So I kind of got involved in web work that way, but.

My friends in college were all still systems hacker people, and so we had a hobby operating system we're working on together in college, and so I sort of had my feet in both worlds, but then I ended up doing a startup in Rails after college that it was way too early. It turns out 2009 is a bad year to start a 3D printing startup. well, but that kind of got me involved in the Rails space because they were using PHP.

And so I was like learning about Ruby stuff via reading on the internet and I was like, my God, I wanna use this Ruby on Rails thing because it seems really cool. And so I built my own startup on Rails and then after that kind of concluded, I ended up teaching Ruby on Rails to some people and kind of getting involved in the general Ruby scene and then the Rails scene. And so that was sort of like how I became known professionally, but I'd still always had that underlying sort of like system-sy background originally. It just turns out that the web is also an interesting space to work in. And so.

At some point I kind of decided I didn't really want to work in Ruby or Rails anymore. I was at least thinking about moving on to something else. And so I was home for Christmas and I'm from outside of Pittsburgh. I grew up on like a cattle farm, so there's not whole lot to do when I go visit my family for Christmas. So I was on Hacker News and I saw this whole thing that was like, for us 0.5 has been released. And it was kind of this announcement of things happening. And so I decided to check it out and I really liked it.

Steve (05:06.638)
but I struggled with some of the code examples they had posted, and so they said join our IRC channel for help, and I'd used IRC for many years at that point. I knew that being a noob on IRC is often not a pleasant experience, but I was like, I'm an adult, I'm an accomplished professional, it's fine if I get made fun of, whatever, I'm just gonna do this. So I joined the IRC channel and I said, hey, I'm having some trouble getting this example to compile. I thought I read the docs, but maybe I don't know what's going on, and they went, oh.

A new person, like, this is cool, welcome. Yeah, we changed something yesterday. We're still changing everything constantly, so sorry, that example's out of date. Here's what you need to do now, and if you have any other questions, let us know. And I was like, whoa, these people are super, super nice. And I was kind of thinking about Rust as language, and I sort of realized that the, I had loved CE when I was a child in the 90s, and I was born in the 80s, but I wasn't really, the latter half of the 80s, so wasn't really programming until the 90s.

But like there had not really been, like you have C++, but other than C and C++, there wasn't really a lot of actual challengers. And what I mean by actual is like, obviously people had done things. That hobby OS I referenced in college was written D. And so like, I was like familiar with it as a sort of successor to C++, but it, I didn't feel like it was going to go any further than it already was. It wasn't getting any more popular than it already was. And that was kind of the case with all of these sort of better C languages. There was not really a whole lot of

like people were trying some stuff in that space, but no one has succeeded yet. And so what I saw was a brand new systems language, which is an essentially like to put it in two startup terms, like a market that's being underserved, but it's backed by Mozilla, which means that they both have the resources to invest in it properly, as well as like some amount of social clout of like, okay, you have a user for this thing already and therefore, you know, it is likely it's like.

Getting your first big user is the hardest one, right? So if you're already starting off in a place where you have Firefox that's gonna use your programming language, then that's a really big thing to convince other people to use it. And also the community was super, super kind and welcoming. And so I saw all three of those things and I said, yeah, this is where I wanna switch my attention to. And so that's kind of how I decided to do that. And so it's super funny because yeah, a lot of people are like, yeah, web person getting in system stuff, they don't know anything. But it's weird, because I see myself as a systems person that got into web stuff.

Steve (07:27.852)
and is the returning to my old form. So just to be clear, I never really did work on the Rust compiler. I got a computer science bachelor's, but I almost got a graduate degree in English, and so I've always really liked writing and documentation and stuff, and so I tended to work more on the social side and the documentation side and kinda let the compiler folks work on the compiler itself. So I definitely know lot about compilers, but I was never really my job to work on Rust C itself.

It's not that I don't find that work interesting, but there's like more people that are interested in that work than in the other thing. And I like to be useful more than anything else. And so if no one wants to do this job and a bunch of people want to do this job, I'll do the one no one wants to do because then I can contribute a lot more than just being like a smaller part of a bigger machine.

Nitay (08:10.681)
There's somebody interesting overlaps here. Sorry, I wanted to jump in a little quick question, which is, so I actually worked at Facebook for a while with Andre Alex and Dress Group, creator of the D language. And one thing that was always interesting to me, and I mean, he's an absolute brilliant guy, like truly like above, you know, standard deviations. Like at one point I remember he went and rewrote the entire C++ STL.

Kostas (08:10.855)
I think...

Steve (08:21.474)
Yeah.

Nitay (08:37.753)
So he rewrote vector and map and all those things as the FB versions and got some like 10, 15, I forget, maybe more percentage performance boost across all Facebook code, literally all. And one of the things I always found interesting was that the D language had so many interesting constructs and ideas, but yet hasn't, never took off to the level of like its potential, I would say. And I always wondered if that was because,

Steve (08:37.826)
Yeah.

Steve (08:47.715)
Totally.

Nitay (09:06.072)
something was missing on the community side or maybe like, for example, Facebook been pushing enough. So I'd be curious from you, having seen the Ruby on Rails community, the Rust community, et cetera, like I mean, coming through kind of multiple of these iterations, what does it take to do a community right wrong? What do people mess up? What do people nail and do right? Like how does it, how does community thrive?

Steve (09:26.274)
Yeah, I Zondrew is obviously brilliant. So I don't want to like say that this is a thing he made a mistake on personally or anything. And Walter Bright is also a very smart guy. yeah, absolutely. You're not either. I'm just prefacing what I'm about to say. Cause before I get critical about something, I want to like acknowledge that like, you know, like this is, you know, it's not really like about them exactly, but it's a lot of D feels socially like it's so

Nitay (09:35.797)
Yeah, I'm not saying that either to be clear. I'm not saying that either. Yeah.

Steve (09:51.244)
Walter Bright, who's sort of the BDFL of D and then, know, Alexandre was kind of the second in command sort of person for those who don't follow obscure programming language situations. Walter wrote the first commercial C++ compiler period back in the 90s, if I remember correctly. And like, so he is like a very, very deep kind of compilers person, but also a lot of his experience is very rooted in that era of languages and stuff. And so D suffered from several different kinds of, I think like fairly critical errors that ended up holding it back and

One of those was that initially the compiler was not properly open sourced. And it was source available, because Walter was able to distill his early career selling compilers, and so naturally he kind of did what he already knew to be the case, and sort of in the very, very early days kind of was like, maybe I can make money by selling compilers for this language. But unfortunately, selling compilers is a business that ended in the late 80s or early 90s, and so it's not really a move. And so we tried to the difference by making it sort of not truly open sourced, but that caused a lot of people to

back off because they really are very deeply skeptical of non-open source tool chains at this point. And so that was like a big problem. A second one was sort of an issue that has been resolved a long time ago, but I think was a really big problem in the moment when D was getting a lot of attention sort of in that like 2000s era thing, which was there was effectively a total rewrite of the standard library. Differently than...

I say like your story about Facebook's standard library also does not surprise me. I mean, I've heard it before, so it doesn't surprise me that reason. But like an interesting thing about the C++ standard library is there's a lot of constraints that are put on it by the way the standard is worded that make things suboptimal. So for example, like standard reg ex is actually slower than shelling out to PHP and calling a reg ex because of certain ways that it's defined in the standard. And so if you're able to throw away those things, then you're able to do significantly better. So part of that is due to his brilliance and part of that is just due to the fact that like,

if you don't need to, I forget, think, there's a thing where basically the standard implies that one of the things needs to be a red-black tree, and so it's just like, that's not always appropriate in every circumstance, and so an unordered map, think, is always required to be a red-black tree, basically, by the complexity requirements they've outlaid or whatever. So anyway, if you have different needs, you make different choices, and therefore, do better. And so Dee kind of had this moment where Phobos versus Tango were kind of the two different versions of the standard library, and so,

Steve (12:14.806)
that situation was not really resolved swiftly enough. So you had a circumstance where like which project you wanted to work on depended on which version of the standard library that was totally different. And so like on one hand, it's cool that a programming language is flexible enough that you can have a second standard library, but also it made a schism in a community that's already small. And so like when your first impression is like,

wait a minute, like which standard library do I use? And if you pick the wrong one and then you would use a different dependency that depends on the other one, you're kind of screwed. And like just that made it very, very difficult for a lot of people to sort of get involved. And the final thing that was, think the most important out of all three of the things that really put a nail in the coffin for Dee, I think is its insistence on having a garbage collector. And like, I understand why it has one and I do think it's kind of the right call, but like it's...

C++ folks, is the alleged like community that Dee was trying to target, just are like the here garbage collector and they just nope out. Like it doesn't matter. It's not rational, but like that's, I mean, it is rational sort of, but it's also not inherently based in the trade-offs. It's just like, oh, that's like a thing that's not for me. And so the problem is, is that like, you can't win social arguments via technical means. And so like too many people would just not even look at it because of the GC at all.

The GC is really interesting because you have a lot of control over it and you don't need to use it for everything and like all that other kind of stuff. But like a lot of people wouldn't even get to that point of investigating what's going on. They just say, garbage collector language, don't need to do it. And I think this really mirrors like essentially like in some senses, first silly, maybe controversial thing I'll say, but like go is kind of like D done correctly.

And if you look back at the early Go story Rob Pike talks about, like they expected Go to catch on with C++ programmers and it really didn't. It caught on with higher level people that were now interested in a lower level kind of tool. And that's sort of similar, is that I think that a lot of C++ folks heard Go had a garbage collector and they were like, no, but it found a different niche with other people. And so I think it was really kind of like a marketing failure essentially, where if they...

Steve (14:24.768)
weren't trying to pursue systems and C++ people and systems is complicated because Go is also systems language depending on how you define system languages, blah, blah, blah. But like, I think that there is a chance that Go could have not been invented and D just would have been Go, but that's like not really how they positioned it or how things kind of like played out. And so it's sort of like, unfortunately fell to the wayside because it's not low level enough for C and C++ folks. And now there's already a language that basically does sort of what it does, but better kind of, or at least.

Many people would argue that, I guess. I still think there's a lot of really interesting ideas in D and like, you know, there's a lot of cool stuff going on, but I think it's just the language of space is really crowded and it's really hard to argue that you should start learning a language that's been around for 20 years and so hasn't taken off yet. And so think it's gonna be really hard for them to sort of come back from that as a thing, but it's definitely really cool language and the people that work on it are great. yeah, I don't know.

Nitay (15:19.953)
That was some incredible insight. And you highlighted something very interesting there that I found myself in my own open source experiences as well, which I think people often overlook. I think there's this sense in open source that if I just write the best code and it's the highest quality and it does whatever, kind of if you build it, they will come. And there's not this thought of making an open source community really as a business in a way. The thing you just highlighted is...

What's the audience you're going after? Like, what's the target? What are they looking for? How do you get it to them? How do you market it well? Like all these kinds of things that I find are often overlooked. How did something like Ruby on Rails or Rust do it right then in your perspective?

Steve (16:00.63)
Yeah. And there's kind of like two interesting things. So I guess I both agree with you, but like also disagree in a way that's actually agreeing, which is I would argue that most people ignore the fact that social factors are part of what the best means. That is like a tool that is like the best technical that nobody can use is not actually the best tool because like usability is actually an important part of the tool as well. And so people tend to like discount these factors and include it like as sort of some sort of separate, like you can't

can't truly separate the technical from the social aspects of things like tools. And so people wanna try to split them up and be like, well, I don't care about the social, I only care about the technical and I'm making the best technical thing. And it's like, you can't really fully split the two apart. so Rails and Rust both did these in different ways. Rust succeeded in this fashion because effectively we understood and often like explicitly talked about Rust as though it was a startup in the sense of like,

not from the money aspect or that kind of thing, but just from a, this is a product and we're gonna have users and we need to figure out how to serve those users and what is the target market. And we sort of thought about the whole thing. And this is also why you see Rust adopt. So if you look at C++, because it's the natural comparison, there's the C++ standards committee that defines the language, but they only make a document. And then there's a bunch of other people that make a compiler and there's other people who make tools and then there's other people who make build systems.

And all those are disparate groups of people. Whereas Rust sort of does a different thing where they produce the, the Rust project controls the language, but also the compiler, but also the build system and also the like version manager tooling and like also the documentation. And it's like kind of produced as one coherent thing that you use. And so it's sort of like a full product from one single organization.

And so, you know, both of those methods can succeed in different ways. Like obviously C and C++ are massively successful, but like the sort of unified experience of using Rust is like much, much simpler. And a lot of people kind of prefer the sort of here is like a whole package of something. There's kind of an interesting parallel there and something else, but I'll go back in a second because the other half of this is how Rails did this. The nice thing about Rails,

Steve (18:21.034)
is that like basically like it succeeded by not needing to care about being a product. Like DHH has been very clear for, in Rails' entire history, that he makes Rails for himself first and everybody else secondarily. And so Basecamp, like the company that he started, is able to pay him to do that work. And so like it sort of doesn't really matter if anybody else uses it. And so it only really got a bunch of traction because he did do a job, like a good job of

and stuff like that, like the 10 minute video, for those of you who are not old like I am, way back in the day basically Rails first was sort of announced on the scene with this video where David showed about how you could make a whole blog in 10 minutes. like nowadays that's not very impressive because everybody can do that, but at the time like you'd spend time spent a whole day like getting your tool chain set up, let alone like actually producing a full blog with comments and authoring tools and everything else like in that short period of time it was.

mind-blowing the like level of productivity that you could get and so you know on some level it was because it was a better technological product but also David did do a good job of promoting it as well it's just like the focus wasn't necessarily inherently on building a community and getting other people around it it was more of like I have this thing and I think it's very good and so but like by doing that promotion it let other people you know use it as well and but like

I think there's kind of like an interesting version where like, I think that DHH would be totally okay if no one else used Rails and that's fine with him. And that kind of like fearlessness, like lets him do exactly what he wants. And like, it just so happens that, you know, it is a good, there's a thing we said in the pre-call where we chatting before we turned the recording on, but like, I kind of believe that when you're like making art, you need to make it for yourself. And just like, because that way, you know, you're making something you think is good.

And then you find other people who also like what you like and have similar tastes and interests, and then they end up like, you know, joining you. And so that's kind of the model that Rails takes is that like it's fundamentally built for David first and everybody else is only incidental. And it just turns out that a lot of people share his tastes and like what he's doing. And so that made it into a bigger thing. But I think there was like a stronger aspect of technical superiority, if you will, with Rails. It was very clear to almost everyone that it was a massive productivity boost from pretty much everything that had come before.

Steve (20:41.998)
productivity is not everything, but you know that also, it also coincided with sort of the startup scene in the US really blowing up, or at least the second wave of the startup scene. Obviously the dot-com boom was like very much a big startup kind of era, but like it sort of happened at a moment when there was a lot of other things going on that it was able to sort of take advantage of, and there was a reason why it was sort of the de facto startup stack for many people for many years. But yeah, to get back to the unified,

product thing really briefly, because it's kind of a fun thing I like to think about is there's like a big difference between Linux and like other traditional unices. let's just, let's take Mac OS, which is gonna make all the traditional Unix people upset, but like it is much more in line with like traditionally how Unix has developed, you know, so like Linux is a single project and they make the kernel. And then you have GNU who makes the user land tools. And then there's like distros to like take both of those things.

and a bunch of other random tools people make and they put it together and like, they're kind of selling the product. And so what's interesting about that is you kind of have at least two or three groups that are totally not working concert with each other. And they're kind of just like doing their own thing. And then there's sort of like, you know, a group that integrates all these random projects written by these random people. Whereas like the more traditional UNIX development model and also, you know, something like the Mac OS kind of follows is like, you know, being a UNIX as well is like,

everything is produced by one organization. And that's obviously not literally true. Mac includes a ton of third party software, including some GNU tools and some BSD tools and stuff. But like FreeBSD and like Illumos and OpenBSD are all developed by one team who's building the kernel and the user land tooling and a lot of the other projects as well as one product from one organization. And it's much more coherent and organized.

Obviously Linux and Linux distros have been massively successful regardless, but you'll notice end users tend to talk about which distro they're using, not like the list of all the different things they're using. And so it's kind of like one of the greatest strengths of Linux is that all these different projects have their own advantages and disadvantages, but it's also a massive weakness because you get a lot more incoherence. Like there's a reason why Linux is like harder to use than something like the Mac or something like traditional Unices, and that's because the exact same strength of all of the diversity of the different projects

Steve (23:06.774)
is also its weakness because it's much less of a single product and much more of like a pile of stuff that happens to work together most of the time. So anyway, like Rust has very much chosen the sort of like traditional Unix model of like we are producing a unified product across all these different things. And there's obviously different teams working on all the different parts, but like, you know, it's like it's seen as a single cohesive whole rather than as like integration between a bunch of totally disparate groups of people.

Kostas (23:37.505)
So Steve, while you were talking, first of all, I was already starting to think about the case of Linux and how the kernel and the different layers there that you described there in a much better way than I could ever do. But at the same time, one of the first things that came in my mind when you're talking about that, it was also like SQL and anti-SQL and the stylization of SQL there and the total chaos of

how these things are actually getting implemented from one database to the other, and how long it takes actually to include something in the standard. So like JSON support, for example, I think in the industry was like, don't know for how many years before it became part of the standard itself. And what I want to ask you is, do you feel like these...

standardization kind of process or having like an external body that's standardized like specific technology and then I don't like the members of the body or like whoever else uses that and we try to have something like coherent that's built out there. It's actually not viable because at the end of the day what we see is that models like the Linux kernel one where you have like a very strict hierarchy there, right? How things are happening.

or very good example about what you're saying about Rust, they're more successful at the end of day. They managed to deliver something that it's a better experience to the user and that leads to more adoption. So that's one part of the question. And the second part of the question is, if let's say that's true, and the best outcome can come from cases where you have base camp.

and someone who built something for themselves, isn't this brittle if a big part of the industry is actually built on top of that? What happens if, let's say, inside Rust, someone decides at some point to disagree with everything? I don't know. There's an excuse in there that happens. Tell us a little bit about that.

Steve (25:46.456)
Yeah.

Steve (25:51.982)
Yeah, it's really interesting and good point. The way that I like to talk about this is like, know, BDFLs are fine as long as the D is B, right? Like as long as the dictator is benevolent, then like everything's great. It's like, but then what happens if they're not. And so like the BDFL model is inherently more fragile than, you know, to use the term you use, which I think is a good one, then sort of a more distributed one. But the other thing too, is that like,

standards are not inherently good, they're a tool. And so like people tend to think of them as being inherently good because like, oh, what about, you know, multiple vendors, you know, working together? And that's like kind of the thing. But a lot of people have this impression that standards are done first and then implementations follow when like actually like with standards that work well.

implementations happen and then standardization happens later, right? So to take the SQL example, it's not like the committee that, I forget what the name of it is inside of, because it's ANSI for SQL, right, I think? So the ANSI committee did not decide to introduce JSON support and then all the databases added it after it landed in the standard. They all did their own implementations of JSON stuff.

and then they came together and then put it in the standard in a way that like, you know, mapped across all the different things they did. And I'm sure some people had to adjust what they were doing in order to bring it in line with what was eventually in the standard. And that was true of, you know, C as well. Like C had a ton of different vendors building C compilers that were all incompatible with each other. And that's why originally C was also standardized under ANSI, but like the ANSI spec was a way of bringing all those groups together and having them communicate. And so,

on some level standards don't make any sense until you have multiple vendors. So there's kind of this interesting kind of like push and pull here where it's not so much that like Rust rejects a standardization process because it's bad, because it's less coherent. It's more like there was no other organization that is currently intending to ship a Rust compiler. And so like there's a little bit of, I should preface that a little bit with like there's a GCC Rust project and you know, some other things, but like they,

Steve (28:06.324)
they sort of like, they're not like full, they don't exist yet in a practical sense. Like you can obviously use them and they work a little bit, but they're not near complete. And so you really only need a standard to coordinate across multiple real implementations of a thing. And Russ is just not at the age where that's even a question yet. And so like, that's I think sort of the like most important thing, but you are definitely right that like, the fragility doesn't come from a lack of standard.

The fragility comes from only one vendor, basically. And this is like why there's a long history in Rust of its relationship with the Mozilla, where like a lot of people were very skeptical of Rust because they saw it as the Mozilla language. And the people in Mozilla knew that was the case too. And so we actually did, like, I was not at Mozilla and then I was at Mozilla and then I was not at Mozilla during the time I worked on Rust. And so I say like, we, in both senses of like the people not at Mozilla and the people at Mozilla both wanted to make sure that Rust was not a Mozilla only language because that's not healthy for the language.

And so like, as a practical example of this in the early days, the Servo team wanted to add inheritance to Rust. And we basically said, no, sorry. And they were like, well, the DOM is like, inheritance based. And so like, what are we supposed to do? And we're like, I don't know, but it doesn't fit the language. So sorry. And that's like another team at Mozilla under the same management that we're basically telling, like, we're not going to do a thing for you, sorry. And so there was like an independence there that sort of existed even while Rust was sort of a single vendor technology. And so I wouldn't...

Like, it is.

What single vendor means is interesting because like on one sense, you only have the Rust project and it's true. that if the Rust project decides to add a GC to Rust tomorrow, we got some problems, but like also the Rust project has stakeholders from a ton of different organizations. And so that's how like things tend to balance out is like, you can't necessarily think about it as being like in some level on some level, the Rust project is a standards body. You know I mean? Cause it's like,

Steve (30:08.834)
they're bringing together groups of people from different organizations to build the thing that we agree is the thing. And just because it's not a traditional standards body where it's like multiple vendors or the compiler, it's just at a different level. So like instead of like one team builds compiler A, one team builds compiler B, we get together in the standards process and we work out our differences. It's like one organization is interested in this sort of thing and the other organizations are in this sort of thing and they work through the process in the Rust project.

to produce the thing that's the thing they want. And so it's still a place where different organizations coordinate, but instead of being about shipping multiple copies of a tool chain, it's like they do the same process at one layer lower within the tool chain. And so I think you end up with the same failure modes, but you also have a little bit of resilience against those failure modes because say that the Mozilla folks really wanted to add inheritance for Servo.

like the other people who have from other companies would be like, actually, we think this is a bad design and we shouldn't do it. And then that grinds to a halt in the RFC process inside of Rust rather than in a sense of like where it would work within a standards body. And so it's kind of doing the same thing, but at a different level. And so I definitely think there are trade-offs and they're good and bad things. I would definitely not claim the Rust development process as like the best one that's ever been invented. I actually think that the JavaScript folks do a better job than the Rust project does on this front actually, but that's a...

the whole separate thing, like, yeah, like there's multiple options and it's not just about like standards good, non standards bad. You have to actually think through power dynamics and you have to actually think through who has control of what thing and in what way. And it's not that simple basically. So Rust is trying to split that difference where there's no BDFL, but also standards bodies can be complicated. And I think the bigger problem with standards bodies is their slow rate of shipping more than the inherent process of standardization.

It's the release cadence that's the problem, not inherently. Also, if get into individual standards bodies, like C++ is definitely suffering due to rules imposed on them by ISO, so I'm also gonna say it doesn't matter, but I think that the biggest problem is the cadence, not the concept of a standards body. Yeah.

Nitay (32:22.86)
I really liked the point you made there about the standards bodies and how they work. In fact, that would probably go on a limb and say that I venture that there's far, far more successful standards that came after, as you said, rather than before. In fact, I would guess that most things like where they came before are not that great a success. actually saw a talk the other day that you made me think of, which was really, really interesting, that actually broke this down at a scientific level. And it showed all of these things that are.

know like existing kind of well-adopted scientific theories and how they actually came after the invention. So for example, I'll mention a few here. The telescope was in 1600, 1608 or something, whereas the field of optics was only in 1650. The steam engine was early 1700s, but thermodynamics was until the 1800s. The electromagnetism and electrodynamics, like information theory came after like the basic signal processing stuff.

The computer came much before computer science. There's actually so many of these examples where, and I think it's because of the simple fact that in order to get a standard right, you need to understand the real usage. You need to understand what the thing does and should do or not. And if you're just sitting there pontificating, like you're always going to get it wrong, in my opinion.

Steve (33:19.971)
Yeah.

Steve (33:35.67)
Yeah, I mean, and in science it's even more straightforward, which is like science is about observing phenomena and then explaining them. So you can't have the explanation, whether the observation and in order to observe something that has to exist. sort of definitionally, you can't have information science until after, you know, computers and you can't have astronomy without telescopes existing because like you need the, you need the observation in order to do the work afterwards. Yeah.

Nitay (33:41.323)
Mm-mm.

Exactly.

Nitay (33:56.949)
Exactly. I wanted to ask you one question. said something else that made me think about something. When you talked about inheritance in the language, there's been a few cases where there's a famous joke that every language eventually adopts X or Y. So for example, generics. So go for a long time, held back, no, we're not going to have generics. Don't do it that way. Do it this other way. And eventually, basically, relented to the community. Do you find that there are certain things where like,

The standards body, like you said, like things like the committee or even the dictator, whatever, things get big enough that as you slow down that kind of iteration speed, you also just start to take on this, like, I don't know what to better call it than community debt, like all these other directions that then actually like impede and how do you kind of combat those forces?

Steve (34:45.646)
Yeah, my, favorite version of this is, uh, from 1993, which is greenspun's 10th rule, which is, any sufficiently complicated see your Fortran program contains an ad hoc and formally specified bug ridden slow implementation of half of common Lisp. And like, you know, it's like, eventually you end up there as a thing. And so I definitely think so there's there's.

So I'll say yes and no again, because like absolutely, like the bigger things get, the harder it is to change them. But I don't think that's necessarily a bad thing. Like you can't build castles based on sand. And so actually, ironically, like one of my current criticisms of the Rust project is that I think it should move even slower than it currently does.

in a certain sense that like there seems to be appetite for larger changes in the current team than there I think is like necessarily appropriate or good. Like I kind of consider the language to be mostly done. Like there is some stuff that definitely needs to happen, but like I am not interested in some larger features that like people are talking about possibly adding. But what's interesting about it is I don't worry about it because they're so large that it's so hard to change that there's like.

things that have been talked about for three or four years now that are still nowhere close to actually happening. And so it's like, okay, I don't still think that's like actually going to occur because it like ends up taking so long. So there's some aspects of that that I do think is true and natural. And I think in many cases, good. I think the lower level you get down the stack, the more stability matters because the more stuff that you're building on top of, and so therefore it's like really important that the foundations exist because you don't want to spend all your time updating your dependencies whenever you're writing a kernel.

Like it's just not, you know, it's not like a thing that's like that important ultimately. In terms of every language gets things, I definitely think that like, like that's kind of true in some ways. I think that Go probably still could have not shipped generics if they didn't want to, because like my understanding is they're still not really used a whole ton in many cases. And like, there's still some.

Steve (36:53.454)
interesting limitations around the way that they did them that are totally reasonable, but also makes them not necessarily as useful as you might immediately imagine, because a fun thing about any programming language feature is that it's like, which one of them? Because there's generics, but there's 10 different ways to do generics. And so which version do you actually have? And all that kind of stuff. I definitely think that's the case. I do think there's some aspects of, once you're within a certain language family, you end up.

probably wanting certain features that are basically standard. And so like, I do think generics is one of those things where if you have a statically typed language, you're probably gonna end up with generics, because just like, it's just too basic of a tool for people now. And so that does like kind of make sense, for example. So I don't think there's some of that. But I think that the more important thing, I guess, I of forgot about is the shipping thing and the size thing is there's a difference between like,

So I think one of the biggest insights that Rust has for programming language development is that you want to separate the release cadence from the actual pace of feature development. So Rust did not invent this idea, but it was one of the first ones, not, mean, maybe really the first is complicated, let's put it that way. Rust committed very early on to, are shipping a new version every six weeks, period.

That is like a really important development because what it means is that like, if developing a feature, like adding a feature to a language will take more time as the language gets bigger for sure. But that doesn't mean that you have to connect your release cadence to the rate of change of adding those features. And so what's happened is, is that Rust still ships every six weeks, even though features that used to take a year to develop now take say three or five years to develop.

And those two things being separate, I think is a really, really important actually. And so that's like, what I really mean by like the standards process operating too slowly is that I think that the release cadence is too slow. Not that they're like, it's hard to develop things and it's slow because it's hard because those languages are old and it takes a lot of work to make changes. It's because it like minimizes the amount of time to react to changes in the world and also means that

Steve (39:15.95)
smaller features get held up based on the bigger features timeline stuff. like Rust users are getting new APIs in the standard library every six weeks, even if say like a specialization is a feature that's been under development for a couple of years and it's maybe never even going to ship because it has some soundness problems that are sort of PhD level. We don't know if there's ways to fix them or not, of like levels of problems with the feature. If we were holding up the release of

rust for that feature to ship, there'd be multiple years where nothing would happen and no one would get any new things. But instead, people get new little fixes and new little APIs every six weeks. And that is like beneficial because it means that smaller changes get out to users faster, even if bigger changes take a long time. so like there was a lot of C++ 26 is not technically finalized yet, but it will be soon. But there was a really big situation at the end of last year because like,

there was a lot of pressure about memory safety in the C++ world. And like once C++ 26 ships, another news happened until 29. And that's three years from now. And that's a long period of time. And so, you know, there was like, there's like pressure to get stuff in before the release date, because then it's gonna slip another three years minimum. And that's, that's like a really, really long dev cycle. And so if instead the standards, like this is kind of the way the web standards moved and.

One of the things Rust has done is taken a lot of influence from the web world and bringing it into the systems world. if you notice that the web standards don't ship every three years, they ship all the time, basically, and they're living documents. And so smaller stuff gets in, bigger stuff takes longer time, but you're still shipping those smaller things continually or on a much faster cadence than bigger stuff. And so I think that really, really matters a lot. Yeah.

Kostas (41:03.031)
Steve, I want to go back to some of the stuff you mentioned at the beginning when you were talking with Nitai about the mistakes that they made there. And you mentioned, like you gave a good example, like the garbage collector there, and when you target C++ users, they have an allergic reaction to that concept, regardless of what the trade-offs are and why it should be there or not.

But moving to Rust, what Rust did right, in your opinion, to build an innovative new compiler out there, right? Introducing new concepts with memory safety, introducing new ways that people interact with the compiler, right? You have like the famous thing of like, okay, you have to fight the compiler in Rust, right? But...

Steve (41:56.299)
Yeah.

Kostas (42:00.314)
even with introducing so much change, like at the end of the day, like people adopted it, right? And it grew and grew a lot. So what were like the things in your opinion, from your experience that really helped for this to happen, even when there were things that they were so new and people have to learn and people don't want to learn most of the times, it takes time, right?

Steve (42:24.706)
Totally. The first one that I think really matters in, in rust cases, it had a legitimately unique selling position to go back to startup terminology. Like a USP actually existed. Like memory safety without garbage collection was not a thing before rust. And you sort of had always assumed like either you have a GC or you don't. And once you don't, you're off in sharp knives land and like, that's totally it. And so that like having something that was actually unique and like,

I don't wanna keep picking on D, but it's not, D's pitch to people was like, it's C++, but better. like, but better is not unique. There's tons of things that can claim to be better, but like Rust had a like actual, like real truly unique situation that is like barely been replicated by anybody else in that timeframe. There are some several interesting languages that are up and coming that I've been checking out, like Hilo for example, that.

are similar to Rust, but also are a little different, but it's becoming a thing now that other languages are starting to copy, which is great, or copy enough, or at least inspired by, or whatever, but Rust truly had something that was unique, and therefore, you want that thing, then you gotta go to Rust to get it, and so there's some of that aspect of it. But the other one that I think is important is a lot of people assume that in order to gain market share, someone else has to lose, and there's a principle that Rust folks try to follow, which is,

really good 90 % of the time and not good 10 % of the time, but it's like a refusal to accept trade-offs. like, what if, you know, a lot of times there's a lot of problems where it's like A or B and it's like, what if we could get C that's like kind of, you know, bending the curve upward? Like, what if we took the line between A and B and we like grabbed it up and we get something that's like half of both, but it's like not necessarily like a crappy version of both. Like what if we could like frame the problem differently?

in order to get a different solution. And so one of these ways is that like, you, would sort of assume like, okay, C and C plus plus exists. They're the only systems languages that matter in order for us to grow. Then it needs to take some of the mind share away from C and C plus plus. And that's like true, but only if you assume that a market is mature and is not going to change at all, but like a better way to like gain things is to grow the pie as they say in startup world. So what if instead

Steve (44:49.57)
we grew the market of systems programmers and we just captured more of the growth than the older languages did. And so that's kind of like one of the reasons why the inclusivity side of the angle matters a lot and mattered a lot for Rust adoption because basically Rust took a large, there were sort of three groups of people that were involved in Rust in the early days thought about, like there's systems people, there's like functional people, and there's what I call the like dynamic people, which is like Ruby Python JavaScript.

people basically. And so two of those three were not groups that were traditionally involved in systems projects. And so therefore, you know, we could like have a new generation of systems programmers that are interested in doing low level work that are simply not being served by an existing, you know, product on the market to continue to be too startupy about it. And so like, what if we instead just brought those folks into this space and then they were all ours. And so it's not so much that C and C++ need to suffer and die for us to succeed.

we'll just go get people that aren't even systems people and turn them into systems people. And so that's like, you know, also similar to the what Go found in many ways is that like, you you just, it's not necessarily about taking mindshare away from existing users. Sometimes it's about just finding whole new groups of users. And so it turns out there's a lot of people in the world who wanted to do lower level projects, who were super intimidated by all the aspects around low level programming, both because it's like techniques they're not used to.

the machismo that's involved often in those kinds of spaces and like a whole bunch of other stuff. And so what if there was like a place where they could try stuff out and feel okay about trying stuff out and like the fighting compiler thing is kind of funny because it's definitely a thing people say, but I like to think about it as like a friend who's stopping you from doing something stupid. You know what I mean? And so like, it's like, it's like a thing you work with, not like against.

basically, like it's more of like, you know, catching your mistakes and then providing you with guidance. so several different people throughout the years got very invested in making Rust error messages really great because it was like, you know, people are going to run into the compiler yelling at them all the time. And so what if it was like a helpful friend instead of a person yelling at you? And so like, you know, a lot of people,

Steve (47:01.292)
have found that like the compiler's guidance in the circumstances what lets them do these projects they've never done before because when they write scenes to the plus the compiler doesn't yell at them but then the program blows up and they don't know what to do. Whereas with Rust, they kind of have somebody to guide them automatically in a way and so they end up finding it easier because of those constraints. And so, you know, that's kind of it. But I think that's like also a big shift in what Rust managed to do and why it was successful is because basically of that. Like it found an audience that was sort of wanting what it was selling.

but they weren't going to existing solutions. so we didn't need to be like C++ is terrible and you should stop using it. It was more of like, we're gonna be over here building a cool thing and if you wanna join us, it's fine. If you don't, that's also fine. Keep using the tool you like. If you like it, we're gonna be doing this other thing. And it turns out there's just like a lot of people over here that were never gonna come over there in the first place. Yeah.

Kostas (47:53.912)
I have to add something from my personal experience with Rust and what you are saying. So when I first started to use Rust, I was coming from the JVM world and I was primarily writing in Scala. And the first time that, and by the way, it had been like, I don't know how many years that I had to deal with memory management. So it was almost like...

I had to get myself reintroduced into the concept of, there's memory there, but you have to care about. But when I, I started with the try like to do something like in Rust the first time, there were like a couple of things that, and they resonate like a lot with what you're describing. So first of all, trying the, first of all, using cargo, I think like the tooling and how.

Steve (48:26.188)
Yeah.

Kostas (48:48.536)
easily was, especially coming from the Java world with Maven and all that. my God, shitting there to make something work. Using Cargo to just go and initialize a new project and start writing something. And actually, the system guiding you between a lib and an app and all these little details that might sound not important, but actually they are.

That was like very refreshing. And the other thing was like the compiler, right? Because I almost had a little bit of like a co-pilot kind of experience with it for the first time in my life because we didn't have co-pilots back then, but I was getting like an error and I was getting a suggestion about that. And I was like, how, like how much work do you have to put to actually build? I have no idea. I'm literally very curious on how you build such a complex system.

Steve (49:30.305)
Yeah.

Kostas (49:46.844)
that can provide in a very deterministic way. We're not talking about the low lens here, right? This kind of like suggestions and guidance to like go and solve something. And as you said, like, okay, yeah, it was frustrating because like I wasn't just running something. I was getting these weird errors about ownership and blah, blah, whatever. was like, well, what ownership? But it did...

Steve (49:51.18)
Yeah.

Kostas (50:15.39)
feel like you have like a companion, let's say, right there. So I have to add that to what you said. But I want to ask you question because you said something about like there were like three categories of like people. You have the functional people, you have the systems people, and then you have the dynamic people,

Steve (50:26.947)
Yeah.

Steve (50:35.821)
Yeah.

Kostas (50:43.004)
I have a feeling that each one of them was attracted to something slightly different. I'm sure like the systems people already were caring about memory, like management and safety, something that I didn't have to worry for many years, right, myself. So what was like for each one of them that, let's say, really resonated with the language there and they made them like to keep using it and work with it.

Steve (51:08.462)
Yeah, yeah. Uh, I do want to talk about that incredibly briefly. First, you're talking about like LLM like output is like another one of my favorite stories. I could tell really briefly about this process. Like, so we were designing async await. There was a big controversy over the await keyword because it was like, do you put a wait space and expression like in JavaScript or do we do expression.await? Cause like chaining methods is good. And like, if you have multiple things, like that's a problem. So there was a big argument about like, do we do the familiar thing or do we do the new thing that we think is better?

And so one of the big arguments against the new thing that was better was like, we have a lot of users coming from JavaScript and they're going to get confused when it doesn't work the way that they work like. And so maybe we should like pick the standards in text, even though it has downsides because it's more familiar and that would be a good idea. And so the idea sort of came up, I don't know exactly who pitched it originally, but it was like, let's just make the compiler parse the JavaScript style too, and then give an error.

telling you exactly, hey, by the way, this isn't how you write a wait, you put it at the end. And so that's like the kind of work that sort of needs to be done is like sometimes it's about like, I say documentations about empathy, but also error messages are often about empathy where you need to figure out like, okay, what is the person thinking when they encountered this error? And then how do I tell them what they need? And so that became the trade off is like making the compiler a little more complicated, but if it is able to tell you like literally like, don't do that, do this instead.

then it's a teaching moment and you're done and you can just not worry about people being confused because you've solved it through tooling. And so that's a good example of the bending the trade-offs attitude is like, okay, we the familiar thing and the new thing, what should we do? And it's like, well, why not both kind of, because we'll accept that old thing that's familiar, but then point them to the new thing in the error message for the old thing. So that's kind of a cool thing. Okay, on the trade-off, the trade-off groups, yeah, so.

A related thing that's very funny is a lot of people are like, well, Rust and Ruby are totally different than each other. Why would you go from Ruby to Rust? And I'm like, I don't know why I would want to learn a second language that's close to Ruby. I want to learn a new language that gives me totally new capabilities. And so that's the way I would say about like the dynamic language people is they were interested in Rust because like you often, often is a bit strong.

Steve (53:13.526)
it is relatively common for there to be C extensions to Ruby and Python and JavaScript because you need to have some sort of capability that either they don't have in a library or you need some performance aspect that you need a native code to be able to do that, native code, quote unquote, whatever, doesn't matter. So that was the appeal to them was like, can gain, some of the first conference talks I ever gave about Rust were at Ruby conferences talking about how could write C extensions in Rust instead of in C.

and how that would be like a better, nicer thing for you. And in fact, the very first production use of Rust ever really was actually a C extension to a Ruby program. And so that was like a sort of big early sort of pitch to those people is like, you you never write C extensions because you're a little scared to see what if you didn't Rust instead, that'd be cool. And so that was like the problem that Rust was solving for them. The advantage is actually related to when you mentioned cargo being nice to use.

Cargo basically exists because Dave Herman at Mozilla was also involved in TC39 and JavaScript, basically said, we need to build a good build tool and this isn't gonna succeed without it and so I wanna make this happen. And so he contracted Yehuda Katz and Carl Lurch who wrote Bundler for Ruby to sort of write Bundler for Rust. And what's very funny is that I remember at the time this was announced, a lot of the systemsy people were like,

well, we're not gonna use your fun little toy, we're gonna use make files, because that's the real thing that people use. And then they were like, wait, this is amazing, and I don't need to write any make files, like, my god, yeah, I'm gonna use Cargo now. And so the thing that the dynamic programming people brought, I always like to frame these audiences like, what do they get, and what perspective do they bring? And so the thing they got was a lower level language that could do things their existing language could not do, and the thing they brought was a perspective that you can have nice things.

Like I used to joke that like the Ruby contribution, the Ruby community's contribution to Rust is mostly systems programmers, your life does not have to suck, your tools can be good actually, like you don't need to suffer, please just use good tools instead of bad ones. And not even bad ones is a little strong, but like easier to use tools than like ones that are harder to use. So that's kind of the perspective that they brought. The functional people, so actually Scala is probably mostly represented here, maybe a little bit of Haskell. A lot of the sort of people on the language team, if you look at their PhD theses, they're almost all in Scala actually.

Steve (55:31.988)
actually, so there's definitely sort of a connection there. Functional people was kind of similar to the dynamic people in that, you know, they often need to do systemsy tasks and functional languages are not often used in systemsy cases. And so that was good. But the perspective they brought was on type systems and why type systems are cool. So early Rust was actually significantly more runtime heavy. Like we actually had, it was very go like back in the day, actually in many ways are Erlang like where there was a runtime.

and channels and threads were like language features and there was even a GC in the earliest versions of Rust because it sort of hadn't been discovered yet that you could do these things without that. And so, cool thing about types is they operate at compile time and then they go away. And so, if you can move safety checks to compile time, then that means you have no overhead in runtime. And so, kind of what they brought was advanced type system knowledge that's like necessary to make low overhead stuff work. Like the only reason the systems language can have memory safety without GC

because you do the type stuff to check all the types to make sure everything is okay. And so that came from functional languages. And so one of the ways in which Rust evolved before 1.0 was moving more and more things out of the language into the library and then out of the library and into the type system. And so the functional perspective was very, helpful there. And the systems people, the problem they had was like...

while C and C++ are fine tools that have been used to make a lot of software, obviously they have flaws and like we can do better. And so they wanted a better language to be able to do their kind of things. And the perspective they brought was the classic no runtime overhead performance oriented, like all of those kinds of things, like the ability to do things, you know, and not rely on the language providing them for you, but being able to do them yourself, all those kinds of perspectives that made Rust that way. And so it was sort of those.

those three groups all needing something and all giving something that kind of made Rust into what it is.

Kostas (57:26.553)
So today someone who wants to start with systems, is the reason to still go into C++ instead of a language like Rust?

Steve (57:40.206)
Yeah, I mean, there are some people that argue what I would call Protestant programming, which is they're like, you need to suffer so you understand the problems before you can appreciate why Russ is better. And so they argue that you should write C and get a bunch of seg faults because otherwise you'll never understand what Russ is trying to make you do. I don't think that suffering is required for enlightenment. So that's not the argument that I will make, but some people do make that. And maybe there's some people that agree with that perspective. There is like,

there are more Rust jobs than you expect. Like a lot of people search Rust jobs on a job site and they find not many and like what's going on, but like not a lot of Rust jobs don't advertise that they're Rust jobs. They're just jobs that you happen to use Rust in. so like, but it is true that there are more C and C++ jobs than in most languages, frankly, because they're still massively used. And so a good reason to learn C++ stuff today still is because you want to get a job in an industry that is primarily C++ like.

Rust is only now starting to make inroads into truly safety critical systems like automotive and aerospace and stuff like that. And so, know, if you're gonna be writing firmware for an airplane, you'd probably better know C and or C++ because that's what your job is going to require of you in the next, you know, into the future. Like obviously, maybe in 15 more years, we'll be talking about how most of those jobs are Rust, but for now, like those jobs are all in those languages that matters. I think another reason to learn those languages is just frankly, learning new languages is good.

I think it's important that people learn as many languages as they can stand because every language brings perspective into what you're trying to do and the way that things are. And so I think it's valuable learning languages just inherently on its own. And so I would definitely not discourage anyone from trying to learn a programming language if they want to because you just always should. So like that seems good. And so yeah, like all those things I think are like good reasons to still do those things. Yeah.

Kostas (59:33.62)
Sounds good. Alright, we are at the end here and I have one last question. So you mentioned at some point that there are some new languages that draw inspiration from Rust and the projects that you are interested in. Tell us a few of these that you are really interested in and people can go and check them.

Steve (59:56.15)
Yeah, so the one I'm most interested in is called Hylo, H-Y-L-O. It is a language that, it changed its name a year or two ago. It used to be called Val or Vale, but there's also another language called Val or Vale, and so they changed it so it wasn't so similar, because it's like two languages with only one letter difference between them is like too close to each other. So Hylo is very interesting because it describes itself as like there are no references, but that's not what I would describe it as. I would describe it as,

what if you could not return references from functions or store references in structs? How simpler could that make Rust as a language? And so that's kind of like the idea is that it still has no GC, it's still very low level, but it like restricts a little bit of what you can do, but the sort of the idea is like it may significantly make the language much simpler and easier to use. And so that might be like a good trade-off to make. So I think that's a very interesting area of the design space. It is still very, very young.

and they're working on stuff, but I think that one is by far and away the most interesting to me personally. There's another other languages that are sort of systemsy languages, but they're not as focused on the safety issue that Rust is, and I think that that is like a critical thing for future languages to care about, and so it's like unclear to me if that's a good idea, but I do think they're interesting on their own. Again, you should learn languages just to learn them, and so.

if you're kind of interested in new upcoming languages that are kind of cool. The first one I to mention is Zig, of course. know, Zig has been getting a lot of popularity as a newer language, and it's still pre-1.0. They do a lot of stuff to mitigate safety issues, even though they don't promise memory safety, and it's still, you know, if you want to write memory on safe things that cause Zag vaults, can pretty trivially, but the argument is that, like, that...

do you have enough tools to make it safe enough that that's not the problem. And there's a lot of other really interesting ideas around like comp time instead of generics. I personally still think generics is better, but it's cool that people work through ideas and it's good and some people prefer it. So that's kind neat. And it's compilation and tool chain model is very, very interesting and neat. So can't say enough good things about Zig. There's also languages like Odin, which is kind of largely in graphics, but is also kind of a sort of

Steve (01:02:13.686)
newer, smaller, simpler language that kind of argues you can get by on these things for those reasons. And so those are definitely like my top three. I'm really interested in Jai solely because I disagree with Jonathan Blow about almost everything and I don't really think he knows the history of program languages that well and that means he might come up with something interesting because like sometimes like outsider art is good and sometimes it's very bad.

And so Jai is either gonna be very boring and not very good, or it's gonna be very interesting and very cool, and I'm not really investing any time in it until there's an actual open source release eventually, but I'm kind of watching that one from afar. I disagree with almost everything that he does and says, but I don't know, maybe that means he'll come up with something kind of cool and interesting, so we'll see. So yeah, I definitely think those are the big, there's also, yeah, Val, or Vale, or Val, whichever one that was not the one from,

Hilo, but that author is on hiatus for a while, so it's unclear if that's gonna get finished anytime soon. And I feel like there's at least one other one based on linear types that I'm totally missing because I don't think that's actually Odin, so I'm feeling kind of a little bad about forgetting the name of that one, but there's definitely some language that fits in that space that's kind of like, if Rust has a thing called affine types and linear types are slightly stronger? And so it's kind of like, what if Rust, but with Pascal syntax and with linear types instead of affine types? And I think that's pretty cool.

I feel like it starts with an O, kind of like Odin does, but is not Odin, so I don't know what the deal is there. yeah, so check all that stuff out.

Steve (01:03:52.236)
I'm not gonna Google that really quick, because I'm now just like, what is the freaking language that does it? Austral, A-U-S-T-R-A-L. So that is like a cool language that I think is interesting. I don't like Pascal style syntax, but I am really interested to see linear types plus systems language, if that works out in general. Syntax is the least interesting things from a programming language theory perspective. And so I don't know if it'll be successful based on syntax, because people care about.

the fashion and syntax of languages, but from a like the semantic side, I think it's really interesting. So we'll see how it works out.

Kostas (01:04:26.962)
That's amazing. Thank you so much, Steve. I think when we before we started recording, and we were brainstorming a little bit about like the topics that we will discuss. I think we have at least another five or six that we didn't even like that's here, which is a good thing. It means that we have some very interesting things to talk about. But also, you have to promise us that you will be back because we have more things like to talk about. So

Steve (01:04:42.808)
Yeah, yeah, totally.

Steve (01:04:53.186)
Yeah, totally. Let's do it.

Kostas (01:04:56.478)
Thank you so much. That was amazing.

Steve (01:04:59.16)
Thanks for having me. was good time.

Nitay (01:05:00.837)
Thank you, Steve.