Future of Coding - Unison's Paul Chiusano on how Abstraction Will Save Distributed Computing

Episode Date: September 13, 2017

In this episode I speak with Paul Chiusano (@pchiusano), creator of Unison, about his ambitious vision for the future, where we can abstract over distributed computing, and there are no apps.Support us on Patreon: https://www.patreon.com/futureofcodingSee omnystudio.com/listener for privacy information.

Hello, and welcome to the Future of Coding. This is Steve Krause. So today I have Paul Chisano here on the podcast. Let me tell you a bit about how we got to know each other. So about six months ago, a friend who knew I was interested in this sort of research sent me a link to something like this on Hacker News, an editable abstract syntax tree. I really was excited about that particular link, but even better was a really lively discussion in the comments where it seemed like everyone was competing to include as many links to similar tools as they could, and I collected all those links I think it was like

15 or so amazing links that I'd never heard of before and one of them was unison and through that I found a creator Paul and of all the links and of all the things I was planning to do that afternoon this was the most compelling so I canceled all my plans for the afternoon and spent the immediately next five hours reading every word I could find that Paul Chisano had ever written. I fell just into a deep, deep Paul hole and I loved it and it was wonderful. I learned so much about distributed systems and I got to see how his brain worked because he's been working on this project for three and a half, four years.

He's been bootstrapping it while he's been doing consulting. I was telling everybody, I told my parents about how excited I was about this Paul guy from Boston that I was reading about. And they said, wow, so are you going to reach out? And I was like, well, I don't know. And so the next day I saw that Unison has a Gitter account. And so I clicked on his name and I saw that I could write him a private message. And so I constructed one. I wasn't going to hit send.

But then, as you do, I accidentally hit the enter key when I was like half written the message. And so it sent. So I was like, all right, well, I'm in. So I might as well go all in. So I finished the message and I hit enter. And then he replied right away. And I think he was like, well, are you free right now? And so I was.

And we Google Hangouted and we got along. And then we decided to pair program sometime later. I wasn't much of a help for various reasons. A lot of what he's doing is over my head. But I was lucky to be helpful in other respects on the product side and various miscellaneous things. We've been working together in various ways over the past two months. And then a few weeks ago, if you read my blog, you remember I had a surprise trip to Boston for this conference.

And Paul was the one who invited me to that conference. And it was really fun. I stayed at his house and his whole family. And it was a blast. And now we're close friends. And we talk multiple times a week. And we're working on similar kinds of projects and it's really great. I guess some of you might know Paul from a different route

because he's also a bit of a Scala celebrity. He wrote a book about functional programming in Scala with his co-author, Runar. And yeah, I think right now or soon he's giving a talk at the main, like a keynote talk at the main Scala conference. So that's kind of his alter ego. He's a Scala person and he's also creating this new Unison language, which I think could be as big of a jump for creating technology as when Amazon created what we call the cloud computing. I think this could be an equivalent jump in the expressive power of technological systems. So without further ado, I bring you Paul Chisano. So I've got Paul Chisano here on the podcast. Welcome, Paul. Hey, Steve. Hey, Paul. Thanks for joining.

Yeah, thanks for having me. So you've been working on programming language research for like three or four years now, and I know your motivations have shifted over time, but what initially inspired this research? So yeah, it was sort of a combination of things. So yeah, I'd been working in industry for a while and doing functional programming in industry. And so first of all, kind of in, so something I sort of noticed

while just working as a functional programmer and building like, you know, bigger systems using functional programming is I had this experience multiple times of, you know, I would implement something in one way. And it might be like a few months later, or, you know, some period of time later, I would sort of realize that, or, you know, it'd be discussions with the folks I worked with, I would realize that if I had just done, if I had done something like just slightly differently, if I'd like used a slightly different representation, uh, or something like that, like it would have saved literally like months of work. And, um, so I kind of had that, uh, I had that like realization, um, like, or I had that sort of happened to me enough times that like, eventually, I sort of got it in my head that sort of there are these like foundational assumptions behind the software that we write.

And, and those foundational assumptions are like so critical and have such a huge impact on on your productivity. And you know how easily you can produce different kinds of software. And so I guess I was very much on the lookout for what are the core things that make programming these systems easy or complicated. And so that kind of was was in my head. And, yeah, so and one of the things I really like about functional programming, is that it's sort of this methodology where you can actually very quickly iterate on different

foundational assumptions. So like like when you build a functional system in a functional style, like, yeah, I mean, I like I found that just like whiteboarding with, you know, my colleagues, it was sort of like, we could, you know, figure out what the implications were of like 10 different design choices, very, very very quickly and also very precisely. So we can actually kind of reason about it. And so that kind of felt like a very nice thing to be able to do and kind of got me thinking more in that style. So that was kind of like one thing, sort of kind of rambly response there. Okay. So then the other, uh, the other thing I kind of noticed that's, that sort of started to bother me was that

there was a lot of my time, uh, spent as a programmer was, was doing, uh, kind of boring code or things that felt like tedious or needlessly complicated. Like I always, I always talk about, you know, there's sort of like the essence of the problem that you're solving. And then there's kind of like a whole bunch of other stuff that you have to do as a programmer around that. Like we had a, so I was working at a standard, standard and pores writing sort of software for the finance industry. And we had this portfolio analytics engine. And, you know, the, the, the engine itself was, was kind of interesting. It was like, you know, we were sort of building up these interesting computations for analyzing portfolio performance and breaking it down in different ways.

And so that was kind of like the core of the problem. But then there's like a whole bunch of other stuff that was not really like, you know, not really the core part of the problem. It's just like, okay, dealing with IO and like, how do you get the description of the job that you need to run? And you need to like, do some parsing there. And then like, how do you like serialize the results? And then okay, we're like running this on tons of nodes and doing a whole bunch of jobs in parallel and, and like, like all this other stuff that, you know, while it was obviously like important, it was like, it felt like there was a lot of repetition and tedious work there. And so yeah, I guess I started sort of feeling like, okay, I wonder if you could sort of get at the root of like, what is it that really makes all that other stuff so complicated or not necessarily complicated, but what is it that makes it so that all that other stuff

occupies so much of your time as a programmer? Okay, so yeah. So I'll kind of stop there. But yeah, so that was part of the motivation for like research into new programming languages. I see. So to go back to your first point about how picking the wrong foundation

can sometimes take months of work, add months of work, or picking the right foundation could cut months of work. Could you walk us through, like I don't know if you have any example off the top of your head, but could you walk us through kind of how, it's hard to visualize, like, months of work from one common, like, one bad foundation. Like, how would that play out? So, one sort of example is, so, for this portfolio analytics engine that I worked on, there's

different, I probably can't get into too much detail, but I think I can sort of give the gist. There's certain ways, there's different ways of representing the actual calculations themselves. Okay. And, um, I mean, there, and, and, and, you know, choice the, the first choice, uh, you know, it might be sort of very straightforward and, and, you know, kind of like the obvious, uh, way of representing those calculations. Um, but you might, the thing that you might not, uh, sort of figure out until later, and this actually kind of happened with us is that, uh, the first representation was actually like harder to compose into, um, into like a full like report.

So, so if you're running like a, a bigger, uh, job, you might have like a hundred calculations that you're all performing and, um, you want to be performing, you know have like 100 calculations that you're all performing. And you want to be performing, you know, all of them sort of at once, and ideally, and as few passes over the data as possible. And, and so so one, one representation actually makes that extremely difficult. And then another representation might make that job of composing a bunch of calculations into a very efficient overall calculation that does like a full report.

That the other, the second representation may make that a whole heck of a lot easier. So it sounds like you're talking about maybe the way you're laying out this data in different data stores, like maybe having it more normalized in an SQL data store. Is that what you're talking about

or is it deeper than that? No, it's more like probably the best analogy would be like if you have a calculation and it's represented as just like an opaque function. Like, you know, it's a function from say, a time series of, you know, portfolio returns to whatever, another time series output. And if that's sort of like your core representation is like the sort of more opaque thing, then, you know, if you wanted to like, do two calculations over the same time series, then you really have no choice but to like,

do two separate passes over the data. And, you know, call, you know, call the first function, it burns through the time series and computes its result. And then you call the second function, which also goes through the time series and computes its result. Whereas if you, if you have another representation where it's not just as opaque, then you can actually combine representations and into like a fused computation that does say both, both calculations in one pass. I see. Okay. So, so things like that. Um, and yeah, that was, that was just sort of like the

first example that I thought of, uh, off the top of my head. It's funny. Like I, I remember the, this experience of like having this like, Oh, Oh why didn't you know we do it this way before and that would have been a hundred times easier and like i remember just that that's like that's the memory that i have but then like you asked me like what were the specific uh cases and i'm like geez this is actually a while ago and i don't i don't actually remember most of them so i'm actually surprised i remembered that one example. Yeah, it was very formative. It's a very humbling thing to just see how badly you can make technical decisions and then build on those bad decisions and then, and then build on those, those bad decisions. And then like,

realize that, wow, you've, you've built this like skyscraper, you know, foundations and it's, you know, you could just keep building on it, but you can just sort of see that that's going to just make things worse. And, um, yeah, so, so that like, yeah, I just have this, this, it created this drive that like, I just, I really want to build on the best ideas and figure out what the best foundations are. Yeah. Don't we all? This, it makes me think about, like, I feel that way all the time, that I screw up technical decisions. Right now, where my head's at is I have this big Firebase database, and I constantly am running into problems

with the way my data is laid out and not being able to access it in the ways I need. And I keep changing the ways I lay it out in Firebase, but it feels like the fundamental assumptions underlying how Firebase works are working against me rather than working with me. And I have to almost be like a genius to lay it out in the right way. So anyways, that's where my head's at now.

I want to transition to one of your initial blog posts when you started doing this research that the blog post was called like why designers should care about type theory and the future of apps something like that yeah so why do you why is type theory uh important here and what does that unlock for us okay yeah so right so the the blog post yeah i i think it was probably around that time I was, yeah, I kind of wrote up this like, it was like almost like a manifesto. And about sort of how I sort of think about software and really just like computing in general and how we organize computing. And so I guess it starts with this view that, and honestly, I'm like,

I'm still trying to figure out the best way to explain this viewpoint because it's sort of a subtle thing, but, um, so, you know, you can tell me that my explanation is terrible and, but, but yeah, so I'm going to do my best here. Uh, but it's, so it sort of starts with this view that, um, interacting with a computer, um, is whether you're, whether you're doing it, you know, as a programmer, obviously you're interacting with a computer and you're describing computations by, you know, editing a text file. But it's, the view is that when you interact with like an application, you're also doing a form of programming. It's just that it's the application is kind of a very limited programming environment. I mean, depending on the application.

So like, I mean, so certainly, if you're like, you know, a programmer, and you're like editing, you know, a Java program in Eclipse or something, you know, okay, we all have a sense're like, you know, a programmer and you're like editing, you know, uh, a Java program and a clips or something, you know, okay, we all have a sense that like, that's, that's programming. Um, but, and then I think a lot, a lot of people would also say that if you're editing a spreadsheet, uh, that's, that's also a form of programming. Uh, it's just that, you know, spreadsheets are a more limited programming environment. It's more, they give you access to a more limited programming model. But it's still definitely a form of programming.

You know, you're creating programs, you're interacting with them. And, you know, the spreadsheet is like an editor for a programming language. But I guess the view is that it's not just like spreadsheets and text editors that are, you know, access to programming. It's really every application is a way of describing computations. And it's just that, you know, even like Gmail, you can't really do all that much in Gmail other than sort of like the fixed set of computations that Gmail gives you access to.

So it's not all that expressive, but it's still, there's that idea of like, you're giving the user access to, um, you know, the ability to define certain kinds of computations and you're giving them some sort of editor or that's, you know, somewhat interactive for defining those computations. And so, um, that viewpoint that all, all of computing is computing is a form of programming and program editing is like sort of that manifesto blog post was sort of like a call to like, hey, what if we kind of actually try to organize computing in this way much more explicitly? And if you recognize sort of all of computing as a form of programming,

then all of a sudden, like, all these really powerful tools from the programming languages world, you can, like, bring them to bear on the problem. And so that's things like type systems, and, you know, composability, abstraction, like all these things that are incredibly useful for programmers, like, wouldn't it be awesome if sort of ordinary, you know, end users who aren't, you know, expert programmers also got access to that that same stuff um and yeah so yeah so i'll pause there uh yeah well so um to what would that unlock so if we had composability and abstraction at the end user level in g say, like, what could we do that we can't do now?

So, yeah, that's a good question. I feel like I should come up with some better examples. So one example that I was, yeah, I had another post about. I was just talking about, like, I was in a Word document. I was editing a Word document. I was editing a Word document, and I had this task that I needed to get done. I was like, okay, I needed to go through all of the tracked, somebody had tracked changes on the document, and I needed to go through all the tracked changes

and, like, accept all of them and then get rid of any other comments or something like that. Um, and I was like trying to figure out how to do it and like the, you know, words like interface and, and, you know, there's like, there's like some menu option for it. And like, eventually I just sort of like gave up and I'm I'm like okay let me just like Google this and okay then I figured out how to google it or sorry I figured it out it was like not not a big deal but then I was like thinking about there like a whole bunch of like even like slight you're like related use cases like what if I wanted to delete comments that were made by me you you know, within the last week,

or something like that? Or, you know, comments that were made by Steve, you know, that mentioned the word, you know, unison or something like that. I mean, and I just kind of like came up with those use cases, like on the spot and i think if you so first of all those right right now to like do to do that uh computation it's like word does not have like an option for that or or i mean it's like as soon as you move even the slightest bit away from like the completely like standard, like vanilla things or that you like fixed set of actions that are exposed by word. Um,

you're like into like uncharted territory of like, you know, you have to like, uh, either do it manually or like learn some, you know, obtuse, uh,

programming language for like scripting word documents or something like that i think this sounds amazing like being able to you know really have the expressibility over all the data and all the apps we have and so i think like uh this sounds pretty similar to the vision at least i don't know in practice of like ifft like if and zapier so how do those tools maybe you don't know them but how do those tools in your mind like not um live up to this vision that you have in your head so yeah i think um those are good tools so so i think i mean so in general i think it's like okay so apps don't really support i mean out of the box they don't really support any kind of like customization or fine-grained

access to you know you know different types of computations and so so so out of the box they're they're these very rigid things and and and everybody kind of knows that. And so, so yeah, something like if this, then that, and, and, and Zapier are, yeah, like on the one hand, it's like, okay, great. This is like a step in the right direction of like, okay, you're providing access to some amount of programmability, um, that, you know, you can use to extend the functionality of these applications and do more with them. And so that's, that's cool. Okay. But yeah, I guess what I would say is like, we can just do so, so much better than that. I, I mean like, like it would,

it would be very easy for me to come up with use cases, uh, you know, and I can probably, I can probably like rattle off like 10 on the spot that, you know, where like if this, then that like doesn't, it just can't express it. Um, and so, so, and, and I think the, the main problem is that you actually want something that's extremely general purpose and that could, really in theory, you could express absolutely any computation you wanted. And if you don't, if you don't sort of start with that, then you're always going to be taking something that's not really general purpose and then kind of like bolting on, you know, a bunch of like ad hoc integrations that, you know, kind of sort of do, you know, the use cases that, that, you know, the people are

requesting the most that day, but, but it's, do you know what I mean? that um you know the people are requesting the most that day but but it's do you know what i mean it's like not really solving the fundamental issue which is that you really should be able to express really anything you want and uh yeah i mean another thing is like just as me personally like i you know i like like open source technology and and i really yeah it makes me yeah i guess i would much prefer that when i interact with computers if i have to define that function that's like you know the uh accept all changes you know made by me in the past week. Like that little snippet of computation that I define. Like if I have to define that, it's like I want to own that and not just have it be like tied to some proprietary platform

that, you know, who knows what will happen to it. And I think that's especially true as you start building more sophisticated programs and computations is, you know, you're like, yeah, I don't want this to just be like totally owned by one company and who could like cut off my access to it,

you know, at any time. And so that's, that's more of like just my personal preferences. Like I don't want to, I don't really want anyone to like own the core programming technology and be able to like cut off access to it. I don't know. So. Do you still believe in this vision for the future of software?

Yes. Yeah, definitely. I mean, I think it's, it's a very difficult thing to, to do. And I think it's, you know, like, I feel like there's a lot of research that needs to be done there, but it's, it's also something I'm like really excited about. Cause I think it would just unlock all these possibilities for, for lots of people, uh, using computers. Um, I actually, I thought of like a really good um analogy i was actually i was talking to um my friend uh runar bjarnason about this he he was co-author on on the book and i also worked with him and um which book uh this is the functional programming and scala it's a a book on functional programming that we wrote together and we were we were were talking about this kind of vision of like, you know, this sort of application-free world

and like kind of what it meant. And we came up with this analogy of like, what we want is, we want it to be like, okay, there's this, we want it to be more like Spotify, okay? Like, or, you know, existing like a streaming music service. There's this full set, there's this huge set of like possible songs that just exist, you know, on Spotify. And you can take any of those songs that you want and like assemble, you know, 10 of those songs into your own playlist. Right. And you don't need anyone's permission to do that. You don't need to like, you know, hire somebody. You don't need to like wait for like a record company person to like put together a compilation album. You just do it, right? You see, you have like access to like the full space of like possible music and you can like assemble that into little albums and playlists and things like that of your choosing. And like, and so like, yeah, the vision is like, yeah, it would be so great if we could do the same thing kind of with computations, where it's like you as a user of a computer you have access to all the computations they're all out there and you can assemble them into you know you know

something resembling an application but it's it's more like a playlist because it's not like uh you know you just say like oh i need access to like the send email function and this, this piece of functionality and that, and you just like, boom, bring it all together. You don't need to like, you know, even be a programmer to do it. I mean, you're doing programming in, in, you know, assembling, you know, all those functions into kind of one place, but there's not these like rigid barriers between things and, you know, really anything that you can imagine that's useful to do, uh, you know, can, can be done. And, um, and so that's like, that just sounds like amazing.

So, so I'm still like very excited about that vision and kind of making that work. Okay. But, um, by the way, did that, I don't know, what do you think of that analogy? I'm curious, like, did that, I don't know, what do you think of that analogy? I'm curious, like, did that make any sense at all? It made a lot of sense. I guess I see how Spotify gives me control over songs and how I can turn songs into a playlist. And so you're saying, so code could be is the analogy is that code could also be songs and i can mix and match code together yeah so so think about like you're working in

like gmail okay and like like i like the analogy is like gmail is like an album that, you know, or somebody has put together. It's like a fixed set of actions that you can do, right? But if you want to like, you know, do something in response to an email, like when you get an email that mentions a certain subject, you want to do something with it or maybe you want to like batch up a bunch of emails with that mention a keyword into a weekly digest or whatever it is like unless that the gmail application sort of already has that functionality available you're you're sort of like out of luck or maybe's, maybe somebody's written like a plugin or something that does it, but it's like, okay. So, but what I'm saying is like,

no, literally, like you would just have access to, you know, yeah, if you needed to like, pull in some additional functionality for, for working with your email and do anything you wanted, like no matter how complicated how complicated um you would be sort of empowered to do that and you wouldn't be constrained to like just have this like fixed set of of actions uh i i like this analogy a lot and it the way you think about uh how you have the space of all songs and you can kind of mix and match as you want you don't have to think about you don't need a label to kind of make an album for you. I like that part of it.

It feels like if I were going to make a Gmail album of computations, it would be more, it wouldn't be a sequential list of things. It would be like, the way that the computations in the Gmail playlist would relate to each other would be like nested, like a complicated nested structure-y thing. Yeah, yeah, yeah. Right, yeah. So that's a part of the analogy where it breaks down for me.

But besides that, I like a lot of it. Cool, okay. Yeah, still, yeah, definitely still trying to, like, figure out the best way to, you know, talk about this stuff. So I just have a quick question for you. Sure. And then we'll talk

more about Unison specifically. From my perspective while that while Unison does forward this vision in some degrees and they're related in some degrees, Unison is kind of solving slightly different problems in a slightly different way or would you disagree with that? Yeah yeah so. So I think Unison, like the stuff I've been working on, especially more recently with Unison, is like it probably does not seem, you know, obviously related to any of that kind of, you know, vision of like how we could organize computing differently.

And so, yeah's that's definitely true okay great cool okay that'll clarify um cool so now maybe i think it's time to give the the unison uh like overview um like if maybe if you could start about like uh what problems uh does it solve um yeah you start with what problems it solves and then maybe go into like some of the specific features you're excited about. Okay. So.

Well, actually, sorry. Hold on. Yep, go ahead. I'm wondering now, I kind of want you to start with with how you, like kind of your history of working in Unisense. Yeah.

Start with like why, like the problems you initially wanted to start working on why you built a semantic editor then what you realize you know kind of walk us through that whole thing okay yeah so i guess when i started working on unison it was like you know i was sort of like i i kind of joked i was like okay i'm just gonna try to fix programming like it was just you know this like crazy research project and I was gonna explore a bunch of stuff and like you know there's this there are a whole bunch of things about uh programming that and computing that that was like wow this could be done so much better and And, um, and so I, you know, it was just like kind of exploring different aspects of that. And so, um, and yeah, a lot of it came out of

just my experience, like working in industry and seeing, seeing what was hard and what was more complicated than I felt like it needed to be. Um, so, so one of the things I focused on initially was the programming language editor so I'd always thought it was kind of archaic that we're still editing our programs in text files and you have syntax errors you have type errors I mean type errors are okay but what's kind of not okay is that you write a whole bunch of code in this totally unconstrained uh

format of like a you know text buffer and then you submit that as a bat you know in as a batch to like the compiler and then it spits back a whole bunch of errors and you know like that it just like didn't seem like a really good experience and you know if you are implementing a refactoring you're doing like text munging um and like yeah there's sort of ide's that exist but like i just kind of thought that things could be done a lot better if it was a more structured editor. And so, yeah, I, so one of the first things I was working on with Unison was this, um, uh, I call it like a, a semantic editor, um, where, so it wasn't just a text editor. it was an editor for the Unison language, where you could not have a syntax error or a type error. So if you, so the syntax errors, that's actually pretty easy to achieve, preventing syntax errors. You know, you just like, you don't like make people manually balance parentheses and and things like

that and so so that's kind of not not too hard um and then but then actually preventing type errors um like that kind of required like a little bit more rethinking like that that means that you actually need to prevent people from like just putting anything they want. That's, that's, uh, certain just at any point in the,

in the tree, in the syntax tree that they're, that they're editing, you want to make it so that, Oh, if they are trying to call like the square root function and they go to fill in the argument to square root and they open up the, you know,

the editing box. Uh, and if they try to like put in, uh, some text there and it would sort of like not, not even let them accept that, that change, like the, you know, the box would turn red and it would say like the goal type here is you need to provide a number and you're providing text and you know, that, that doesn't work. And so, so yeah, I kind of liked that idea and I was like exploring it for a while. And if you, if you go on like, uh, unisonweb.org, you know, it's, which is basically like a research blog. Um, you know, you can like see some like past experiments with that. um okay so that was like pretty interesting but okay but then the other thing that i was was really interested in doing something about

was making it simpler to build uh like distributed systems and in so so i guess like the this was kind of like the other thing that that i thought could be like made way better about about programming is that um yeah just from my experience it was like a lot of the um a lot of the work that i was doing was just like in, you know, not, not writing the logic that ran on like a single node, but it was in, you know, you have a system, an entire software system where it's a whole bunch of nodes and they all need to talk to each other, coordinate in some way, uh, to do some overall computation. And it was all that other stuff of like stitching together a whole bunch of nodes into, into a cohesive system. Like that was, that was like another big area that felt like there was a ton of complexity that could be reduced. And so, um,

yeah, I guess I kind of got to a fork in the road where I was like, okay, this research on the editor is like pretty interesting, but, uh, you know, do I, do I want to focus more on that or do I want to focus more on the core language and its support for building distributed systems? And I, I guess I kind of came to the conclusion that I felt like the having much better support for distributed systems was like that was that was like more of a bottleneck for like at least my productivity as a programmer because I guess the thing about you know the our editing tools is they are kind of archaic, like editing, you know, in a text editor and like, you know, even using Git and, you know, all these things that programmers use. Like they're definitely archaic and you can definitely look at them and say like, okay, this could be done a lot better. But at least if you're a programmer who's been doing it for a while, you just sort of attain

a level of fluency with those tools and they, they become much less of a bottleneck for your productivity. Um, even though you kind of recognize that, Hey, that it can be done better. And so, so yeah, I just sort of made decision, like, okay, I'm going to focus on this thing that really is, like, a big problem for myself and for, you know, other people who are professional programmers. So, yeah, that was kind of the decision I got to. But, I mean, I'm still really passionate about the other stuff, but, you know, there's only so much time in the day. And, yeah. Cool. That makes sense. Uh, I really liked the talk you gave at the Boston workshop a few weeks ago, uh, explaining why you think there's, uh, there's more room at the bottleneck that you're

working on as opposed to the one you used to be working on. So, um, I don't know. I think you did a pretty good job here of explaining it, but if you wanted to be working on so um i don't know i think you did a pretty good job here of explaining it but if you wanted to talk more about like why you think that is yeah so in particular i really like the analogy of the uh the brain interface to x86 assembly okay yeah okay yeah so right i i sort of like um you know i I was thinking about like, okay, in terms of what has, what makes the biggest impact on, you know, our ability to like create programs. And so, so one, one area that we can focus on is like, is doing things to like reduce program complexity.

So that's things like, okay, introducing new programming languages that are more composable, that are easier to think about, that are easier to glue programs together into bigger building blocks. So that's things like moving from x86 assembly to a high-level modern programming language like Haskell

or something and okay so so that's kind of like one one thing that we can focus on and then the other the other area that we can focus on is things like just making the interface to programming and editing programs, like more fluent, you know, more direct, more immediate feedback, you know, things like that. And yeah, so sort of like the, you know, the logical like endpoint of that might be like a direct brain interface where, you know, like, yeah, I imagine you could like write x86 assembly or produce x86 assembly code at the speed of thought, you don't even have to type it. You know, maybe you have all kinds of information about x86, that's like instantly at your disposal, you don't even need

to like open up a new browser tab, It's just like instantly there in your brain. And so that, that would be like a very fluent interface to you know, x86 assembly. But you know, that it's, it seems like it's probably more important or you get more bang for your buck by just like simply moving to a better programming language that, you know, is much less complicated to program with. And even if you had to

like write Haskell in, you know, a dumb text editor, if you're building a program of any significant size or complexity, you know, Haskell is probably going to be a better choice than writing an assembly code, no matter how quickly or how direct the assembly code generating interface, you know, is. So, yeah, that's kind of, that was like a way of thinking about, you know, what, what the relative priorities should be of, of, you know, which ones we focus on. I do think it's, it's more of an open question now, like, like right now, like sort of with the benefit of hindsight, we're all able to look back at, you know, you know, like assembly language, and we're like, I'm glad we didn't stop at assembly language.

Like, I'm glad that we, you know, kept building additional languages that made it a lot simpler to build these bigger software systems. Right? And people are like, okay, yeah, I'm glad. That definitely paid off. But if we're like asking that same question today yeah i guess i'm always like curious like what do people think about the future is it are we kind of done with programming languages and they're all kind of the same at this point and we're not going to see any real

major advancements or you know are there are we going to maybe see another big jump of going from assembly language to high-level languages? And do we still have that in the future to look forward to? Yeah, well, I think that's kind of the topic of Brett Victor's future programming talk that he gave at Dropbox. And I kind of referred to that in the first episode of this podcast that the core thesis I have at the very bottom is that there are improvements to be made. We don't all agree on what those improvements are. But I think most of the people

listening to this right now will agree with you, or at least they want to believe that there's more improvements to be made. We can do better than the languages we're stuck with right now. Sweet. So I think now would be a great time for you to kind of walk us through what problems Unison solves and some of the features and some of the accomplishments you've been able to achieve so far.

Okay, yeah. So Unison is, so the core language is, I'd say like the defining kind of characteristic of it is that it lets you treat any sort of pool of nodes or compute resources like it's a single computer. And so you write a single Unison program and when you run that program, it is actually going to evaluate.

It's going to spread itself out onto however many nodes you spent that are specified in the program. And it might, so it might be running on like thousands or tens of thousands of nodes, but you just wrote kind of one program to describe all that. And so it's really like that entire, uh, that entire, you know, collection of computers is like functioning like a single supercomputer. And your Unison program is just, you know, running on that supercomputer. And like, so that's kind of the view. And it's in order for that to work, like there's a bunch of things

that the language runtime needs to be able to support. And by the way, this is like, you know, there hasn't been a release of Unison yet. The project was in R&D mode for a while and we're actually,

we're just now kind of working on getting to the first release and it's building the actual Unison runtime. Um, so, you know, just, yeah, to take everything I'm saying with a grain of salt, but, but yeah, that, that's kind of the view is you, you write one program, it runs on however many nodes you want it to. And the run, the Unison runtime is, is handling all kinds of stuff for you under the hood. It's, it's doing like deployment of code dynamically. It's happening transparently. You can hop computations between nodes and Unison will be, you know, serializing those computations

and, you know, you don't have to be writing like parsing and serialization code and sending JSON blobs around. Like you're not worried about any of that. You're just kind of focused on, you know, defining the computation itself. And yeah. So to be honest, this sounds like, you know, too good to be true. I had a class in college where we had to follow Larry and Sergey's initial paper that described the Google search engine. We split up into two and four. We all took a different piece of the search engine.

And then we had to, like, you know, bring it together. And it took us hundreds of hours and thousands of lines of code. And I see on the Unison homepage you have a fully functioning search engine in, I think, what you said, like, 15 or 12 lines of code and i see on the unison homepage you have a fully functioning search engine and i think what you said like 15 or 12 lines of code like how does that make any sense okay yeah so um i think i mean okay so so i i want to like give a caveat here. Like, so we don't totally, I feel like we actually don't totally know how, how complicated, um, it, it is to, to build software systems in the sense that like, um, there's so much like incidental complexity that exists right now that, um,

we, we, we, we do, we do know that there are like additional sources of essential complexity. There are like new things that you have to worry about if you're building a search engine that, that runs on,

you know, 50,000 nodes as opposed to one node. Um, and, you know, same thing for something like Twitter, you know, um, if you're building Twitter and it's, it's running on tens of thousands of nodes versus one node, like there's definitely, there are like essentials, uh, there are actual additional

sources of complexity. Um, and so I, I, I have more of a hypothesis, I would say that the, the amount of additional complexity of building even a distributed search engine or, um, or like a distributed version of Twitter or, you know, Twitter at scale, or really any of these like big, uh, software systems that exist in the world uh is like my hypothesis is it's it's really just there is some additional complexity but it's like constant factors it's like maybe it's 10 times as much work to build uh you know twitter at scale versus twitter on one computer but it's not you, a thousand times as much work. It's like a pretty small, like, constant factor.

And so, yeah, like for this, like, search engine that I sort of started working on as just an example just to kind of explore the expressiveness of the Unison language is, so here's kind of what I found about that process. So what I found, and this is also true of like, I also have done some experimenting with like building a distributed version of Twitter, distributed scalable version of Twitter is like, there's actually not that much. There's not that much that is really unique to, I almost feel like Twitter is a better example so maybe I'll just

kind of talk about that but yeah there's not really that much about say Twitter that is really like unique to Twitter and likewise there's certainly a lot with like a search engine that is not really unique to the search engine. So, I mean, for a search engine, you have, I mean, the big thing that you have is some sort of search index. Where, I mean, this is at least in like a simple search engine.

You know, I'm sure Google has, you know, all kinds of bells and whistles and additional stuff. But, um, you know, like a search index, you know, it? Because if you've like indexed the whole web, you know, it's a ton of data. And so, you know, it's not all sitting on one computer. But that's fine. But the data structure itself is, it's actually doesn't really have anything to do with search engines specifically. It's just like a general purpose distributed data structure. Um, and it's, it's really the same thing with

Twitter. Um, you know, so it's like when you actually like break down the problem, uh, into it's sort of like little pieces, you realize that, okay, a lot of these distributed systems that people have spent tons of time building, they're actually just composed of the same sort of ingredients, I guess. And if you had a programming language where you could like properly abstract over entire distributed system components, like very easily, um, which is, and that's like what Unison is like really designed to do. It's

like, it's this programming language. You can, you can have an entire distributed system be like wrapped up in like a function, you know, or like, yeah. So it's like, it's, it's really meant to be like as composable, uh, as you know, as it is when you're like writing code that just runs on one computer. Um, you know, any piece of functionality, you can pull it out into a function. You can abstract over stuff, all that. But now you're doing that at the level of whole distributed systems. Yeah, so it sounds like this is really solving that initial problem you had. You mentioned when you were building dashboards with that opaque function,

you didn't have composability. It sounds like this would have solved that problem. Yeah, so I think just in general, composability. It sounds like this would have solved that problem. Yeah, yeah. So I think just in general, composability is an awesome thing, and that's basically how we can cope with complexity of building software. We don't just fill it in brick by brick.

We create these building blocks and create more and more ways of gluing things together. Well, here, I liked the analogy you had in that talk you gave where you start with two bricks and you make a brick that now contains those two bricks. Then you use that brick to create a bigger brick and then use that brick to create bigger bricks. So as a visual way to think about it, I think that's to show the power of composability. Yeah, right. Yeah, you never want to just be like, you know, like if you have a system that is going to run on 100,000 nodes, like it should definitely not be 100,000 times as much work as if it runs on one node you want it to be

like you know something that's more like a logarithmic thing where it's like yeah you you just sort of keep building up these bigger and bigger blocks and then it's like okay great you get to the end and you've built this like massive system but you've just done it in this very like composable way um and so yeah so i think just i mean like a search engine you know like the actual search part of the search engine where it's like once the once you have a search index and you have, like, the web crawlers that are populating that index, like, the actual search function is the stuff that's actually unique to each system is, like, I don't know, you find that it's, like, actually kind of small, or at least it seems that way to me. I mean, I can't wait to actually like,

once Unison is released, and you know, you can actually it's like a real implementation of a programming language. Like, I can't wait to actually like, try it on on on stuff, and actually see if it really is like, as easy as it seems like it will be. But yeah, when you can achieve really good reuse and composability at the level of entire distributed systems and package all that up into functions that you reuse over and over and data structures that you reuse over and over,

that's the thing that makes it so much simpler to build these systems. And honestly, I kind of suspect that, I don't know, like even've probably seen at least some of this, like, composability, like, you know, within their own internal tools that they've built that aren't all, you know, exposed to, you know, the public. but yeah so it just seems like there's there's a lot a lot of things that can just be like kind of written once and then reused over and over well i guess to take the other side of that it seems like from what i know about facebook they kind of take the opposite approach where if you want a tool like an internal tool to do something slightly different than the one that exists you just you know scrap it and build a new one uh you know i think that that there's like on the one that exists you just you know scrap it and build a new one uh you know i think that that there's like on the one hand there's the functional programming approach where

you think about your beautiful abstractions and your type systems and you build it beautifully from the first time um but but like sometimes i i think as a mere mortal like it's just easier to like hack it together and you know node and php and javascript and and then just if it if i want to change it later i'll just rebuild it so what's you know like how do you how do you think about like you know for the rest of us who aren't as smart as you are how do we like why like how can functional programming systems be made more mainstream? Well, yeah, I mean, so first of all, yeah, there's,

there's definitely nothing wrong with like rewriting code and you know, I do that all the time and yeah, you, you, I feel like the, it's sometimes it's better to not try to introduce abstraction kind of too early before you really understand like how to do that well like sometimes it's better to just like oh i have this the system i'm trying to build and i'm just gonna like kind of you know hack it together and not not try to find like the beautiful reusable core bits right uh but yeah, but yeah, at a certain point, like you or somebody like you, you can sort of, when you understand the problem better, you're like, oh, okay. Uh, Twitter is, you know, as a distributed system, it's like, oh, I can actually assemble it from a few different, just very general purpose pieces. Like, oh, okay can actually assemble it from a few different just very general purpose pieces.

Like, oh, okay, it needs a distributed hash table that does like a certain kind of load balancing and like demand driven replication. And like, okay, that's cool. Like that is totally generic. I can pull that out into like a library and just write that once um and then like maybe there's like some other aspect of twitter where it's like oh um actually there's like stuff with like uh you know managing like user accounts and you know updating like access like sort of doing permissions of of users and discovery or like that type of thing and like like, Oh, I could like, I, now I fully understand that problem.

I can, I can factor that out into, into a nice library. And I think the key thing is that the, the person that discovers those really good abstractions and, and introduces those libraries, that, that can be a different person than,

than the people that are just using those libraries. And so it's like, it's actually a good thing in that not everybody has to be like this expert on, you know, abstraction. And, you know, finding the best abstractions. It's like, there can be some people who are really good at that. And then some people are like, great, I just call the function that somebody else has written that's very easy to use. And that's what composability and functional programming really helps a lot with, is you can build these very nice,

very easy- use uh apis libraries and there may be a lot of sophistication behind them but uh you know the way you actually use them it can be very straightforward so cool all right yeah that was that was great can you talk about content-based hash for identity around unison terms yes yeah so um so if you want a programming language where it's like the programming language you know is like describes an entire distributed system um like a, a big problem that you need to solve is, okay, well, in a distributed system, maybe you have, like, thousands of nodes,

and the nodes are going to be talking to each other, and data and computations are going to be moving between nodes. And so there's this question of, like, okay, so how do you do that how do you like actually send a computation from one node to another and so it's kind of easy to think about like okay if you're if you're just sending like a number or like a list of numbers or something from like you know one node to another you're it's sort of like easy to think about how you would how you would make that work but

if you're sending like a function between nodes which and and I would I would argue that's like extremely useful to be able to do it's actually kind of necessary that you'd be able to do that is that you can send not just not just like numbers and and strings and so forth but but actually arbitrary computations that have functions in them and so forth if you want to send functions around you have this like problem which is that how how do you actually identify um what the function is that you're sending. And so the first way that you could do that is, like if I'm sending like the factorial,

say I'm like sending a computation to the Steve node, and I'm saying, okay, Steve, I'm gonna move a computation to you that computes factorial of 10. And so, like, there's this question of, like, okay, how do I identify, how do I tell you about, or what do I actually send to you? Do I just send the name factorial well if i just send you the name factorial uh then that's kind of that's that that's probably not going to work because how do i know that you have the same meaning assigned to factorial as as i do like maybe you have a different definition of factorial

than the one i was thinking of um and that that gets to be even more of a problem when, you know, obviously, like, you might have an entire ecosystem of libraries that are written with different versions of libraries. And, you know, it's sort of like not really sustainable or scalable to just have unique names for every single function and expect that everybody in the universe is going to pick, uh, uh, uh, a different name. Uh, so, so using names is like, that gets very complicated. And, um, so the, so what you can do instead, um, is, is instead of using names to identify functions, you use hashes to identify functions. So, and the hash, so if I'm sending you a computation that's like factorial of 10, we would, I would tell you actually, I wouldn't send you the name factorial, I would send you a hash of the factorial definition.

And the hash would actually incorporate both the definition of factorial itself, like how it's defined exactly. And it would also incorporate the hashes of any of the dependencies of the factorial function. So it really does exactly pin down the particular implementation of the function that I'm talking about. And so I would send, I would say, Steve, I want you to evaluate, you know, this hash applied to 10. And you would say, oh, great, I already have that hash, because, you know, you asked me to evaluate this last week, and I cached it. Or you might say, oh, I don't know about that hash. Can you send it to me? And so I would, at runtime, this is in the Unison runtime, I would synchronize that hash to you and you would cache it locally and then you would proceed with the computation.

So that's kind of the basic kind of core idea. Um, and it's, it's not really a new idea. Uh, yeah, I mean, people have been identifying things by hashes for, for a while. Um, yeah, in fact, there's, yeah, there's something called the Nix. It's like a build tool where you, you, they're using hashes in a similar way but it's at the level it's at the granularity of an entire um code base or like project um whereas unison is like it's really at the at the level of individual functions in in the unison language and um so it's an idea that it works really well. It's very robust. It's, you know, makes things a lot simpler when you're building this kind of distributed runtime. But it also has all these interesting implications for kind of the rest of the

programming language. And those kind of needed to be like worked through. And yeah, that was actually a lot of the research on, like in unison was just figuring out, yeah, okay, this is like a great like starting assumption, but there's a whole bunch of stuff that needs to be figured out after this to like, you know, build a complete programming language that you can actually use

so as long as i've known you whenever we talk about interesting things you talk about how you like to have a framework by which you make your decisions uh like makes you more comfortable that's how your brain works thinking through a framework so could you walk me through how you became that way what are some like example frameworks you use often you know what you're like i'm asking for the framework framework if that makes sense yeah yeah okay um so yeah yeah i i like the way i often describe it is I like to just be able to just reason from first principles. And I guess I don't know. I'm not totally sure when that really became my style of how I like to think about things. But it may have been some of, you know, just learning functional programming

because functional programming is very like, you sort of, you pick a set, like when you design like a functional library, it's like you pick a very, very small set of primitives and then you kind of reason. like when you're doing library design, you sort of reason about like, okay, if, if these were the primitives, then just logically like what would be expressible using these primitives? And you know, like is,

does that give me everything that I need or do I want something else? So, so like, you know, like, is, does that give me everything that I need or do I want something else? So, so like, so yeah, maybe just getting used to that, that way of, of thinking about things. Um, something that I just like really like about reasoning from first principles is like, there's something, um, you get like a kind of certainty about the conclusions that you reach that, um, you just feel like you understand it so much better. Um, in the sense that like, if say you're like, you're working on some problem and you're like, you're not sure what the answer is. And so you, you go and you, you go at, you know, talk to your friend and you say, Hey, I'm, I'm working on this problem. You know, what do you think? And you, and you, your, your friend like

says, Oh, you know, you, you should do X, Y, Z. And, you know, maybe your friend is like an expert. And so like, you really like trust that, um, you know, that if they say to do X, Y, Z, like, okay, they're probably correct. But like that, you don't like have, but it's sort of like a black box, right? It's like, okay, they're telling you X, Y, Z. And like, maybe they've given you some reasons for it, but like they haven't, it's, it's not enough that you, like, fully believe it yourself. And sort of by the same token, like, if you, like, reason from first principles and come to some conclusion, then you can sort of be, like, so confident in that conclusion. At least, you know, or you know what that conclusion really depends on.

It depends on what were the original assumptions that you may made. And then what was like the, you know, sort of chain of logical reasoning that you use to, to get to your conclusions. And it's like, you sort of know what your knowledge is, rests upon. And like, that's like a feeling if you have to make any kind of decision. Whereas if you don't really know what your knowledge rests upon, if it's vague, if you just have advice that... And maybe the advice was coming from a different place, or maybe

it was actually based on different assumptions. You sort of like, don't really know quite how applicable it is to your exact situation. And it's sort of like, you're not quite sure what to do with it. Whereas like, yeah, the reasoning for first principles, you sort of like always kind of know like where you stand. And, um i i guess i kind of i like that and and i i think it's like surprisingly like productive in the sense of like you can get very far reasoning from first principles like you don't like in some ways it's like a better guide to understanding a problem or a domain than sort of a more undirected just like okay i'm gonna like read everything there is to know about this field and um you know and then hopefully i'll i'll know what to do

it's more so so like in fact like the way that i like read you know papers and then hopefully I'll, I'll know what to do. It's more so, so like, in fact, like the way that I like read, you know, papers and things like that and, and like do, do research is like, I kind of actually, I don't know, maybe some people would say I like do it backwards. It's like, I actually like, I, I just think about the problem, whatever the problem is. Uh, I mean, if I happen to know about, you know, existing techniques or research, like I would incorporate that into my thinking, but, but I don't really like try to do a whole bunch of like literature review or anything like that. I just like, think about the problem, reason from first principles. And then like, I just,

just doing that, like, I feel like i understand the problem space like pretty well and then at that point like i might like go out and like uh go do some research where it's like it's sort of more clear to me what the problem space is and like what some of the likely solutions are going to look like and then when i like read a paper um i can just sort of fit fit that paper in i can be like oh okay well yeah they're exploring like this this part of the solution space and like you know i can see how they they got to that point and like it's like i have more of a more of a compass or or like way of exploring the space that's not just like totally random and just you know reading a bunch of stuff and and not quite knowing like what i'm looking for totally

that makes sense so yeah and yeah there's definitely like a lot of that with just yeah even like working on unison it'd be like i'd be working on some aspect of it and and and then i realized like okay okay now that i understand kind of you know what i'm looking for it's like okay i'm gonna go read uh you know some some type theory papers in this particular area to like understand this better and and you know because whereas if like if i just started out and and read you know i mean there's like this massive literature of like people studying different kinds of type systems and and writing about them and you could just spend like years just reading about that and so yeah it helps i don't know You can be a lot more guided and structured in how you explore the space, I guess.

That's really good advice, especially for someone like me who's trying to be systematic about building programming languages. And sometimes I think I go on either side of it. Sometimes I'm building too much and I haven't thought deeply enough about what I'm building, and sometimes I spend a lot of time with my head in the clouds reading papers. So I think maybe there's a place in the middle where I think about from first principles the problem I'm trying to solve and then read papers and build to kind of more holistically front from that. Yeah.

So something related to that kind of uh mode of operating is like it's it actually i think it actually takes time to it takes time and experience to develop reasoning principles like when uh like i feel like when i when i first started out um programming um i mean i had like basically you know when i like left college and i would you know was doing some programming and i basically had like no idea what i was doing really and and like um like i didn't have sort of the reasoning principles that would let me mentally like explore uh like the consequences of making different decisions with software like with fidelity like i like and and it's like if you asked me to like evaluate like design a versus design b it was like i would have been like well i

don't know you know yeah let's just try building it um and then it would only become more clear later like kind of what the implications are but and it's sort of like only like over time and especially like learning functional programming where functional design is like all about that of just like being able to reason about the implications of different choices and and so it's like that's like that those the discovery of those reasoning principles and like mental uh just fluency with like uh doing that reasoning is like that in and of itself is just like this huge lever i feel um it's it just like lets you iterate in your in your brain on on different choices uh more more quickly and you you often like don't have to write the code because you just like you basically know

what the what the outcome the outcome of writing the code based on a certain way of approaching the problem is going to be. And I think that's a pretty good way to articulate the difference between a beginner programmer and an advanced programmer. And part of what I think we're both trying to accomplish with our research in this field is making it easier, creating better tools of thought for people for beginner programmers to like be able to think the thoughts that wouldn't have been thinkable for them for like until they

practice programming for like a decade but the tools are so expressive and powerful and like abstract that they can like think those thoughts with the help and like with the companionship of the machine that exactly yeah yeah it's like it's kind of messed up that you know the machine basically the computer basically provides no help at all in in uh and it actually slows you down that's what you're saying yeah it's like better to think in your head you can go faster in your head than like with the help of the computer the computer actively works against you today as opposed to like helping you yeah and right so it's like right the the i mean you can like of course you can write the code and then you can run the code but that takes a long time um and so yeah so there's just like a lot yeah a lot we

could do to have uh have it be more of like a dialogue between uh you know the computer and you so that you're not just like you don't have to become this expert um to to be able to sort of see what the implications are okay actually i saw this um i read this article it was a long time ago, which was talking about just in general, like how technology. So they were talking about sort of like microphone, like the invention of like the microphone and and, you know, speakers. Right. And before, before those things existed, like if you wanted to be a singer, you had to go through this like very extensive training of like, you know, like to be an opera singer where you have to be able to project your voice in this very specific way. And there's a lot of work to it. And, you know, you know, on the one hand, that's okay.

Like, you know, opera, I mean, I'm not really into opera, but, but, but yeah, I mean, you know, you know, on the one hand, that's OK. Like, you know, I mean, I'm not really into opera, but but yeah, I mean, you know, there's there's like really amazing things that that, you know, a well-trained singer can do. And that's that's great. But it's also this big barrier that sort of leaves out, you know, the rest of the population that isn't able to go through all that training. And, and then it's, and it's like every, every piece of technology is kind of like that. It's like, even, you know, like the invention of the word processor, where you can like cut and paste text and move it around very easily. Like, okay, well now if you want to write something,

you don't need to like keep track of everything in your head and be just like one of these people who like can like write down like fully formed coherent thoughts like sort of in this very linear fashion and of course like people were doing right lots of writing before word processors exist but they had to develop like this this totally different set of skills of like being able to keep track of more things in their head and and think about um you how to, how to like do everything before working with like whatever the physical artifact was for producing text. And so it's like, I think it's a really great analogy. I like hadn't thought about that until recently. I was thinking like I was going

to, I was going to, I was writing a to-do list out on a piece of paper and I realized that I like ordered some to-dos incorrectly and I wanted to make a list of the tasks, like a subtask of another task. And I was like, I guess I draw arrows now. Like I didn't realize how powerful even that simple feature of a copy and paste was. Yeah, right, right. It's like, you don't even think about it anymore.

But just the fact that that exists is like, yeah, you have less, you have to be, you don't have to be as like clear-headed about what you're doing when you first start and the computer doesn't get in the way. And yeah, I think it's, it's the same with like building, building software. Like, you know, right now you have to master this crazy set of like arcane skills to like build you know uh software today and you know you have to be able to like yeah do all this thinking in your head and it's you know takes a long time and um yeah i don't want to make it sound like it's gonna be trivial in the future but but yeah there's like so

many barriers that we could like remove that would make things so much easier and make the computer more of a guide. Let's do it, I'm pumped. This has got me excited. Cool. Well, anyways, I wanna be mindful of your time. Thank you so much for taking the time to talk to me. This was a really fun conversation. Cool.

Yeah, I really enjoyed it. Yeah, thanks. Awesome, yeah. Before we wrap up up i wanted to give you a chance to uh expose the paul api to the world so like what are the the ways people can interface with you is it on twitter email blogging like where what's your interface what are you looking for you're looking for open source contributors uh people to read your blog, what's your API? Ah, okay. Yeah, I mean, so I'm on Twitter.

It's P. Chisano, like first initial, last name. There's unisonweb.org is the Unison site, which has a bunch of links to other stuff. Yeah, the Unison site is, yeah, I mentioned it was it was more of a research blog and it's it's there's a bunch of stuff that's like out of date or you know i don't know so i think uh we're we're working uh so i'm working with uh uh one of the other open source contributors we're working on the new uh unison runtime and so there's like a bunch of stuff that's happening. I'd say any big updates would be on

the Unison blog. Yeah, I don't know. Just, I guess, stay tuned, I guess. Wonderful. Great. Well, thanks so much, Paul, and I'll talk to you soon. Okay. Thanks, Steve. Bye.