The Changelog: Software Development, Open Source - Hare aims to be a 100 year language (Interview)

Episode Date: December 6, 2023

This week on The Changelog we're joined by Drew DeVault, talking about the Hare programming language. From the website, Hare is a systems programming language designed to be simple, stable, and robust. When we asked Drew why he created it, he said "[because] I wanted it to exist, and it did not exist." Wise words. We discuss Hare (of course), why he's so passionate about all things open source, the state of the language, fostering a culture that values stability, and oddly enough — what it takes to make a peanut butter and jelly sandwich.

This week on The Change Lab, we're joined by Drew DeVault, and we're talking about the HAIR programming language. From the website, HAIR is a systems programming language designed to be simple stable and robust and when we asked drew why he created he said because i wanted it to exist and it did not exist wise words and hair has some big ambitions it aims to be a 100 year language which we get into in the show why drew is so passionate about all things open source the state of the language currently fostering a culture that values stability, and oddly enough,

what it takes to make a peanut butter and jelly sandwich. A massive thank you to our friends and our partners at Fastly and Fly. This podcast got to you fast because Fastly is super fast, super fast globally. Check them out at Fastly.com and our friends at Fly will help you put your app and

your database closer to users all over the world with no ops. Check them out at fly.io. What's up, friends? This episode is brought to you by our friends at Neon, on-demand scalability, bottomless storage, and database branching. And I'm here with Nikita Shamganov, co-founder and CEO of Neon. So Nikita, imagine you are a tour guide. Give me a tour through the world of Neon. So let's look at a modern developer. As people say, never bet against JavaScript.

So more than 50% probability this person is writing JavaScript and TypeScript. Using React, Next.js, deploying their code on a platform like Vercel, and really care about design. So working with Figma, working with a local designer, or maybe starting to work with an AI designer and using technology like Vercel just shipped called BZero. And then you got to store data somewhere. So you go to Neon or use Vercel Postgres, which is powered by Neon, you push a button, and now you're able to write and read from Neon. And then that kind of just works out of the box. The majority of your time you spend crafting your application, crafting the front end, and then the database is just kind of like, it's just kind of there and just kind of works. And you don't think too much about it.

And when you run previews, when you run next versions of your software, you can send your collaborators, your other engineers on your team, or your product managers or designers, a version of your app, the version of the future that you want to debate if you want to comment on, and it's fully sandbox, you know, from your front end to back end to the database. That's like a good part of this world. The world is obviously much bigger than just building front end apps. There's also back-end apps, there are Python apps, there are Java apps, and all of those things. We're perfecting the world for the world that I just described. And we think that the rest of the world will follow.

And the rest of the world is Java apps, REST apps, back-end apps, queues, scheduling, AWS Lambda, Kubernetes, containers. Again, the tech world of the back-end is just enormous. But I think perfecting this first world that I described will create a standard in developer experience that the rest of the developer world will just follow. So you have Vercel, Postgres, Powered by Neon. You've got Neon as an integration to Vercel. You've got Neon out there at neon.tech as self-serve

where anybody could just go and sign up and start up right now. You're optimizing for this new standard. But what's the response been like? What's the community saying? What's the community's response? We are lately onboarding close to 2,500 databases a day. That's more than one database a minute of somebody in the world coming to Nian

either directly or through the help of our partners. And they're able to experience what it feels like to program against database that looks like a URL and the program against database that can support branching and be like a good buddy for you in the software development lifecycle. So that's exciting. And while that's exciting, the urgency at Neon is currently is unparalleled. There you go. If you want to experience the future, go to neon.tech,

on-demand scalability, bottomless storage, database branching, everything you want for the Postgres of the future. Once again, neon.tech. Well, we are here with Drew DeVault from SourceHut and from here, the programming language. Drew, welcome to the show. Hey, thanks so much for having me. We are excited to have you.

I love ambitious projects. I think anybody who has ambitious projects finds their way on this show relatively easily. And so this one was kind of a no brainer for us. First of all, I've been reading your blog for many years. I was just scrolling your blog today in preparation and I saw a lot of purple on those titles as it's just like all your posts are on one page and then, you know, the old, the old visited visited attribute i'm glad you like it html was paying off so lots of stuff we've linked to you out in changelog news and stuff so your reputation preceded itself with us i didn't know what you were up to with hair until you reached out this aims to be a 100 year programming language i mean that's that's

ambition right there so let's start with that why guess, why 100 years and how we'll follow? Well, the basic idea behind the 100 year language is that, you know, hair is more conservative. So you have languages like Rust, which is working on experimental and interesting stuff like the borrow checker, and you have Zig doing its comp time thing. I think the distinguishing feature for hair has less to do with like the concrete features and new stuff you get and more to do with setting stability as a goal. And I don't think a lot of other projects are doing that.

So we want it to be something which can be completed and then depended on and used to build software which lasts a long time. And I think that's what distinguishes hair for that purpose alone. So that I understand, but why do you have that goal? Why do you want to build software that lasts a long time? Can't we just continually reinvent for the modern era? You know, I think there's a lot of value in continuous innovation of that sort, but I also think that there's a lot of value in, for some some projects choosing longevity as a goal instead. And so like, you know,

if you're running Linux, for example, you're going to have a hard time getting a binary compiled four years ago to run on your PC today, because there's this kind of continuous change going on. And a lot of the time change is good, but a lot of the time we don't really need it. You also have a bunch of stuff, which hasn't really changed in a long time. Stuff like your core utilities, your shell, a lot of things like that are still good without that continuous integration. And I think Hera is kind of targeting more of that stuff than the stuff which is really innovating and pushing the boundaries of the ecosystem. What made you kick into it in the first place? What made you decide to start a programming language? I started here for the same reason i start all of my projects which is that i

wanted it to exist and it did not exist okay okay but why why did you want to exist what's the why behind that okay yeah you're right so basically i have all kinds of ideas of stuff I want to work on because I find it fun or interesting or useful to me. And there was a lot of stuff I wanted to build that I felt that the tools I had available to me at the time were not really ideal for that purpose. And so, you know, I'm yak shaving.

I had to invent the programming language to make these projects that I want to write with it better. Okay. Going all the way back to the language itself. So this is like echoes of Serenity OS to a certain degree. Well, I'm also using hair to write an operating system for what it's worth.

I had a feeling you might say that. Yeah. Okay. So bare metal. I mean, you're just invented from the ground up, you know, to create a peanut butter and jelly sandwich from scratch. You must first invent the universe. Yep. And hair is part of that universe for you.

Yeah. Hair is made out of hydrogen and time. Love it. Stardust. Yes. There you go. So how do you put actual peanut butter and jelly sandwiches on your plate? Assuming that you eat peanut butter and jelly sandwiches on your plate assuming that you eat peanut butter and jelly insert your favorite you know i don't really eat peanut butter and jelly it's like a habit but i'm not opposed to it and if i were asked to make a peanut butter and jelly sandwich i would go to the store and buy the ingredients and make a peanut butter and jelly sandwich i would not start a farm okay all right that's good to know we're on the same page there are you asking me to make you a

peanut butter and jelly sandwich that would be a roundabout way of asking, wouldn't it be? It would be, yeah. This guy's very passive aggressive. He wants me to make him a sandwich, but he won't even pseudo make me a sandwich. No, I'm just wondering, you have these huge ambitious projects that you start ground up, and you want them to exist, and you're creating them. And I'm always wondering, well, then how do you eat? And how do you sleep? And how do you do the other things that humans have to do to remain alive in the meantime? Is SourceHut your business? Is that how you're making money and this is on the side? Does this play into the business somehow or how does it all work? Well, it's kind of vague, I suppose. But SourceHut is a business. It's a profitable business and we

publish our financial statements every year. But it is a business. It's a profitable business. And we publish our financial statements every year. But it is a business which employs myself and two other employees for the purpose of building exclusively free software. And it has this revenue model where it has a platform and people can pay for accounts and they use our software on our infrastructure so that we have the infrastructure expertise and we have the capital investment for buying a bunch of servers and so on. And then they just pay two bucks a month. It's a pretty good deal.

And the software is still free. But that's kind of like a tool that I designed along with the help of my colleagues to enable us to build the free software we wanted to build, to build the free software we thought was important without necessarily thinking about how to pay for it. So this stable revenue, we work in the platform, we expand the platform, we build the platform, but it's one of many projects we have. And we work on the stuff we think matters without necessarily

finding a financial incentive. And because we do it in this framework, we can eat. Sometimes those projects end up providing some kind of financial or revenue stream, and sometimes they don't, but we're not really thinking about that. Like we built some IRC tools, for example, for internet relay chat, because we thought it was important and it needed work in that ecosystem. And then it turned into something that we started to be able to sell. And sometimes that happens and sometimes it doesn't happen. But at the end of the day, we're making money doing free software.

And that's really what we want to do. Yeah. Can you expand on who the we is and what you're optimizing for as a team? Yeah. So it's myself, my colleagues, Simon Surin and Conrad Hoffman. And it's just the three of us. We occasionally have contractors that come on board to help out with this or that. But we're the full time employees.

And our goal, again, is it's very kind of self-directed at the discretion of our engineers. So we work together on what we think is important together, and we work independently on what we think is important independently. And we also engage with the larger community. So we're full-time maintainers of our own projects, and we contribute to a wide variety of projects in the ecosystem. So our motivations and our structure is essentially the same as any other free software contributor. So we work on what's important to us or what we care about or what we depend on. But we've built a structure wherein we can engage in that kind of work and make money from it. Are you all close geographically?

No, we're all in Europe, but we're distributed. We don't have an office or anything. Gotcha. So like any internet thing or open source or FOSS project, you've got collaboration on the internet, basically. How did you get to alignment with views on software? Did it just naturally come about? Or did you all sit down and say, hey, this is how I feel. Do you feel this way?

And wow, we should do this together. Was it just like that or was it different? Well, I started the project and then I reached out to them through my existing network of free software projects that I was already working on in my spare time. And I was like, hey, I think you'd be great for this. Do you want to work together with me on it? And so it was kind of self-selected by reaching into the FOSS communities network for people who believed in the mission of free software. What makes you believe so deeply?

I mean, this is kind of like to some degree maybe obvious, but what makes you believe so deeply in open source software? And, you know, in the pre-call you asked if we can creative commons this podcast and we kind of said no in one way, but yes in another. Because we're all about free and open source software and sharing and remixing and collaborating. But what makes you really feel deeply about that? Like what happened in your life to make you feel like, wow, this is the way it should be. And I want to make sure that my life's work is involved in that. You know, I love writing software. And so I was always going to do that and doing it in the context of free software for me you know from a practical point of view it's the best way to write software because it's efficient and it works and you get high quality software and you can tap into a whole bunch of other people who

are interested and you can collaborate on stuff in a way that's not feasible especially at a small scale for non-free software. And from like a philosophical or like inspirational point of view as to like why I do it in my soul, you know, I believe it's right. I believe in the virtues of free software, but also like there's this moment sometimes which really connects with me and reminds me why I care about free software, where I could be working on a website in the morning, and I could find a bug that I needed to work on. And by the evening, I'm knee deep in the Firefox code base because it was a Firefox bug. And then I ended up in HarfBuzz because it has to do with text rendering. And then I end up in GCC because turns out there's also a compiler bug.

And I like having this autonomy and agency over all of my software, whereas I can take responsibility for the operation of my system. Because if I have a problem or if I want to change, I can go to anything that I use in terms of software, read the code and make the change that I need. And then I can contribute it. So everybody benefits from that. And that's a kind of autonomy and a level of, you know, the right to take responsibility for computing that I think is really important to me and completely impossible if I use proprietary software. So a source hut, a response to GitHub, GitHub being a proprietary piece of software that hosts many free and open source software projects, but not itself free and open source. Was SourceHut a response to that or is it just like you had a better way of doing it?

What was the impetus behind SourceHut? You know, it's something of a mix of all of those factors. So even when I started SourceHet, there were existing free software solutions which were seeking to be competitive with GitHub. So like GitLab, for example, already existed and Gitia and a number of other platforms as well. Something that kind of like GitLab and Gitia and a couple of others have in common is that they're really forward about trying to compete with the GitHub market on GitHub's terms. And it's a little bit disingenuous to say this. I know that these platforms have their own appeal

and their own design sensibilities, but to some extent, they're all clones of GitHub. And so Sourcet is not a clone of GitHub. It is what we believe is a better way to write software. It's inspired by the way Git was designed to work by Linus Torvalds, the way that it's used for Linux kernel development. And we have a philosophy of working on free software with a workflow that we have built into Sourcehead, which is distinctly very different from the GitHub workflow. And so it's its own thing. And we think it's important that it's something, but it's also to some extent, a response to the fact that the majority of open source software is using a closed source platform. And we do believe that's very important for free software projects to depend on free software infrastructure.

So what does it feel like then from a person who's used to using a GitHub or GitLab style collaboration around pull or merge requests and that whole deal? What does Sourcehut feel like to use as just a day-to-day programmer? SourceHut is much more distributed and decentralized. You know, the promise of Git is decentralized version control, and SourceHut kind of embraces that. You know, the old cathedral and the bizarre metaphor, you know, Eric Raymond is a character. We don't need to open that can of worms.

But the metaphor, I think, is very good. I think that GitHub is kind of built around the cathedral analogy where you have the repository with the pull requests and the issues and you go there to GitHub to interact with it. But Source Set is much closer to the bazaar because we use email for sending patches. So you don't go to the website and click send pull request you send an email with the code and git comes with built-in tools because it was designed for this workflow to facilitate collaboration over email and so personally i mean i am the founder of source set and i designed it from the ground up and i um i actually rarely look at it because it's designed to integrate with all kinds of other tools. So like the main way that I work on Sourcet or with projects that use Sourcet is through my mail client, through IRC, things like this, because it's designed to interoperate and to centralize. Do you like using mail for source code collaboration?

I love it. It's so much more productive. And to the point where I wrote my own email client to make it even more productive. Of course you did. Of course. I love it. I love it.

Okay. So awesome. What makes you love mail? What are the attributes that you love about the process? You know, there's a lot of stuff to love about it, but I think the most compelling reason is just that it's a much, much, much more efficient workflow. I sometimes give an example of like, assume you don't have a GitHub account and you want

to contribute some code. You need to have an email account first and foremost. So that's a free oracle that we share, but then you need to go to github.com and you need to register for an account. You need to confirm the account and you're going to switch from your web browser to your mail client to your web browser. And then you're going to make a fork of the repository. You're going to click some buttons on your web browser. Then you're going to come back to your code and you're going to use your editor, your

terminal or whatever. And then you go back to the web UI and you click open pull request. And it's the same for reviewing pull requests. Whereas if you use an email-based configuration, you set it up once and then it's one command get send dash email to send a patch so you just write the code you commit the code you run one command and you're done with your contribution and from the maintainer side it's even faster because i i get so many emails i have right now in my mail client here something on the order of 500 emails, which mostly are patches that I need to review.

And I could not cope with that level of workload if I didn't use this workflow. I can get through those 500 patches in like two days with the email workflow. So I'm an inbox zero guy. Couldn't handle it. Couldn't handle it. But oh, I'm an inbox zero guy too. I just have 500 emails in my inbox those are all actionable in the near future okay so you're a inbox zero guy who's drowning at the

moment i don't know i'm not drowning it's manageable because i use this workflow so you're more of an inbox 500 kind of guy then i guess if it works for you volume jared i mean imagine if you contributed to hundreds of open source projects and you maintain large projects like the hair programming language and source said, yeah, and all of the work on that was through emails, you would get a lot of emails, but the workflow makes it very efficient to work with those emails. Absolutely. You know, I like about you so far, Drew, is you make everything sound so easy, doesn't it? It's like, well, we work on what we want to. Sometimes it makes money. Sometimes it doesn't. But, you know, I and we work on what we want to. Sometimes it makes money, sometimes it doesn't.

But, you know, and I just use email. I don't use anything else. And it's super efficient and life is good over there. I mean, it sounds very nice. I mean, it's not easy. And I don't want to make it out to be too easy. But there's also a big element of luck. You know, there's the hard work to figure out

how this way of writing software is possible, but there's also not everybody has the opportunities to do that. And there's a lot of luck involved. So it's, you know, it sounds easy and honestly, I'm living the life, but I understand that, you know, this seems like something that's a little bit unachievable to some people. And I respect that. Yeah. A lot goes into it. There's luck, there's talent, there's hard work. There's all sorts of things that get people to where they are, but you're here now. You're working on a lot of stuff. It sounds like, but hair is what we're here to talk about because again, seems

like the most ambitious of your projects. You're trying to create a programming language that outlasts yourself. Probably quite a ways. Well, it's a hundred year language so i'm only 30 i don't know how much we can say it's going to outlive me by a long time okay hopefully by a short time well let's not split hairs on that one pun not intended but always appreciated when i stumble across one if you're going to create a programming language to last that long it has certain attributes that you're going to prioritize can you enumerate those for us? Like what, first of all, has there been one? I mean, C is pretty old.

Yeah. C is 50 years old. It wasn't designed to be, but it had a lot of traits, which made it possible for it to have that staying power. Yeah. Okay. And it'll probably make it to a hundred. Don't you think? I bet it will. Yeah. Yeah. So what, what are some attributes of C then that are good or that you're, that will be shared by hair? You know, there's a lot of things hair does differently because C was never designed to have this staying power. And with hair, it's a choice that we've made to try for that, which is an ambitious choice in my network, but we're trying it.

But, you know, some of the things I think about C that gives it the staying power is it's incredibly flexible. Many people would argue it's too flexible and I would agree with them, but it can be applied to a huge variety of problems and it's exceptionally portable and it's standardized. And I think all of these things work together where, you know, we had the accident of Unix, which kind of made C indispensable, but also it had these other traits that I think helped to make sure that it would become popularized and useful for a wide variety of applications that are very important. Like there's few programming languages you can write a kernel in. You're not going to write

your kernel in Python. And so we need a language that does something like C in order to build everything else on top of. And the things that C does tend to need to be reliable and last for a long time. And so C tended to end up being the language which best fit into what those low level components needed. Okay. So what are some design attributes of hair? Maybe give the baseline, like what it is as a programming language. And then we'll talk about the specifically the 100 year aspect of it, which I'm sure is a huge part of it but like what does hair look like or feel like as a programming language first yeah so hair is um it's a systems programming language uh and it compiles down to machine code and you can you can use it for a whole lot of low-level use cases for that reason i'm writing this kernel with it and we're doing

a bunch of other stuff along those lines of thought. You know, it has the syntax, which comes from the C lineage. It has, you know, braces and it has postfix expressions, you know, these kinds of things you would expect from a C derivative syntax, like JavaScript, Java. These are similar syntaxes. And it gives you the tools you need to do a lot of the same stuff C does. So it can feel like you have the power of C, but it also has, you know, 50 years of hindsight that C didn't.

And so it has a lot of features which kind of address paper cuts in the space that C is occupying right now. Like we have better error handling through tagged unions. That feels very comfortable to use. So you can write more robust code more easily. We have things like slices, which is a

sorely missing feature from C. We have better string support. And we have a handful of safety features nowhere near what Rust does, for example, but things that were sorely missed for C programmers. And we let you take the training wheels off as well. So if you need to do something, you know, in a kernel context, writing a driver with unsafe memory patterns, it's easy to do that in hair. And then we also have a standard library for hair, which is, in my opinion, significantly better than C. I think one of the wordiest parts of C is the standard library. And with 50 years of hindsight and a bunch of other languages for inspiration, we were able to come up with something a lot better. So you mentioned Rust. There's been large pushes in the programming language community,

especially amongst web people, to rewrite core infrastructure in memory-safe languages. A lot of that work is being done in Rust. We were just speaking with Ben Cohen a couple weeks back from the Apple team. He thinks that Swift is a decent choice for that. Zig now is making waves. I mostly heard about it because of the Bunn JavaScript runtime written in Zig.

I hadn't previously even heard about Zig, but it seems like it's very much playing in the same pond. Yeah, I'm actually, I collaborate sometimes with Andrew Kelly on like programming, they misdesign decisions and so on. We have similar goals. Okay, interesting. So he's actually on my, I have open tab of Andrew Kelly dot me right now. He's on my list of people that we'd love to talk to at some point on the show. Did you know about Zig when you started here? Is it spiritually aligned enough that you could join forces or their design decisions you've

already made that kind of make them two separate ideals or what's the situation there? I mean, we do have different ideals. Zig predates hair and I actually, um, investigated Zig and was fairly optimistic about it as like, maybe this is the answer to the problems I'm trying to solve. And I didn't think it was, I think Zig's a really cool language with a lot of cool ideas. And it was the, one of the closest things I found to what I needed, but it wasn't quite there. And hair is different in many ways, especially in terms of design and philosophy, but the languages are capable of similar things. so i'm here with ian withrow vp of product management at century so ian you've got a developer-first application monitoring platform. It shows you what's slowed down to the line of code.

That's very developer-friendly and is making performance monitoring actionable. What are you all doing that's new? What's novel there? Traditionally, in errors, what's the strength of Sentry is we've taken not a stream of errors and said, hey, go look at this, like all these error codes are flowing into says, we actually look at them, we try and fingerprint them and say, hey, we've actually grouped all these things. And then we give you everything you need within Sentry to go and solve that error and close that out. And that's, I think, driven tons of

value for our users. And traditionally, if you look at performance, it's not that thing. It's looking at certain golden signals, setting up lots of alerts, maintaining those alerts, grooming those alerts, and then detecting them. And then maybe you have a war room and you try and look at traces, or maybe you realize, oh, it's this engineering team that owns it. Maybe they'll look at logs or whatever they have available. Performance is very rotated on detection and then isolating to where the problem may exist. And root causing is often an exercise left to the user. Good performance products provide a lot of context and details that an experienced engineer or DevOps professional can kind of

parse and make sense of and try and get to a hypothesis of what went wrong. But it's not like that century era experience where it's like, here's the stack trace, here's all the tags, oh, we see it's like this particular segment of code, and Ian did the commit that changed that code.

And do you want to fire your issue and assign it to Ian? It's not that crisp, kind of tight workflow that we have here. This is breadcrumbs. Right. And we said, hey, maybe there's no reason why we couldn't do this for performance. Let's try. Okay. So you took a swing.

You tried. Describe to me how that trial works. If I go to my dashboard now and I enable APM on my application, what are the steps? Largely because we kind of encourage you to go and set up transaction information when you set up Sentry. You probably, as a user, probably don't need to do much. But if you skip that step, you do need to configure to send that data in your SDK. And what happens is we start now looking at that information. And then when we see a what we call a performance issue, we

fingerprint that, and we put that into your issues feed, which is already where you're looking for error issues, right? It's not a separate inbox. This is the same inbox, the same inbox. Yeah. Now, we obviously give logical filters. And if you just want to look at those, we do that. And for newer users, sometimes we detect, hey, you've probably never seen this before. We do things because we know we build for mass market that bring your attention to it, but it's the same workflow you have for errors today.

So you don't have to learn something new to take advantage of these things. So you asked for the experience. So last fall, we did the experiment, the first one, which we called M plus one. And we didn't know how it was go, honestly. But people liked it. Like we kind of know people like it

when they start tweeting and saying nice things about it. And so, yeah, it got traction. Very cool. So if your team is looking for a developer first APM tool to use, check out Sentry and use the code changelog when you sign up and you're going to get the team plan for free for three months. Make sure you tell them we sent you because they love hearing from our listeners.

Check them out at Sentry.io. Again, Sentry.io. That's S-E-N-T-R-Y dot I-O. So let's get back to the 100-year aspect of it then. So you put out on this post, which we'll link to, Hair aims to become a 100-year programming language, five points which are important for this purpose. I thought maybe we could breeze through these and camp out on areas that we find interesting. The first one is that conservatism is in the language design. The second one is the importance of the standard. Three is the necessity of a feature freeze for defining long-term API stability goals and, fostering a culture that values stability. That one might be the hardest as we tend as software developers to value anything but stability, right?

We trade that in at every turn. Is number one on purpose? Are these more important as you start and work their way down? Or you just had to put them in an order and you just picked? Yeah, I guess I used a numbered list in the block list, didn't I? Might've been better as bullet points. Okay. So they're not ordinal. Yeah, they're not ordinal. They're of different importance, but they're all very important. So what does it mean to have conservatism in language design? So I alluded to some of these ideas about where Hare finds conservatism and why Hare values

conservatism in terms of language design. And so when I say conservatism in terms of language design, I'm talking about careful choices of how to do the language design that err on the side of caution and on the side of more proven solutions and less on the side of experimental stuff and trying new things. So like Zig, for example, one of its big value adds or selling points is the comp time feature, which is very unique to Zig. And I think that's really cool. And I hope they do really cool things with it. But something that differs from Zig in terms of hair's design philosophy is we're not trying to add a big feature, which is experimental and unique to hair, because instead, we think that in order to achieve goals

like this hundred year stability, what we want to do is distill the state of the art and understood systems programming design techniques, which have already been proven, you know, in the field of battle, and take, you know, sensibilities about good systems programming language design as they are today and put those into a programming language and then stop. So stop as in it's done. Yes. All continued efforts will be elsewhere, like in the standard library or even beyond the standard library. But like the language itself is feature complete. Is that what you mean by done?

Yeah. And there was this point you mentioned about the feature freeze. This is a goal that we have, which ties into that, which is that when we finish designing the language, when we finish writing the specification and we finalize the compiler or the grammar and the syntax and the semantics, we're going to say it's done and call that 1.0 and there will never be a 2.0. We are going to commit to not making breaking changes or adding new features even to the core language ever once we're done with it. How in the world do you do that? Wow.

You say it's like Jason Oliver again. You say no to everything else. We have this process that we're going to use to try to make sure that when we say it's done, that it's good, which is ambitious. I know it's hard ever to say something's good for sure. But we're going to create this process of acceptance testing where we're going to split up into teams and we're going to outline a list of things that we need to validate in terms of design. And we're going to go over the whole language,

the fine-tooth comb and compare notes. And we expect this process to take a few years worth of validating the design. We're going to say we think it's done and then we're going to check our work and then we're going to say, we think it's done. And then we're going to check our work. And then we're going to say it's done a few years later. And at that point, hair becomes a time capsule. And it's okay for other programming languages to keep innovating and trying new things. And I'm really excited about the new things that they're going to do. And I know that hair will eventually become obsolete. But I think that because we're going

to make this decision, hair will not become the best way to write code, but it will keep working. And I don't think a lot of other languages will. Okay. So define keep working. Let's say it's 80 years from now and I just have hair 1.0 still, I guess. That's how it keeps working. And if I have some source code that was written to run on hair one, which is the only hair there is, then I'm going to compile and I'm going to execute. Well, we are going to keep working on it. We're just not going to make breaking changes. So there'll be a 1.0 and a 1.1 and a 1.2. But the pitch that I give people is on the day hair 1.0 is released, you can write a program in hair. And in a hundred years,

that same program will still compile on a modern system assuming that people care enough about it for 100 years to keep porting it to these systems but we go even further we say if on the day that hair 1.0 is released you grab a copy of the specification and you implement your own compiler that compiler in 100 years time will compile contemporary programs okay interesting so that brings us to the importance of the standard right because hair is going to be more than just the implementation that you're creating it has to necessarily be the standard because there needs to be new implementations over time you know like the quantum version yeah whatever you know as we as we have

quantum leaps so to speak technology there has to be new implementations that will then implement the standard that you are designing today, right? Exactly. And if we want people to port it to new platforms and to proliferate in a similar way that C does and to keep it maintained and working as technology evolves, you need a specification which defines what is the language and how does it work. It also keeps us honest. It means that we're saying this is how the language works. And we fix our compiler if it disagrees with the spec. We don't fix the spec. Okay. It strikes me that you named it backwards. Shouldn't this be the tortoise? I mean, isn't hair a misnomer then? This has not been lost on me.

Okay. So you had the idea of longevity later i think a hair is cuter than a tortoise and i think the the file extension is better i'll give you that one like who wants a dot tortoise yeah file extension nobody tort could be good though that would be cool that would be kind of cool it is dot a dot h a at the moment i'm happy with that okay actually the origin of the name of the language is not a metaphor at all. I told my buddy, Lewis Taylor, I said, hey Lewis, I want to make a programming

language and I want you to draw me a cute mascot any animal that you want. And he drew a cute rabbit and I said, okay, it's called Hair. Oh, the mascot is named Harriet by the way. That's a fun fact about Hair. It is a cute little mascot. I'll give you that.

Here Drew goes. He continues to make it sound so easy. He's like, just draw it. I'll just call it hair. No problemo. Some of us sweat over names for years. I write so many projects. I had to unlearn that habit.

Yeah, that's probably a virtue is the ability just to not care so much and just name it hair. Well, I thought it was because it was fast or something. I'm just trying to figure out why. Then I saw your 100 years thing. I'm like, well, he's not going for the tortoise versus hair metaphor because that would be backwards. No, it's named hair because of the cute mascot. The one came first, the hair or the, or the name. Okay. So we have the importance of the standard conservatism. I just feel like that's going to be so hard because it's a, like you said, it's really hard to call something finished and good, right? Well, sometimes you can just quit. We're going to, so there's another point about like stability guarantees in the standard library, which is important because we're not actually going to call it finished. We're going to call it stable. So the language, syntax, and semantics are not going to change, but we're going to add features to the standard library, perhaps. We're going to improve the compiler optimizations.

We're going to keep working on it and improving it, but we're going to maintain perpetual backwards and forwards compatibility. Yeah, Jose Valim did something similar with Elixir. He, at one point, said Elixir is feature complete and the language won't change from here. And he's continued to work on it and the team has continued to work on it. There's so much you can do in tooling,

in the libraries, in tons of places. So it's not like they're done working on it. It's just like the language itself is finished, which I think gives a sigh of relief at a certain point when you're riding that wave of newness is to be like, okay, it's over now. Where do you think hair is in that progress? Like if you had to give it a percentage done,

I know not done, but percentage designed, feel free to use a range. Yeah. Are you like halfway there? Like what percentages is it to being 1.0? You know, it's hard to say. We maintain the tradition of it's done when it's done, of course, but we have some focus areas, which are going to matter to the ability for us to stabilize the grammar and the semantics,

which comes in the form of a few research areas that we're thinking about looking into. We're thinking about researching linear types, for example, which is going to change. If we end up doing that, it will change some of the syntax and add new language features. We're also doing miscellaneous small stuff. There's some proposals on the RFC mailing list right now for things like adding optional parameters for functions. And so we kind of have this mix of a couple of things we've identified that we need to figure out if we're going to do it and how we're going to do it before we can call it stable, like linear types. And then we have a small collection of refinements. And I would say

the refinements are going to keep on rolling for a little while longer. And we're going to do that research on those couple of things. And then we're probably pretty close. And as it stands today, hair is a useful programming language that people are already using for things with the understanding that there's, you know, we haven't made the stability guarantee yet, but it's still being used and it's useful and people are writing cool stuff with it. And so it's not necessarily a blocker for us to finish all of these things for people to use it and for it to become interesting. So we're not really in a rush. It's already useful.

And we're going to take our time because if we brush it, then we're going to freeze a bad language, you know? Right. Yeah. You don't want to have regrets, you know? Yeah. Especially once you've called that that moment in time, right? That freeze moment is no going back, right?

So that's right. We'll take your time. What's wrong with LTS is like Linux does, though, or Ubuntu does, versus just like literally freezing it? Because you said regrets, Jared, and that's the whole point of versioning, right? It's like, no regrets, because you can version. Well, Linux is frozen in a sense, which is that the cardinal rule of Linux is we never break user space.

And so Linux is infamously unstable in terms of like, if you compile a binary five years ago, you can't run it today. But that's entirely because user space is unstable. So like glibc does symbol breakage all the time. If you were to statically link something where it just relies on the Linux syscall ABI or on the sysfs or pocketfs layouts, that kind of thing, if it's just talking to the kernel, something that you wrote 20 years ago for Linux in this manner

would still run today because Linux has made that guarantee. So what's wrong with LTSs then? Like LTSing a version, like a long-term support kind of thing where you can stabilize to a degree over a period of time, provide support to it. Does that not provide enough encapsulation or enough? What was the word you used before, like freezing it? What would you say before?

Stability, not sure. You said something about it. Maybe it was freeze. I don't know. Disregard. Yeah, I mean, there's a difference between the way that LTSS is applied to Linux is compelling and the way that it's less compelling when applied to Hair. So first of all, Linux is a piece of software for like end users. It's run on your computer on billions of devices around the world.

Hair is a tool which is used to build programs. And so it has different needs and design constraints. And also Hair is significantly simpler than Linux, and it has a fixed scope, whereas Linux has an open scope. So Linux is always going to have to add new drivers and new abstractions to support those new

drivers. Linux can never be done and still meet its goals, whereas Hair can meet its goals and be done. Well, I cannot argue with you because I have zero of your talent, so I will not anymore. Well, I mean, different strokes for different folks. I couldn't sit down and interview you, I think.

Well, also different kinds of programming languages for different uses. You also have a far better sense of style than I have. Well, thank you. I try to have good style. Adam, you do make it look easy. I'll give you that. Thank you very much. Thank you very much, Jared. I think just the concept of LTS

seems to logically make sense when applied, but I'll take your word for it. I mean, different people make different decisions. You know, programming language like Rust might benefit from an LTS release, but for what Hair has tried to do, it doesn't make as much sense. Okay.

Plus, like a diversity of programming languages is awesome and if you have hair 1.0 that's continuing to grow and it's one or one point whatever phase 15 20 50 years from now somebody comes along and hits that fork button or whatever the source hut equivalent is and says here it's reply jared it's reply it's reply they hit reply all that's right and they said here comes the tortoise you know i'm gonna fix all the things drew messed up and we're gonna modernize this sucker and that's just fine too i invite that yeah i'm sure you do yeah What's up, friends? We're working closely with.tech domains to feature startups that are participating in their startups.tech program right here on the changelog. And I've never seen anything like this from one of our advertisers,

but it does make sense to me to show off not only what.tech domains offer, but also who is building on.tech domains. And I'm here with Simon Schillenbeck, founder of Handprint Tech. You can find them at handprint.tech. So Simon, tell me about Handprint. What do you guys do?

Handprint Tech is a Singapore-based digital technology platform that connects companies to the most impactful non-profit organizations in the world. Our mission is to make it easy and more valuable for companies, regardless of what they do, to make a positive impact in the world. So we fit within the sustainability space, but our approach is very different. Most of what sustainability, especially from the corporate side, has focused on over the last 30, 40 years is to do less bad, reduce their negative impact, reduce your footprint. But handprint focuses on the creation of positive impact. Okay, that makes sense.

So how do you help companies then? The way we help companies achieve this is firstly by curating and digitizing the best NGO projects, the best charities, the best impact organizations in the world, and improve their capacity for high quality reporting so that companies can have absolute trust that their money that is going to these organizations is well spent. Secondly, we built a variety of tools that enable companies to embed and automate the creation of positive impact through their normal business processes. So you can integrate handprint technology in e-commerce, in bank card transactions,

in advertising, in event registrations, in CRM systems, in whatever you can imagine, so that just engaging in your normal business practices can be linked in an automated fashion to the creation of a small positive impact, which is a handprint. And by doing so, we've been able to demonstrate that this can truly increase the company's capacity to instill loyalty, to facilitate engagement, and to stimulate growth. Creating a handprint can really align with your business objectives. And in doing so, companies can capture value from working with us and grow with the planet. Grow with the planet. Okay, that sounds good to me. Let's talk about.tech domains then. So I see in your footer. Your business name is officially Handprint Tech PTE Limited. What does that mean? What made you choose a.tech domain? The domain choice was kind of an interesting story.

So we're, as you mentioned, we're Handprint Tech PTE Private Limited. So that's a Singapore legal entity, which is PTE Ltd. We initially wanted to name our company something else, namely The Green Company with three E's. And very luckily, the Singapore government turned that down because they already had another company called The Green Company with two E's. And they said, well, you can't have almost the same name. And we'd already started building our tech platform and we had named it Handprint because Handprint is the flip side of Footprint. Footprint is all you do that creates a negative impact and destroys the world. And Handprint

is actually a scientific term launched by people at MIT to qualify and quantify the sum of positive impact that you're doing in the world. We started building that platform and then said, why not just name the company after it as well? It does have a good ring to it. And so we chose handprint.tech because we wanted to make it very clear that we are not a non-profit. We are a technology company. By having the handprint.tech name, it becomes a lot clearer that, okay, this is a tech organization that primarily is a tech company.

The only difference is that our product is a positive impact in the world, but we do this through technology. Okay, make sure you check out Handprint at handprint.tech. Again, handprint.tech. And of course, go to startups.tech slash changelog if you want to have your startup that's building on a.tech domain featured on a show like this. Don't wait,

go to startups.tech slash changelog. Again, startups.tech slash changelog. here's the one that i can't get over quite because you know i am a a working programmer believe it or not fostering a culture that values stability. So I do have some years behind me. So I value stability, but I also have that childlike wonder of the new and shiny that I just can't get rid of no matter how many of my hairs turn gray. Are you going to find enough people to care about that? That hair becomes like actually, because really what will probably make hair last a hundred years is that people are still finding it useful and years from now. And so the user base, which is it going to appeal to folks when rust is adding new things, maybe zigs adding new things, maybe some brand new feature comes out 10 years from now that like you just got to have, but hair doesn't have it because it's feature frozen. How are you going to get that community base going? Well, you know, that's a really good question. And this is the hardest part of all of these goals

is fostering cultural stability. I don't think in terms of scale, we don't have ambitions to be especially popular. We just want to be good. And if people like it, they'll use it. But it is an important question because yeah, if nobody's using it to write cool software, then there's no point for it to be stable for that long. And I think we attract people because hair is really fun to write and you can do a lot of stuff with it. And it's, you know, it's super fast. You can bootstrap the entire tool chain from scratch, including the backend, which is not LLVM in three and a half minutes, including running all of the tests. The compiler is super fast. It's a very pleasant workflow to use. And we have great documentation tools

that feel really good to use. And a lot of people feel like they get their hair code right on the first try, especially they get their APIs right, which is really the most important part of designing software is to get your interfaces right. And people feel like they

just know how to express their interface goal in hair in the one true way of writing hair. And so there's all of these things about writing hair as an experience that feels really good. And a lot of those things that feel really good, like making it easy to design a good interface, also lend themselves to supporting the stability goals. Because if you make a good interface, also lend themselves to supporting the stability goals. Because if you make a bad interface, you have to make a breaking change to do another one. And so we want hair to just be a good language, which is enjoyable to use and applicable to a lot of projects in the systems programming space. And if we think we build that, people will come. But we don't actually set it as an explicit goal. We make it good because we want it to be good for us, not necessarily because we want to take over the world. But that's kind of secondary to the whole culture of stability thing, which, you know, you're right, people love shiny new things. And that's an instinct, which we're starting to kind of push back against. And that's probably one of the hardest goals for stability that we're trying to take on.

But I think it's working. And I don't know if it's going to scale, but what we're doing right now seems to be working. And the way we're doing it is, you know, here is a community which is growing a little bit more every day. It's kind of small, but it's also a little bit closer knit. And we focus on making a place where people feel comfortable participating. And we have this kind of a close community where we can not just collaborate, but also share values. And so if somebody comes into the project and we make it easy for them to participate in our discourse, they're exposed to our ways of thinking and understand how we value stability

and why we value stability and how they can apply those values to a productive purpose. And we also have design decisions, which also kind of nudge you into that. We have, for example, no package manager. We don't want to have an MPM situation where you have a thousand dependencies by accident. And so we have both a small number of technical things, but mostly we just have this discourse where the way we talk about hair and the way we talk about our values within the project causes people to, as they acclimate to the culture of the hair community and start learning hair and seeking help from experts on hair, they kind of start to get it. And this is a big experiment and it's a social experiment. So who knows?

But we're trying to make the culture value that. And it's something we're deliberately trying to do, but it's also by far the hardest goal. Where does that community exist? Mailing lists and IRC for the most part. And how's it going so far? I mean, you feel good about it? Yeah. I mean, it's been a couple of years now that I've just been a hair user, not just a hair developer. And it feels really good to write hair code. Like, you know, sometimes I joke that I want programming, which is a very, it requires a great deal of a great

absence of hubris to say that. But I really love writing hair code. And so does everybody else who's using it and working on it. Like it just feels good to write and we're all really enjoying it. So we're using it to build a bunch of cool stuff. And it's really cool to see the ecosystem starting to grow. And it's early, but it has momentum

and we really love what we're doing. And so it feels great. I gotta love that. You almost wonder, you know, as you draw more to your crowd, you know, like when will the people show up and ruin it all? You know, because small communities are nice and medium sized communities can be nice, but it seems like on the internet, large communities almost de facto are not nice. And so maybe you'll stay small just because you're

being so intentional with your community. And that will be a good thing. Maybe that'll help it survive for 100 years. I mean, we have also been deliberate about accommodating the community as it grows. So, you know, it's small, but we have 100 people working on here. And we recently did a bunch of reforms to the government structure. We added more maintainers and we subdivided the project into subsystems and assigned specific maintainers to those subsystems. We set up a code of conduct and we created a social space for the community. And so we're taking these measures as it grows.

We're watching it grow and we're identifying where things are working and then we're changing and adapting and so far we're able to preserve our culture by doing that and it's not known if as it goes bigger and bigger or if it grows bigger and bigger if we'll still be able to do that but it's something that so far we we have had to deal with growth and we've done it in a way which was measured and good for our community and allowed that culture to persist. Have y'all met in public yet in, you know, face-to-face IRL? You said only million list, only IRC. Yeah, some of us have. Okay. I've met a few of the people who work on here personally.

And, you know, this is a project which creates friendships. And a lot of people have become friends and spend time with each other and seen each other on their trips and so on. And then we have also had a couple of meetups at FOSTA. Cool. I was thinking of a way to use the word bunny. A fun word. In something like, I was thinking like welcome hair, you know, some puns, you know. Or maybe an alternate version of hair which is bunny it's just

a fun i thought you were gonna make like um a sex joke with the community growing and the reproduction of rabbits kind of thing well that's good too i like where you're going with that yeah i don't know how to pull it together though so you got to work on the punchline yeah that's a tough one to pull off without you off without violating some codes of conduct. Well, you could call it Bunny Farm because it's a play on Funny Farm. But anyways, just thinking out loud about some IRL stuff and just being fun with it. Because I mean, that's kind of what you're doing anyways, right? Yeah.

What developer doesn't love a good pun? Yeah. I'm here for the puns. I mean, and this is a project that we take very seriously and we care a lot about the craft and we're deliberate and we're very careful with design and we set stability as a goal. But doing all of those things is fun for us. We're the kind of weirdos who love doing that. So it's going pretty well. Well, you opened up talking about this kernel that you're building in here. Yeah.

Let's close by talking about something a little more secret that you're building in here. Himitsu, is that how you say it? Himitsu. Himitsu, a secret storage system. This is out there, source code available for folks to check out. You've built this in here. You want to tell us about that? Yeah, sure.

So Himitsu is the Japanese word for secret, and it's a secret storage manager, which is kind of a superset of the features of a password manager. And so I have all of my web passwords in it, but I also have my SSH keys and my PGP keys in the pin code for my credit card. It's a general purpose system for storing secrets. It's inspired by the Plan 9 Factotum system, which most people who listen to this podcast would have never heard of.

But Plan9 is this amazing operating system that I have a lot of respect for. And I saw this Factotum feature in it when I was using it. And I was like, I want to use that on Unix, but also there's some room for improvement. So Himitsu is kind of deeply inspired by that, but doing its own thing. And so it can store all kinds of secrets. And I do have a Firefox add-on to fill in my passwords with, but I also have an SSH agent, which runs my SSH signature requests through the Himitsu daemon. So it pops up a consent dialogue from Himitsu when I try to SSH somewhere and I hit bang and it signs the SSH encryption challenge and off to the races. So we can store it and work with any kind of secret.

Very cool. So I think that is a great starting place for anybody who's curious about here. Perhaps, maybe there's a better starting place just to like check out a real world hair code base that's serving a purpose for Drew. Or is there a better place for folks who are just interested in the language itself and seeing what it looks like,

how you can compile and run it in like a real world program that's written in there? We do have a great tutorial on the website, which includes instructions on how to compile it. If you build everything from scratch, you're up and running in three minutes, maybe five minutes, I'll be generous. And we think the tutorial is great.

It's a good introduction to the language features presented well, I hope. And if you just want to see the language and learn about it, go there. And if you want to see real hair code, Himitsu is great. We also have kind of a stock project for people who want to look into hair or do their first real contribution by writing hair, which is HAutils, which is an implementation of the POSIX core utilities written in here. It's not like a particularly serious project that we expect people to install and use, but POSIX is standardized and it's just good bite-sized real-world problems for people to solve. So that's a good place to see how those problems are solved and maybe to solve one of those problems yourself. Very cool. Hairlang.org. That's H-A-R-E. Adam, any other puns you want to work in before we

let Drew go or any other questions for him that we haven't asked yet that you've been stewing on? I would just say words more so like thumper or carrot or hop or twist. Just like different things that play on, you know, the bunny world, the hair world. It's just up for grabs, I guess. This is good. I'm writing this down. Yeah. You feel like our own personal LLM, Adam. We're like, give us 75 words that have to do with rabbits.

And then you just, you're spitting them out for us. Buck, I believe, was, that's a famous creative commons i think video that people use as like a demo yeah yeah from blender buck bunny big buck bunny big buck bunny that's right not the warner brothers version is there one well i don't know is that warner brothers bugs bunny is that who owns that yeah bugs bunny that's looney tunes looney tunes yeah which was yeah yeah i think so or maybe that was that was warner i was on i was on point there yeah i think so or maybe that was that was one of us i was on i was on point there yeah i remember like uh the pig character with the wonder brothers water tower you know for sure yeah exactly and if you want tortoise i mean you'd be limited i mean what can you do with tortoise not a lot right which is why he really did he really did land on a good name i mean there's so many

things he could do well tortoise shell turtle you know that's about all i got so far you can make a joke about turtle soup you're not the best llm you're like i can only think of two words for tortoise what i like about tortoises though in particular is the their shell is based on the calendar did you know this no right yeah if you look at a tortoise not all of them but some of them have like what seems to be a clock or a calendar around it. The multiples of 12 months, for example. Really? They have 12?

Isn't that crazy? Cool. 12 quadrants on their shell? That's right. Yeah. Some of them do. Could that be happenstance? There's something a part of that.

Time is baked into the turtle shell. Okay. Yeah. That's part of that stardust that created everything. Anyways, it's time to go. We had to fact check that one. You're doing great. Don't worry.

You're doing great. He's a professional, everybody. I'm here to name things and question you about LTS. That's it. I'm going to give you a call when I need a new project date. Well, I will answer. I'll give you my phone number. Okay.

We'll talk to you in 100 years. All right, Drew. Appreciate it. We'll link up all the things in the show notes for folks so they can find all the places. Interesting stuff, ambitious stuff, and best of luck to you and the whole hair community as you continue to...

Adam, what's the pun? Thumper it? I don't know. Thumper it, yeah. Let's just say goodbye. Anyway, it's been great. Thank you guys so much for having me. Thanks, Drew.

And for all the puns, too. You got it. Well, that's all, folks. That's it for this show. Thank you for tuning in. Can you believe next week, Jared and I are recording State of the Log? We still want submissions. So we want to hear from our listeners.

We want to hear from you. Just drop us a voicemail. Go to changelog.fm slash S-O-T-L. And guess what? Threads are waiting for you if your voice appears on the podcast. That's good stuff. And we also have a bonus on this episode for our Plus Plus subscribers, so stick around for that.

changelog.com slash Plus Plus to learn more. It's better. You know what? I plus to learn more. It's better. You know what? I think it is better. It's a little bit better. Maybe it's a lot better. You should try it out. changelog.com slash plus plus.

$10 a month, $100 a year. Drop the ads. Get closer to that cool changelog metal and get bonus content like today. Big thanks to our friends and our partners at Fastly and Fly. And, of course, to Brake Master Cylinder. Those beats are banging. Stick around if you're a Plus Plus member. If not, the show's done. We'll see you on Friday. Thank you. it's better