I've known a lot of your public works through things like Lang Jam, where I've always wanted to get involved with them. But I do not have a programming language or even like a super classical computer science background. I haven't really known where to get started, but I managed to fall into writing a Forth a couple months ago and now it became relevant again because I've started it including it in my operating system. I think I reached out to you just saying hey what are your thoughts on growing a programming language around an operating system is essentially like a domain specific language for an operating system.

Sophia Turner

Yeah, where shall we dive in?

James Munns

Well actually probably now that I've introduced the concept I should probably introduce you — do you- do you want to give yourself a short introduction before we dive into the technical stuff?

Sophia Turner

Sure, so... I until recently was part of the Rust Core Team and earlier than that I also was part of the the team that created TypeScript. So I've been kind of professionally and in a hobby sense part of the programming language design and implementation community for gosh … around sixteen total years, seventeen total years now? It's one of those things that started as a hobby idea, “Oh let me just throw this together,” and then I just got hooked. And that kind of became my career ever since.

James Munns

You gazed into the abyss and became the abyss gazing expert.

Sophia Turner

That's right.

James Munns

Was Nushell a project that you started, or joined and have championed or… I know there's quite a few projects that I've seen you interact with, and either have come and left because you've actually been more successful than a lot of people that I know where you have very good positive experiences and then you move on to something new and then a year later I see you are championing some other also amazing project and things like that.

Sophia Turner

Ah, yeah, so I thought I was going to take some time away from doing programming language design and I went and worked at Microsoft on Azure and after a few months of that the the itch just got too bad and. My buddy Yehuda Katz said, “I'm going to start a new shell,” and I was you know playing with PowerShell, “I'm gonna start a new shell,” and I was like, “Cool, give me commit access.” He's like, “Absolutely, let's go!”

James Munns

I didn't realize Yehuda was involved with that!

Sophia Turner

Yeah so he… it was originally his first commit. And I jumped in about five days later after he told me he was working on a new project and that became Nushell so that the combination of that and then another guy um, Andrés Robalino came in and turned this shell idea into kind of a full scripting language and whatnot. It's been really awesome to kind of watch that grow.

James Munns

Yeah, so so I did more of a computer engineering, working with a lot of embedded systems. So programming languages were always something that I used but I never… I didn't take a program- I had a lot of friends that did computer science and they would have a programming language class or some computer science class that would get more into lexers and parsers and stages of compilation and things like that and it was a combination of: It didn't interest me at the time and also I wasn't forced to do it, so I never really got a taste for it. And working on embedded, a lot of the times you're compiling specifically to fit as much as possible into as small of a space as possible. So you don't tend to have as dynamic environments and especially the beginning of my career was all safety critical stuff which means you're really not supposed to have dynamic environments. It's supposed to be very well understood and and straightforward… and the last year or so I've been working more on an operating system level where I just started building bigger and bigger systems and trying to build them like operating systems I realized that switching from a system that does one really specific thing in a really specific way and wanting to build a system that you can iterate on, or get it to do many different things is a very different approach and I was really running into the limitations of trying to build an operating system in the shape of an embedded system if that makes sense.

Sophia Turner

I think so.

James Munns

So I kind of realized, hey wait, all the things that are making this problem challenging right now is I don't have a file system where I don't have a networking stack or I don't have a shell or something like that, where I can play around with what I'm doing and building that I was building a really big application rather than an operating system and so I was like okay, cool I need to build an operating system I was working on that and still sort of iterating on that and then kind of ran into a wall because I was just building plumbing for like three months and I could get it to do something every now and then but it was just kind of like building plumbing and… It stopped feeling rewarding because I could never put the tools down and just play with it for a while to like you know re-energize mentally. Until fairly recently I was working on… I learned a little bit about Forth and I can go into that a bit more but… Just as the first programming language stuff I was doing I was playing around with Forth and then hadn't been touching my operating system for a while because like I said it fell off and then I got in contact with ah Eliza — you might know her from like the Tokio project and stuff like that —

Sophia Turner

Yep.

James Munns

— hawkw on Github… She and I were talking and she also has an operating system project and it's also kind of sometimes on-again, off-again, and we were just talking about how we really wanted a system that was just fun to play with and the question was how can you get from something you're building on, to something that you can play with and we sort of outlined a couple things like, well it needs to be more like a computer you need to be able to do stuff with it when it's not hooked up to your compiler basically. So the thought was that well okay, well let's get a shell on there. Let's get some kind of programming language, so that when you detach it from the main computer, it can do something on its own and you can sort of invent something new and play with it and hoping that that would drive inspiration and things like that. But I'm totally out of my depth and Forth is an interesting language, for a lot of reasons. And ah, yeah, the the reason that I reached out is, I went - is this is there a better way to do this, or is this even something that you have opinions on from a language perspective of growing a language specifically as an extension of of an operating system.

Sophia Turner

So let me ask you some questions to see if I can kind of repeat back what you're saying, but also see if I've got a more complete understanding. So, in what you're working on, you've got this operating system, it boots up, and you need some way to start interacting with this thing you know, getting something displayed on the screen, interacting with some device driver or something like that and currently you don't have a shell, you don't have that kind of… Or even a scripting way that you could just drop into some REPL and type some commands and then something happens- is that right?

James Munns

Yeah, until very recently that was the case- so I have integrated the Forth now because that's where I was kind of when I left off at the end of last year is - yeah I could bring up a new driver or a service or something that, um, you know, checked the serial port or printed it… or now I have the display working, or it can blink an LED or something like that. But it was always building something you hit run, it does exactly the thing that you programmed it to do and you go, “That was neat,” and then you go and program the next thing which you know there was none of that flexibility and now we have a very limited Forth shell where you can… We have sort of like system calls in our operating system, and we've started duct taping the system calls onto the Forth scripting language so you can basically give a system call a function name and pass it some arguments and get it to do something. So you can open up a new Network port from the command line now… um, just because Forth is at the upper limits of my ability right now if that makes sense.

Sophia Turner

Oh as far as like implementing ah, a programming language?

James Munns

Yeah, yeah this is the only one that I've ever implemented - and I looked at something like Rhai before of just figuring out how you map that, like, the underlying semantics of the platform to the environment that the the language itself is running in and finding like sort of a symbiotic growth between the two of them.

Sophia Turner

Yeah, Rhai is an interesting idea as far as like to draw inspiration from, because it's really built for scripting against an existing Rust application. You've got for example, you register some functions on the Rust side, and then those just show up in the script which sounds pretty similar to what you're trying to do with your Forth script to be able to say here is some system calls and then they just show up in your Forth side of things as functions that you can run. So there is some similarity there and I wonder if there is something that you could take from this kind of embedded scripting language not embedded like, um, embedded systems but maybe “embeddable” is ah is a better way to think of it like embeddable into the application? So in a sense, something where you could even use some of the same tricks that Rhai uses to register a set of, a set of the the system calls in the code, and then, with luck, those just show up as part of the script and just function calls in the script that you could call.

James Munns

Yeah, so originally I was writing the Forth for bare metal embedded stuff. So I it wrote it all no standard. It required a bump allocator… but you're familiar with Forth right?

Sophia Turner

Um, I mean enough to know the gist of it. Yeah I don't use that very often.

James Munns

Haha, yeah I don't know if any- many people today use it super often. But I mean it has its own sort of bump-allocator-linked-list-dictionary thing that it uses so, there's no real like, host allocator, but you just give it a big blob of memory and when you define new functions or variables and things like that it just shoves it on the bump allocator more or less.

Sophia Turner

Right.

James Munns

But yeah I always designed it from the beginning because I always knew that there was going to be some native code that I was going to build, and mentioning embedded languages, even though we're talking about embedded systems and embedded languages I think it actually really makes sense because as an operating system, I don't really have a stable API or or even a way to like call programs, really, so… There's only the Rust code that I've written for the kernel, and the Rust code that I'm hoping to run for my scripting language. So I think the patterns actually do match fairly identically because you're grafting it on to a language environment rather than an operating system environment because this Forth shell that we've integrated now is running in the kernel, until we have user space which doesn't exist yet. But yeah, it definitely works the same way where you can define a native Rust function, and then bind it to a name and then when you call it from the interpreter it just calls out to that Rust function… and that was one of the tricky things at the time is - before this was async or before it was async it was just all blocking, which means it was great I could just say hey here's a function pointer that takes the VM context as immutable reference and you just bind that function pointer to a name and then all of a sudden it shows up in the scripting language.

Sophia Turner

Right.

James Munns

And that was really great, except for our kernel is all async… which means you really shouldn't be blocking on flushing to a file or something like that, you should be able to yield - and async functions are not like function pointers. They have, like, context and things that goes with them and there's some control flow stuff, so… I hadn't actually figured out how to bind it to async and sort of what we we fell down to was- well when you build the specific embedding you give it one function that just matches on the string name, and can call one of very many async functions rather than giving it like an array of string function pointer tuples. You just give it one function that matches and calls the appropriate async function and things like that and… that was a little tricky to figure out of like kind of turning the control flow inside out. But yeah, it's one of those things where the language works. My implementation of it's not great. Forth is a language is really wonderful because it's low-level and powerful and simple and it's, it's very much a hammer and chisel language sort of thing, but it also means that anything you do is wildly unsafe if you -

Sophia Turner

Right.

James Munns

If you implement any of the core functionality, it's like well you can peek and poke to random memory address, and how do you interact with arrays? Well you take a pointer and then you add a number to it and then you write randomly to that array and of course there's no bounds checking or anything like that because that would be expensive in the 70s and -

Sophia Turner

Right.

James Munns

So that's one of those language design things where I go, well this certainly works today and it will continue to work as long as it's just me and Eliza who know that if we make the kernel segfault, that that's okay, but one of the reasons that I reached out to you is … I don't know if you've if you've grown a language through and out like different stages of an application — so like if you have an embeddable language where at the very beginning, the language is more focused on helping you build the application, whereas in the later game, a scripting language might serve more of a purpose of helping people be more productive or working on top of an existing engine. But it's interesting because I have a feeling we're going to have to go through that transition point where it goes from being a language that helps you build the platform to a language that makes it easier for people to use the platform. Does that sort of distinction make sense?

Sophia Turner

It does! I mean, it kind of raises the question of - is Forth a kind of like your early days scripting language, or is that something that you want to continue to support as the system grows? Like you mentioned, it's wildly unsafe. It's from a different era of of style of programming language. It's not a style of programming language that a lot of people are are familiar with. I think it's a stack based language. There just really aren't that many anymore these days.

James Munns

Yeah, well most of them are hidden as Wasm or Java or things like that. They have languages applied upon them rather than being, sort of, raw stack-back based languages nowadays I guess.

Sophia Turner

Yeah, kind of like the stack based virtual machine stuff. Yeah, absolutely. Yeah, hm… I mean my instinct when I'm thinking about how to design a language in 2023 ah rather than 1970 something something, whenever a Forth was made, is really to draw a lot of inspiration from the languages of the current day. So a lot of people are going to be coming to things that are familiar with Javascript. That's not saying that Javascript is like, the end all be all… But as far as a design starting place, that's where I would start saying if you want to script something- this gives you functions, this gives you a way of building up interesting scripts that you could then run later. Another aspect that I would definitely think about, especially because, you know, I've been working on Nushell for a while now- this idea that there should be a nice connection between the scripting language and how interactive it is. And in your particular case, because this thing will - could - potentially grow to be the shell into your operating system - so you, you know, you log in and then the the thing that you're writing interactively in this kind of REPL way or the shell way might be that language itself is to think about is — how would one design a language such that it was nice to use in that interactive sense. Does any of that resonate for you?

James Munns

Yeah, for sure and that's one of those things — these are things that are probably going to feel like old hat for you but they're fairly new to me — of looking back, especially at at older generations of programming languages where there are some stuff that that was really powerful at the time and has fallen out of fashion where a lot of the, like, graphical programming languages where you have a table of all of your variables as part of the IDE or things like that or exactly those kind of things that you were talking about about introspection where you can see what the system is doing is particularly interesting. The operating system is in a weird place right now where it's — I'm building a language to help me build an operating system, but I don't know what either of them particularly want to be whereas I feel like I'd be interested to hear some of your experience with embedded languages like Rhai or or other languages like, what usually sparks you to introduce an embedded language, or design a language around a problem domain in general?

Sophia Turner

Having just made one fairly recently — so I did a language called Jakt, J-A-K-T, with Andreas Kling who created SerenityOS, and he was kind of looking around for, I want to get a safe systems language so that the people in the future that are writing certain DOS code, they aren't writing C++, they're using something better. And he tried Rust, but Rust doesn't have object orientation and he hit some other limitations. And so I was like, okay, let's just make something. And in that sense, when I actually have someone that has those constraints and can sit and kind of ping pong with them with those constraints, the design can really gel around that. If I don't have that, as you… as one might imagine, you know, the sky’s the limit, you just design whatever. Oh, can I, can I throw you a a slight curveball?

James Munns

Sure.

Sophia Turner

Are you familiar with Niklaus Wirth? Creator of Pascal?

James Munns

Yeah… That is the only thing that I'm familiar with him about.

Sophia Turner

Okay, so the the curve ball is that, later in his career, he made this thing called Oberon, which is kind of brilliant and kind of wacky in a really cool way.

James Munns

How so?

Sophia Turner

Oberon is an operating system and programming language, kind of integrated into each other. And so you boot up. The thing that you boot up into is a graphical shell, where text is written and you can interact with this text. If the description is hard to understand that's because nothing is like this that exists today. I mean, you can go get Oberon, but no one pursued this direction, and yet it is a fascinating direction for — what does it mean to interact with your system? If you happen to do Youtube at all, I used to have a Youtube channel called “Systems with JT” and I look at Oberon in one of the videos, and it gives you a sense for what this thing could do. But it's like, imagine a precursor to HyperText or co-designed around the same time as HyperText, and as you type certain words, those become command invocations and you can click on them and run the command. It's a very cool idea. And it gets away from some of the trappings of — if you do what I just suggested, which is start with the known language of the day, Javascript or Python, and then build around that, that leads you down a very well-paved design space. But Wirth and others back in the day were saying, but what if you don't? What if you make a system intended for users that understand the language itself. The graphical interaction mechanism is not separated from the programming language that this thing is implemented in. Yeah, you just have to see it. I don't know if I could do it justice. It was a very interesting idea.

James Munns

Yeah, following down the Forth rabbit hole — when I was growing up when I was in younger school years, we had a lot of, like, the classic Macs in our schools, and I remember we had things like Hypercard —

Sophia Turner

Exactly.

James Munns

Where at the time, like, you know, now when you sort of look back at the screenshots at it, you go, “Oh, that's kind of like PowerPoint!” It was, kind of, but with with a lot more programming built into it, And going back after learning Forth and realizing how some of the things were built around that time, or how certain things like PostScript like what pdfs or printers are still sort of built on top of how how those worked back in the day were really interesting when you'd have, you know, like 20 or 30 or $40,000 printer and it was the one in the building and it was more powerful than everyone's machine, rather than designing, like, a rasterized image where you have all the pixels rendered on your local machine and sending that over a network to a printer so that it could print it — because your computer couldn't handle it and the network, which was pretty much nonexistent at the time couldn't really handle it, that PostScript is also a stack-based language, it's sort of like a cousin to Forth. So you don't really design a doc- well you design a document but not from the perspective of what pixels go where you say, okay: text goes here, and then a gradient, then a triangle goes here and it's more like sending a script to the printer to run because at the time there was a huge mismatch in between the power and the cost of the terminal that you were sitting in front of and and the very large expensive printer and they go, “Well, let's just put the brains in the printer.” And some of the other things from those early Mac era for what is it like Mac talk and stuff like that, some of the networking protocol stuff where like you said there, there's some things that just if you go back and look at that you go, no one does that!

Sophia Turner

Right.

James Munns

Like, that is really interesting, and especially for like, the challenge you had at the time… where you make an interesting point of like, thinking about the users that will use your system. Because especially in those earlier days, the people who were sitting in front of computers weren't the general population of people, they were people who were academics or engineers or things like that who were using a very rare system and things like that so sort of the the expectation of understanding, or the people that were sitting in front of the computer had probably built a good chunk of a computer before, which is on one hand really inaccessible for people who don't have that experience but on the other hand is how more accessible if you are reaching down into the system itself. Which is sort of where I find myself today in in developing my OS, in that there's a very small population of people working on it. It's two of us mostly. And this is sort of that delineation I was talking about before of - the language that will help me build the system, versus the language that I think would appeal to the most people who use that system in some future vision or something like that.

Sophia Turner

Yeah, and I think that's one of those tensions that always shows up in designing any system designing any tool, and especially shows up in programming languages — like who is your audience for designing this thing. As we're talking about it, and I'm thinking back to things like Oberon you know we haven't mentioned it yet but things like Smalltalk are another interesting perspective — if you have full control over the system, thinking of everything as introspectable objects, where I could click on a window and then say - this is like a classic Smalltalk thing - click on the window and then kind of flip it around and get its properties and just tweak the properties and flip it back around. And so that everything is intended for someone that's comfortable with grabbing and manipulating in a kind of technical sense, real pieces of the system… and that's something for you and Eliza and whoever your other contributors are, but I think there's there's really a case to be made for saying, “Let's build something that makes us happy - the core team of this project - and we attract other people that do that.” We're not going to design in such a way as to make it impossible for anyone else to understand, you know, it's not going to be esoteric. But, you can design in such a way that maybe some of these ideas from the past really appeal. You know maybe take Forth even further, or maybe you look into some of these you know visual experiments like Oberon and say, you know what? Text base, interactable commands and stuff is really rad, I like that, and let's kind of go in that direction. And it would have a certain kind of appeal, because the audience that are attracted to that would say, you know what? We should have tried that, we should have that is an idea from the past that should be explored. Not saying you have to go the Oberon direction, it's just the one that kind of came to mind where the intent of the system is for people, not necessarily experts, but people that do not mind playing with the system in a programmatic sense. By like manipulating it or by changing it and seeing what happens.

James Munns

There's a language that I'm thinking of… it's written in Rust… a language that I've seen some people use where they build things like lighting installations or graphical demos and things like that where I know the engine itself is written in Rust. But it's meant to be sort of ah, an iterative iterative playing language. Does that ring a bell to you, or do you know what I'm talking about?

Sophia Turner

Vaguely, I've heard of a few projects like that. It's not coming up for me which one that might be…

James Munns

Yeah… it was interesting to hear you talk about designing a language, because it rings all the bells that I have for when I'm designing a system. So I do a lot of consulting, and I sit down with people and and honestly the thing more than like, “How do I program this, or how do I write this driver?” and things like that - a lot of the the nuts and bolts of of what I help people with is requirements engineering or systems engineering, where you sit down and you go- what does this need to do, and what does this need to not do, and what are my constraints and boundaries. Because when you can constrain it to what it just must do and nothing more, it becomes honestly easier. At least in my engineering brain — you can solve for constraints. You have so many free variables, you can't even just stop and solve for 1 or 2, but… The challenge of the day is figuring out what the system wants to be.

Sophia Turner

Yes!

James Munns

This is very much a hobby project- I don't have a customer and, you know, I have a vague idea of the sort of niche that I'd like it to fill. But ah you know, there's no deadlines and there's all open options. But yeah, it's It's interesting to design for something… design for creativity. Does that make sense?

Sophia Turner

Yeah, and I think too, when you've got an audience where you're not even really sure who that target audience might, be or it's kind of vague — switching gears to talking about writing fiction. But a classic thing when writing fiction is to say “I'm writing this story for that person” and it's probably someone you know, really well, maybe a partner maybe a close friend, and you just have them in your head. So every time you're making a decision in the story, you're like, “Ah. This is the person I'm writing this for,” and that's the kind of design constraints you're pulling from. I think you could do the same kind of trick for an interactive programmable system, where you're thinking, “Okay, maybe it's not me or Eliza. Maybe it's somebody else that I know really well and I know their kind of design aesthetic and I at least can pull from that.” I don't know if you've ever kind of used that trick before, but anything where you can just simplify your assumptions or your constraints down, like you're saying, to the set where it's this and not more than that. Um, using, whether it's you know the core team, people, a specific target person, I think it'll definitely build some momentum.

James Munns

Yeah, you mentioned that and the the place that I've used that for is writing blog articles or technical writing for me at least because there's there's often a lot of stuff that I want to talk about or teach about but there's just this whole world of — How much of the basics do I cover? How in-depth to the specific topic do I go? Because I could go, you know, very wide out and it would be a very high level… It's like writing a talk or a blog post where you go, “Well… Who's my audience here?” and that's one of those things that I found, exactly like you said, is is one of those things that… almost every blog post I have on any blog that I've written on has happened because someone asked me the right question. Of a specific person who I knew what they did know and what they didn't know, and they asked the right question, and I go, “Okay, I can write exactly the blog post for you.” But when I when I lack that audience. That's the challenge because the the world is huge. I remembered what the name of the language is — it's called Nanow or Nanu? N-A-N-N-O-U. I think it's actually meant more to be like a library kind of thing. But I was wondering if you had gotten into sort of more creative coding areas where it's… It's a little more open-ended… I guess that's the whole point of DSLs is to make it easier to express those creative ideas rather than having to to get deep into how the whole system works. But, yeah, figuring out that kind of world where it's meant to be something to be played with, you know what I mean?

Sophia Turner

Totally. I mean I've been fascinated by the live coding community… Do they still call it that? Live coding sounds now like something that you would do on on Twitch. What I mean is — back when people would have a live audience and they would be programming in these visualizations that go with the music and you would see them coding up on the screen and as they did it, it would replace the graphics with you know, something that kind of pulsates and then it kind of grows from there and it's this fascinating mix of entertainment and coding and multimedia experiences.

James Munns

I've never seen someone do that visually but… have you ever heard of Sam Aaron and Sonic Pie?

Sophia Turner

Sam Aaron and Sonic Pie… no, no I haven’t..

James Munns

So Sonic Pie is a framework. It's based on super collider which is an audio engine basically. It's a Ruby environment that sits in sort of like a little GUI and you write little function blocks that are each sort of voices. But it's got sort of its own language and idiom and things like that so you can import a bunch of drum samples and write some Ruby code that say like, pick a random one of these kicks and play it on the twos and fours and play that on a loop. And then take the output of that and feed it into a filter or feed it into this, or every now and then feed it through a filter, or every now and then turn off this one. But he does a lot of those live coding streams, for for lack of a better word, where it's just, you're just looking at a REPL and he's just sort of like commenting and uncommenting blocks of code at a time but he's built it in exactly the way that it does the things that you would want to do while you're performing, like… when you comment out something it doesn't kick in into the next bar so it's not like a hard cut and it's smart enough to like, lock in the tempo or or things like that so that it's going like that. But now there's sort of a whole bunch of people on Twitch and things like that using Sonic Pie either for an educational purpose to learn about music or programming, or to do live performance things like that. So I've never actually seen anyone do that visually —

Sophia Turner

Yeah, for sure.

James Munns

— but I have seen that for audio before.

Sophia Turner

All that this kind of reminds me of one of the tenants that we picked up for a Nushell really early on. And I think it's definitely worth a mention, is that if you are building a programming system for yourself for your project, one of the things I absolutely recommend is make it fun. Make the language as as well as you can, make it fun to use. If that becomes a point of friction because it isn't fun, it's like “oh I've got to open this thing, I have to type some things, and I have to kind of remember stuff, and I don't like it. Or it's a bit unsafe…” You know, whatever it is that makes it unfun for you, if you, you know, after the tenth error you're kind of getting frustrated, that's a good indicator that this isn't the right design for your project. We all have limited energy. We all have limited time. For any kind of hobby project. Especially, if you've got that hour at night, you want to sit down and enjoy that hour at night that should be a pleasurable hour. It may sound almost like kind of obvious, but designing in such a way that you are checking in with yourself about how much fun you're having. If you're like I'm not really having fun with this right now. That's that's just a good “Okay, now what do we need to change so that I can have that fun.”

James Munns

Yeah, I think you I think you nailed it on the head. I mean the- so the Forth was what I had on the shelf, so is something that I had built in another random deep dive into how things work and I happened to have it on the shelf. So when I was talking to Eliza, I was like, “How can we make this fun and basically how can I addict myself to working on this system. I mean, you put it in a better way. When you've only got that 1 hour, it's not a paid project or anything like that when you've only got that 1 hour when you're sitting there and you go: Well, I could you know, read a book or watch a movie or watch some Youtube or something like that… How do I go, no: like, the whole day I'm excited to spend that 1 hour on that and I think that's interesting because that was the whole point of introducing a scripting language, so that I could make a system that I could play with. But then I immediately- like my engineer brain kicked back in and I was like, ah, how do I optimize this for safety or for you know accessibility to new users or things like that. But you said it really succinctly of “make it fun.” Because- that was the whole point of why I added the scripting language to the system was to make the system fun. But then immediately I didn't turn around and go, how do I make the programming language fun too? You know what I mean? lack of follow through on on that.

Sophia Turner

Right? Yeah, absolutely. I mean like you're saying- we as engineers, especially professional engineers where we're doing a lot of engineering for pay, there's a lot of expectations about how we're designing systems, how we're thinking through things as Professional Engineers — Capital P, Capital E — and I think that the… when we're working on stuff on the side, it's nice to - not forget everything that we learn in the professional environment - but set aside a lot of the requirements, because really, this is your- this is your free time, this is your hobby time. And say gosh, if fun isn't the first priority, I'm going to get in trouble … or the project's going to get abandoned or something like that, where I feel like especially, you know, through the years past juggling hobby projects and pay projects, you really do need that that little tailwind of “Gosh, I really want to work on it!” Like you were saying, really, I'm thinking about it through the day, I'm excited about when I can kick off work and and jump into this project and see how far I can get yeah, absolutely.

James Munns

So, in the beginning, I was working on the OS. It wasn't async and I'd been talking to Eliza, who was working on her OS called a mycelium which - similar sort of goal, but I was sort of going from the microcontroller up, and she was starting at X86 and building an operating system from there. So it's funny because we were kind of building towards each other's worlds, if that makes sense, where she was sort of starting at a desktop system and building down in the operating system stack, and I was starting from, Okay, the microcontroller turns on, so I'm going to start writing drivers I guess… and then put an OS on top of that and we had already started using some of each other's, like, library components and things like that… just having someone else working on the project is super refreshing, because when you're not working on it, sometimes things just get better by themselves? I'm sure you know from working on other projects, or when when someone calls you into a project and it's just so refreshing when someone is building something and you come back after not thinking about it and you go, “Oh! Oh, it's just it's just better now!” Which solo projects do not do- they acquire dust and they become less fun to spin back up on.

Sophia Turner

Ah, yeah, if only they did… though though imagine a future where — I hate to even say this, I hate to even to bring this into this conversation, but apparently… I'm the moment has spun up — An artificial intelligence thing, that's like “Oh hey, let me fix this code for you while you're away.” How weird would that be?

James Munns

See: I could see it for a lot of cases… I will tell you at least the way my brain works and the way I have fun. I could tell you right now that would make me upset because-

Sophia Turner

Yeah, it's not my style either. Yeah.

James Munns

I absolutely have to understand things. As a source of inspiration I see a lot of those, the generative models and things like that being interesting for inspiration and I think the people that I've seen be most effective on that are not people who put a prompt in and got an answer out or even just iterated on the prompt. They put like 5 random prompts in and they go, “Cool! That's now my reference artwork or reference program or reference whatever,” it's like, “now I know what to build from here,” or, “now I know what to design from here.” But definitely when it comes to anything technical, I derive joy from like digging down and understanding exactly how everything works. So, I've seen some people be wildly successful where they go, “Yeah, I can just generate the cruft” And it's nice, because it gets them moving, but for me I would go, “Nooo, that would slow me- I would have to stop and understand how everything works.”

Sophia Turner

I'm kind of like you too where I work best when I have some other person that I can bounce ideas off of, that I can take a break and I come back and the code is better, because they've been thinking of it from their perspectives, their skill set and... It's like oh yeah, look how much better it is when they put a little bit of time, and then it gets me excited then I want to jump back in. So yeah.

James Munns

Or even the other side, the empathy side of it is — there's absolutely stuff that I have built where I go, “Ah, it's terrible. But it's fine. Like, I'll put up with it, for me.” It's like when you have the level that you will clean your house versus- when you're by yourself versus when someone's coming over? You're like, “Oh, I wrote, like, a thousand lines of code with no documentation and a lot of unsafe and it's… It's very gross.” But then, like, you know someone else is going to look at it and you go, “Okay, yeah, I should probably clean that up.” Because when they come back or when they look at the PR for it to be nice for them. But that same kind of thing… But the the thing that I did want to ask you is: When you're designing languages, or when you're- maybe even broader than that- but let's just start with like when you're designing languages: What parts of the languages are the most fun for you? Whether it's like the most fun to implement, or after it's been built and you can show it to someone else and go, “Hey, watch this.” You know what I mean? Like, what part of the language design or development process for you is the most fun?

Sophia Turner

Yeah you know I… gosh, what an awful answer! I was like, “I actually like almost everything!” and I think that's probably why I got hooked so strongly and made that my career: Is that, you know in my first few languages— which were, you know, these abominations of a language, but that's alright, you got to start somewhere— each part of the process, like working on the parser and having an ASD come out like, “Oh, that's cool!” And then you learn how to do a type checker and you're like, “Yo, I just found a real bug in an actual program. That's so cool!” Working on code generation, “Oh, I can compile a program and it actually runs, it's an app, it's a real app now!” And I think each piece has some joy to it. Something, that's like once you experience it and experience success in that area, it feels like oh yeah, that's really cool.

James Munns

I can see why that's hard to answer, because now I'm thinking if you asked me the same thing about embedded systems or or like microcontrollers or things like that: my answer would probably sound a lot like yours. Of like what's your favorite part about embedded? And the answer is just… being there? That sort of sounds like what your answer is for designing programming languages too is: you enjoy being there which is, like you said, exactly why you're there.

Sophia Turner

Yeah, it's like the the joy of watching this thing evolve to have a new feature and all of a sudden now I can use that new feature. There's certain kind of milestones when you're working on a programming language that once you experience those, you're like, “Yo. Okay, there are definitely higher moments that are more than just- oh I got a feature working.” So for example, the first time when we're working on Jakt that the self-hosted compiler built itself. And you're like: ooohhhh damn… you get a higher high that feeling of accomplishment, because you know that that is a pretty serious milestone that not a lot of languages reach and then once yours does you just- you know you kind of pat yourself on the back and go okay cool. We have ticked this huge to-do item off the list and now everything builds on top of that. That's so funny, and like, my brain is thinking about programming languages and then it's switching to working on emulators. And I also love working on emulators, and one of the reasons is because once you get one of your childhood games emulating properly, you get that same kind of buzz of like, “Oh, look at it!” you know, nostalgia kicks in and then… You're actually playing it and you're, you're seeing that, you know, the emulator has matured to a certain point. And you have this really clear, ‘Good Job. You did it’ moment, where you know you can kind of see that and I think that there are a few things that have that nature in programming languages. Like that self-hosted compilation, that are the things that you remember even years later.

James Munns

Yeah, and that's interesting because like the the immediate goal for us right now was- so JP, or or Jonathan Pallant who's on the Embedded Working Group and is now part of the leadership council and and has been part of the… I've known him doing embedded stuff for as long as I've been doing embedded Rust stuff… but he's also working on an operating system project and that was one of those things of going back and Forth from him is: When does it go from being an embedded system to a computer, or an operating system rather, because it- the line gets real blurry. Embedded systems in applications and operating systems— depending on how you look at them and from where you're standing — they have a lot of commonality to them, where especially between like embedded systems and an operating system, you're writing drivers that interact with hardware and you're providing some abstraction on top of that, so you can achieve some other goal but… His distinction was: when you can design something that you didn't have in mind when you were writing the code of the of the system. So like, embedded systems are sort of very limited in that you design them to do one thing really well. Like if you're designing a printer, yes, you don't know what's going to be printed but you know that you're going to be printing or scanning and you have sort of a limited palette of options to work with, where when you have a system where you can run some language or load arbitrary programs and things like that, things get combinatorily interesting at that point because even with just 3, 4, 5, 10 syscalls, it no longer becomes possible to understand the full problem space. And same with programming languages- like, as soon as you have made a Turing machine, anything is possible more or less I suppose… and that's probably one of the interesting things of seeing other people build something that you didn't have in mind when you were designing a language or a system like that. Is that one of the things that brings joy to you, or is the joy more what you do with your system sort of thing?

Sophia Turner

There definitely is that joy, and it's a different kind of joy. I mean I remember when I was in graduate school working on my degree with this focus on programming languages and compilers I was like, gosh research is cool and all but I want to see real people use the stuff that I work on and ended up getting in on the TypeScript team but it was still a ah research project out of grad school and I was like, this is what I want, because once I saw people other than the people in that team like, go visit another team then see the kind of code that they're writing or having a video watching someone using your programming language for the first time… or they start becoming expert and watch them how they think through problems. All that stuff it kind of makes the language real — up until then, it's like: oh it's cool for us, oh it's a project that we're working on for ourselves, oh that's nice. The second someone else kicks the tires and starts making some progress and does something novel… everybody when they're programming has a certain fingerprint and the first time you kind of notice. Wow that's a very cool fingerprint. That's a different fingerprint than mine altogether.. Yeah, all of those kinds of experiences I think really make it feel like the thing that you're building is a tool for other humans… you know , it gets a little bit more abstract after a point, because it goes back for you know, however, many thousands of years that we as humans have built tools for other humans. And when you kind of strip everything else away, that's what building a programming language is. I'm just building a better hammer and then some master craftsman is going to pick that thing up and build something amazing and I'm just going to sit back and go, that's cool.

James Munns

Yeah I was gonna say the- well at least the ones you've mentioned so far I don't know if you have other stuff that was private, whether intentionally or or unintentionally reached ah a fairly large audience… I mean TypeScript is huge huge and then Nushell is something… well ah, how do I phrase this… You certainly were in Rust earlier than I was I joined… I started getting involved around 1.0 and things like that. But even back then it was still a community where if you were on Twitter if you were on message boards if you were on Reddit or whatever if you hung out in IRC, you knew what a lot of people were doing and then very quickly, Rust got too big for that for me and then but sort of the cycle started over with embedded where in 2018 we kicked off the Embedded Working Group and I probably knew the 100 people who had ever played with embedded Rust at the time and now it's getting to the point where there's like 2000 people in the chat room and I go, I had no idea someone was doing that today. But it's interesting to see Rust even like, 4 or 5 orders of magnitude out where I see people who either I followed them for other technical reasons, or, you know, friend of a friend of a friend sort of things — you see them playing with Nushell, or you see them playing with other components in Rust. Nushell has been one of those things that has popped up the most for me in areas of non-Rust people — it will just pop up. Where I was really getting at with that was: have you taken a different approach to building something for a small group versus a big group, or is it just you're building for today and sometimes you land on something that becomes a very big group over time?

Sophia Turner

I mean I think it's probably the latter. I don't think I'm wise enough or smart enough to be able to plan that far ahead. But sometimes, whether it's luck or whether it's a, you know, little insight that you have the smarts that day to be like, oh that's a good insight, I should do that thing… For example, working on the Rust error messages and moving us to the what, kind of, Rust is famous for these days with the the error message format, and doing that design in collaboration with Niko and Yehuda, but doing that design and leaning into it and making sure we succeeded with it and then… gosh so we did that what in 2016? And then today, pulling up all these other compilers and just going, “Ha! Wait… wait a second — that's the Rust error message format that we made in 2016!” Like, it's their version of it and I would never have predicted that back then, that it was going to be that popular even though, if you go back and read the original blog post, the name of the blog post is “Shape of errors to come”… but that was me being cheeky, that wasn't me trying to be, like, prophetic and yet that's really what happened. To answer your question, I can't predict these things. I just think that, you know, one of the things I learned working at Microsoft, working on TypeScript, I was surrounded by high world class language designers that had been there for decades that have worked on really important projects. Anders Hejlsberg is like one that comes to mind, he's like world famous for working on Turbo Pascal and working on all these other… working on creating C#. And you talk to these people and a lot of it is — yeah, obviously there's some luck, but a lot of it is can you just put the time in every day to solving the problems that people have if you can solve the problems that people have, you give them more and more reasons to use the project. So as TypeScript learned from other projects and listened to the users, they created a TypeScript that was much easier to use and much more flexible. When I joined the Rust project back in 2016, I remember sitting you know Niko down, Aaron down, and saying, “Okay, where are we right now?” Rust is a kind of research-y language, it's post 1.0 but it's trying to find its audience. It's got a rabid fan bases, but it's a rather small rabid fan base. How do we take that, and then grow that somewhere else? And it was the same playbook. It was saying okay, what are the things that are holding people back from picking up Rust? We put out the Rust survey, so I kind of designed that, put that out with some other community team and found out- oh, IDE support is missing and oh, these you know error messages need to be improved on all these things. And we kind of went through and removed the things that were slowing people down so a lot of the Rust 2018 was built on this - at least parts of it were built around this need for ergonomics, so the error messages the… you know we created RLS as part of the IDE support and that ergonomics kind of helped carry Rust forward. So it's not like, you know, back in 2016 when I was talking to folks, it's not like we predicted that in 2023 we would have like, I don't know, what are we at now? 4 million, 5 million users, or something like that?

James Munns

Ahh, I haven't even even kept… ah but every year that I see it, it surprises me.

Sophia Turner

Yeah, it's not like we could have predicted it. But I think it's one of those things that if you put in good work, listen to your users, remove the blockers for your users so that they're really being able to reach the power of whatever it is. In Rust, there's so much power in how the borrow checker worked. It already had all that value sitting there, then it was like how do we chisel around that so that it's this polished statue. And coming up with a way of presenting the information to the user or you know, Steve and Carol working on the the Rust book and coming up with a really good pedagogical foundation to teach Rust. So that, when people actually pick up Rust and teach Rust, and I know you've you've also taught Rust so you know what this is like. Once we had better ways to teach it, then it could just open doors for people. So a lot of these things that stopped people from getting the value, once we kind of learned as a project how to free that value and give it, make it available to people, I think that's where the things that didn't seem possible back in 2016, all of a sudden, those doors opened and Rust starts crawling up the ranks in the the programming language popularity.

James Munns

The metaphor that keeps popping into my head is is the difference between: kindling a flame versus… I don't like the metaphor of making it a “raging flame” you know what I mean but I mean like… I'm very much in agreement of you of: once you found the momentum, just keep building the momentum. It is interesting, because one of the first experiences I had with Rust was was going to RustFest in Berlin in 2015 or 2016, and… you might know his name, I think his name's Marijn Haverbeke, maybe? Gave a talk of … it was either the Rust that was, or the Rust that could have been or something like that… where he had been involved since fairly early like 2012, 2013 when it was still you know like the 5 or 10 people at Mozilla with Graydon who were working on it — of all the stuff that they tried, they went, “It turns out that wasn't right…” like, and I think he was in the point where he was sort of on his way out of the project where I think he saw it through the 1.0 and went, “Okay, yep, that was the experience that I wanted,” and I'm not sure what he's doing currently but… it was interesting because it was such a refreshing talk of of that, like just sitting with a very small language and figuring out what the niche was where there were all the things that the language had at the time like green threads or… for a while it was a language a lot more like Go and for a while it was a language a lot more like Erlang and things like that. The interesting thing I guess there is that they were solving the problem of building language for a browser. And I don't know how TypeScript started and maybe if you have some of the other languages that you were involved with at the very very beginning like you said where you were the second committer on there of — I'm guessing for all of those you had the concrete problem in mind of, “We don't know how we're going to solve this problem, but we know this is the problem to be solved.”

Sophia Turner

Yeah I think a lot of that early kind of DNA of the design does stick around even though things get adjusted. With Rust they did bounce around a bit, it was more Go-like… At some point, and I want to say this is when Patrick Walton — funny enough he was making a Nintendo emulator also — when he started this and made enough progress that it could run, but only use the borrow checker, and then showed that to the Rust Team to say, “Look the borrow checker. That's the value and you can lean on it.” You don't have to have all of these… this other stuff that they are thinking, “Oh maybe the borrow checker isn't strong enough. You need this, you need that…” and he showed that no, in fact, you could just build stuff with that. For other projects where, you know, I kind of came in really early — They already had a lot of that DNA. So, in the early days of TypeScript, they thought that the types would help execution speed. This is back when Javascript engines were racing against each other and whoever got the fastest engine results got some news post or whatever. It was a big deal back then to get really fast Javascript performance. So in fact, one of the two people that started the TypeScript project was the person that created the Javascript engine for IE. Like the the faster one, the newer one, from like 2010, 2011, 2012, I don’t remember exactly which year… but it was one called Chakra so that engine was made by the same person that kind of co-created TypeScript. So that was the original goal, but after a year or two, they realized: you know what, the performance aspect, that's cool, but the design aspect — being able to annotate a few types and in the IDE get error messages and completions — Wow, that's the winner. And that really became — in the same way that Rust kind of found itself, like TypeScript found itself fairly early on, and that became its reason for being since then… you know, let's make a language that scales up… the weakness of Javascript was that it just didn't really scale very well if you try to make a large application with it, with large teams good luck, no one really wanted to do that. But with some type information, you could enforce the kind of contracts between the components, now you can do it. So, you know, if we want to zoom out a bit: there's the projects finding themselves in the early days, and saying like what is the value really, what is the reason this thing exists? What's its goal? Once it locks in on that goal, then the rest of the time is kind of like you're saying — how do we polish and polish and polish some more, so that that goal is really clear in the documentation in the product itself and also we remove all of the obstacles for people being able to reach in and get that value back out.

James Munns

Yeah and I think you mentioned very, or a while back of just showing up, and I think that sort of kindling metaphor where you you sort of have to sit there, and you don't really know how it's gonna go because it depends on the wind and how wet the the ground is and things like that. Where, where you have to try a couple different things… but I guess the beginning it's just continuing to show up until you find that the right spark or something like that and figuring out what does click, or what is differentiating or things like that, of being there and in- whether it's like PC Walton's demo where you go, “We've played around with this for a while, but if you take this and this and this, this is the direction we need to go,” and then it does sort of switch to a… logistics and communication isn't necessarily the right exclusive category there but, like you're saying, it goes from being that very small people who have that sort of common vision of like, “Ah! This. This is what this does!” and that's one of those things that I remember really clicked for me, and then turning around and training was something that you had to spend a lot of time on whether it was with the errors or with teaching material and things like that… of taking that on the road is what really makes you go from the thousand people in the IRC room to the 4 million people on the surveys, when you you find the the way to communicate that and cut off all of the sharp edges, so that people do stick around. Which is interesting because I've gone through that part with the Rust project, but I've not been a part of that very beginning stage of like that kindling and iteration, and just trying things or- and maybe that's just all it is, is it's trying things and solving the problems you have today until you've built the structure where you go, “That. That is what we need to keep doing, for a long time here.” And I think that's sort of an interesting phrasing because I think that does actually help me relax a little bit if that makes sense? Of, it's not going to be clear until it is, so just make it fun enough to keep sticking around and keep iterating on it… It either will find a niche or it won't, and if it does then I know what to do next. But finding that place, where it just catches and it starts spinning on its own that getting there is the challenging piece.

Sophia Turner

Yeah, and I would say too something else and you're just reminding me, is that if you feel the value, that it's okay to just believe it. You know, when TypeScript started — and I remember this clear as day — when we first announced TypeScript, about 50% of the tweets about it were negative, even though we're, you know, this small team, we're really proud of what we're working on and they're like, “That is the dumbest idea I've ever seen. Microsoft what are you doing?” That was the kind of tweets that we would get. And, you know, we just went into work the next day, we just kept working on it. And with Nushell - something similar: it's like we knew that having a kind of a functional programming language with a single universal data format that you could kind of pass around was a really cool and really powerful idea. And if we had 10 users or 20 users or ten thousand, we're just going to keep hacking on it. Not to say we didn't have rough days — We, you know, the group of people working on it like wow is this thing going to grow? like but… you try not to have those days, and you try just to be like, “Do I still believe in it? Is the spark there for me?” So that I feel like working on it because the more time I put into it, the more polish I put into it — all of a sudden the stuff that I believed in, nowadays, Nushell is getting talked about more but it took years to get to that point. It's over 4 years old now and it's okay that in those first three, three and a half years that it was just the core team high-fiving each other when new things happened, and then sharing that rare tweet or or rare comment where someone's like, “Wow, Nushell’s really cool!” It's like, “Yay!” and you just share it around and you really enjoy and appreciate that moment. But really, it's a lot about just putting the time in because the time is the thing that really builds the system that when people come back and check it out a few years later they're like, “Oh my gosh! What can this thing do?” and, you know, the same thing with TypeScript — it just was not a success for much of its early life. I went back and looked this up — so GitHub stars is ah a bit of a vanity metric. It's not like the greatest metric in the world, but it does give you a sense for maybe how many eyeballs were on a particular project. I went back and looked: when TypeScript was announced as the language that Angular 2 was going to be written in. It had maybe 5000 stars the day before-

James Munns

Which is still of a fair amount!

Sophia Turner

Which is, it's, you know, it's a fair amount. It's not nothing, but really, it didn't take off- like it was a very slow slope. But when it found a particular audience and that even that didn't shoot it up like a rocket, but it just bent the curve. So all of a sudden, that was growing a little bit faster and a little bit faster and a little bit faster and then years later it's shooting up because the momentum finally started people noticed it and the Angular thing was kind of the first big vote of confidence that said, yeah someone outside of Microsoft, some other Javascript project said, “Actually, TypeScript rocks,” and that's what started it. But if we hadn't put in all the time to get to that point, the door wouldn't have been open. So yeah, it's ah it's a lot of- it's- there's a, there's a lot of grind to it. Yeah, absolutely.

James Munns

Man, very cool. Well I think ah, we're about an hour in. This has been, like I said, just relaxing and comforting. It's been very illuminating that the progression of the career is like: at the beginning, everything seems very simple. Like when- whenever you're learning something technical — whether it's programming or any skill or anything like that — at the beginning, it feels impossible… and then you learn a little bit and then it feels very easy… And then you learn a little bit more and you go, “Oh no, it's paralyzing now,” because you know where some of the the directions go. But then yeah, finding sort of that comfort level where you go, “Ah, it’s.. we're not going to know how it's going to go. It's going to be fine… but like, we know the big pits to avoid, and, you know, we'll just steer around those, and it'll take a while, and maybe it'll go off from there.” It's one of those interesting sort of inflection points of feeling not comfortable, to comfortable, to not comfortable before you get sort of into the final comfortable level if that makes sense but…

Sophia Turner

Yeah, you kind of make peace with it. Yeah.

James Munns

Yeah, you, you give up the hope of understanding everything and things like that. Ah, but yeah, it's been super comforting to hear that experience and sort of crystallize some of the the things that I saw in Rust from a very outside and non-involved perspective of being involved in figuring out where that sort of maps in the roadmap of 3 to 5 years from now and things like that. But yeah I super appreciate you taking the time to talk with me. You've mentioned a bunch of the stuff that you're working on — any other things that you are super excited about right now that you want to plug?

Sophia Turner

That's probably it! We just announced our plans to get Nushell to 1.0. If folks have been waiting to, you know, check out Nushell, this is one of those times if you want to jump in and help a project get to 1.0: we'd love to have you, come on by, we’re really friendly. But yeah, I've got other stuff kind of cooking in the background… we'll see. We'll see what other announcements come out in the next year or two. It's been a fun chat. It's been fun to kind of look back and think about the whole process of making something like a programming language and and how that works.

James Munns

Very cool. Thank you so much.

Sophia Turner

Of course! Bye.