Future of Coding - Stop Being A Sysadmin For Your Own Machine: Nick Santos

Episode Date: May 22, 2018

Do you hate Makefiles and YAML config files? Do you feel your soul slowly dying as you wait for your tests to run? Do you yearn for even-more-continuous integration? Nick Santos, the CTO and founder of Windmill Engineering, is here to help. Windmill's a cloud-based build-system that intelligently runs your relevant tests in the cloud, in parallel on every file save. How's that for a tight feedback loop? futureofcoding.org/episodes/24Support 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, surprise! I have three episodes for you this month. As you can see, this is number three. I hope this makes up for missing March and April. I think I can stick to this one episode per month thing from now on, but occasionally I'll have to make up for missing months with more episodes in other months. So this interview with Nick Santos actually came about because I bumped into him at a party at my friend Kyle's house. Thanks, Kyle. And usually the conversations I have with people at parties when we talk about work is pretty sparse. They say, what do you do? And I say, I work on developer tools and

programming languages. And that's where the conversation ends. But this time, when I said that, Nick said, Oh, me too. And we were both kind of shocked to meet someone else at a party pretty, pretty randomly. You know, I will say, to be fair, that this is a party thrown by a computer science engineer, and many of the people who are at the party also studied computer science with him or worked with him at other companies. So we all are engineers, but still within engineering, DevTools is a pretty small niche. By way of introduction, Nick Santos studied computer science and math at Dartmouth College. He was a staff software engineer at Google, where he worked on consumer projects like Google Docs.

And he was also a software engineer at Medium, where he worked on the editor experience. And now he's the CTO of Windmill Engineering, a dev tools company that brings a live editing experience to your build process. Please enjoy. I'm here with Nick from Windmill Engineering. We're here today in New York City at Workbench, which is a venture capital firm and also a co-working space. Welcome, Nick.

Hi, Steve. So I guess to start with, I wanna talk about why you started this company, like what brought you to it, and yeah, the background, what you guys do. Okay. How best to approach this? So Woodmill is a dev tools company.

We believe that engineers spend too much time waiting for dev tools. How I got into dev tools, I'm not from a dev tools background much. Most of my career has been on consumer work tools. I worked on Google Spreadsheets for a long time. I worked on Forms. After that, I worked at Medium working on their editing tools and their writing tools. One of the common themes of all of that was that JavaScript tooling was really terrible, that just working with a large team and a large code base in JavaScript was always a pain.

So we ended up writing a lot of our own tooling. I ended up working a lot on a tool called Closure Compiler at Google, which was a JavaScript type checker. And through Clojure compiler, I ended up meeting my co-founder at WinMill, who also worked a lot at DevTools at Google. And one of the things that we talked a lot about is how the DevTools experience today is kind of sad and requires you to keep a lot of state in your head about how the tool works. The classic example being Git has all this complicated state about where you are in the

rebase and where you are in a branch. And we really wanted dev tools that were a little bit more visual and a little bit more like Google Docs or Google Spreadsheets where you can just play on a web page and start typing, and it starts giving you feedback immediately. And that's kind of how we got here. Cool. Yeah, that makes sense, how you were inspired by the consumer work and the developer work together. You wanted the developer experience to be similar to the consumer experience.

I think a lot of us are motivated by that sort of vision. I'd be curious to hear more about your experience on Google Closure and how it relates to what you're doing now. Oh, boy. Closure Compiler is an interesting project in the sense that it grew very much out of what we needed at the time, that it became way bigger of a project than we expected. It was very much, hey, we have this team of, you know,

dozens of engineers working on this JavaScript code base. They're constantly making mistakes, constantly passing the wrong arguments, and mistakes that like, hey, some team is developing a sharing library and another team is using that sharing library and the team that's using that sharing library is passing the wrong argument in and they're in an argument about, okay, whose fault is this? They're in an argument about arguments?

Yeah, exactly. And so Clojure and product started out as, okay, let's just push everyone to start writing their types in comments. And then after the fact, we're going to rigorously write a type checker for the types in the comments. And that way, people can start writing their types now. And we will gradually, over time, be able to check them better and better. Got it. So it sounds similar to TypeScript and that kind of movement. Yes.

We started Closure Compiler in 2006-ish. We started the type check of Closure Compiler in 2006 or 2007-ish when everyone thought that ES4 would be a thing. I don't know if you know the history of ES4. No. ES4 was this proposal for JavaScript to add pipe checking to JavaScript to the main language. Wow.

That was really exciting, but just never got released. Huh. That's fascinating. I never heard about that. There is a spec. I'm sure you can find a PDF somewhere. It was very ambitious. Maybe someday there will be real types in JavaScript. Closure Compile was very much the seat of the pants. We're taking the spec. We got a

spec. Let's start implementing it now. Maybe a score will happen. Cool. I get it. TypeScript had the benefit of being more well designed up front. Or Flow, Facebook's project, Flow.js. I don't want to say that, yeah, Closure Compiler was certainly not as well engineered as either of those projects. Let's talk more, I want to get a better understanding of what you're working on. So what is, yeah, what is, what problem does WinML solve and how does it try and solve it? So we believe that developers spend too much time just searching in the dark to try to figure out if the change they just made broke anything. That you've made a change, you don't

know if it's going to work or not, and you have to figure that out. What Windmill does is you describe your build pipeline, and you try to describe it in as small units as possible, and we try to figure out what you should be running next for your next 10 seconds of development. The next 10 seconds of development. So when I first heard about this, I thought it sounded very similar to continuous

integration testing in the cloud, but instead of increments of every commit, it's every control-S save. Right, exactly. Yeah, every time you save, we try to say, we're going to upload your change to the cloud and try to figure out, okay, based on what you just changed,

what should you be running? Yeah, there's kind of a branding problem in the sense that continuous integration is taken and it's actually continuous. It's more continuous than continuous integration. So what are you gonna call it? Live integration, maybe. Live integration is a cool one

because it kind of evokes the kind of live reload workflow that we really wanna evoke, that we really admire. Yeah, that makes sense. It feels also very Google Docs-y, that you're patching changes very live. You still wait for save. You don't do it as a- We still wait for save, yes. You don't wait for the, not just on keystrokes.

Yes. That makes sense. We could. You could. We've talked about, there's got to be a. That makes sense. We could. You could? We've talked about it. There's got to be a way to do it. Maybe someday. So one obvious advantage of using a cloud-based built system on every save is that it can definitely speed things up.

You can paralyze things. And you mentioned that you could also order things smarter. How does that work? So right now we look at the file that you just edited and we try to figure out, first of all, what does that affect? Which sometimes depends on language. It's a very basic analysis. And what is the likelihood that based on what you just edited that something will break? And try to figure out, I mean, this is kind of, I hate to say machine learning because I think machine learning is so

overblown right now, but like machine learning has this great concept of information gain. That like, what is the amount of information I expect to get from this action? And figuring out, okay, what's, what is the thing that can get me the most information now? And trying to figure out, and then running math. So you're figuring out which tests to run? Yes. And so how are you connecting a test to a file? So right now, we look at just basic dependency information is the first thing when we have it.

So like a test will depend on a file. You'll see that it calls methods that are in a file? Right. Or like for Go, for example, Go has a tool called GoList, which lets you say, what does this test depend on? We can figure out the depends on this file. There is a statistical approach, which is just saying, hey, if you're editing this file and we're seeing every edit,

we have this stream of data. And we can say, hey, we can see that you've made a bunch of changes to this file, but it's never broken this test. We can be pretty confident it doesn't break that test. And there's some statistical kind of fuzz factor you can add in there to make sure that it still runs at some time and just double checks. But over time, we can build confidence of whether it changes this file or changes this test. Got it. Yeah. So you're bringing machine

learning to the build process and testing. I would say we are, yeah. I would also, but I would clarify this, 80s machine learning, not deep learning. Got it. Cool. That's good.

I like your insistence on anti-bubble and anti-hype. Like, this is simple technology that's going to make things better. This is, I'm not trying to promise something that I can't deliver. There's no Alexa, what is it, Samantha from that movie. Yeah, I'm not going to be like a human intelligent person. It's just very basic. Yeah, we think this is a basic statistical tool that we can use to kind of take it to the side.

Got it. So you're running this whole company to make the feedback loop tighter for developers. Why is the feedback loop so important to you or developers? I mean, I think you're a Brett Victor nerd. I am not so much of a Brett Victor nerd. But I definitely believe that in all of things, not just in programming, that just feedback makes people better, that feedback is made to be better,

and that it is important that feedback be instant. For, yeah, for anything. Yeah, like one, and you're definitely right, I'm a Brett Victor nerd, and this is his thing, and so I'm all about it. One, just to hold the other side of the argument, I saw a study that showed that if you have a GUI-based interface, or this is like an analogy,

if you have a GUI-based interface or a keyboard-based interface, even if the GUI-based interface is faster to accomplish a task and you can time the tasks, people will say that the keyboard interface feels faster, even though it's like empirically slower because it just feels more fluid than moving. But you don't, because you don't notice the time it takes to like do multiple keystrokes, but you notice the time it takes to move your mouse and just feels clunkier.

And so sometimes I wonder when I'm frustrated, when things take time to build or run tests, I wonder, is this frustration worthy? I am frustrated, and that's a problem we could fix, but is it actually slowing me down, or does it feel slow? Is it a perceived problem or a real problem? Yes. Yes, that is an important distinction.

The perceived latency versus real latency. I'm not sure. I have to think about that, I think. Okay. I think we believe to some extent that there is a value in having the feedback be automatic. And being able to say, hey, the feedback is automatic and we're pushing the data towards you before you need it.

Or before you think to ask for it. for. So I think I would make the distinction between the GUI versus the command line interface, which I think is a separate access than the interface of is the feedback automatic or do you have to ask for it? Can it push versus pull? Interesting. Okay. Yeah, I could see that distinction. So it sounds like you're working on both sets of problems. You're making the feedback push and you're making the feedback easier to get. Yes. I think Windmill has a lot of interesting problems

and kind of distributed build system space, but we also believe that there's a very difficult UI problem. That is, hey, we're pushing five tests running in parallel at you, and that can clearly be overwhelming. Or, you know, 100 tests running in parallel at you. We don't want to do that. We don't want to be Clippy for testing. Oh, interesting. Yes, I'm glad you brought up Clippy. There are a lot of developers you were talking about. I've talked to a lot of people who

are working in this space who call what they do Clippy for developers. Oh, yeah. I hate that. Yeah, why do you hate that? To me, Clippy is the example of pushing data that's not relevant and not useful, and pushing it, being too aggressive.

And to me, there's very much a UI problem of trying to figure out, based on what the user is doing right now, what they want. And I don't know that we have an answer for it yet. I mean, the closest example I can give is maybe the medium text editor. There is no bold tool on the screen.

There's no bold button on the screen until you select something. And then the bold button appears. We thought a lot about how that interaction should work and how that should surface. Oh, I see. That's an example of a solution to a UI problem. Yes.

Then we try to make sure that the tool, that if the tool is on the screen at all times, that is a UI failure. That really, we need to kind of watch your actions and try to figure out when you need the tool. That's fascinating. Just to see if you need the tool. I never thought about that in Medium, that there's no bold button. But it's there when I want it.

But it is, yeah, perfect. Yeah, I wonder if other Word document editors are gonna adopt that UI. There's some, I think, that do, but yeah. Fascinating. So there were a few words that I read in some of your initial blog posts that I want to dig into. One of the words is reactive, that you're building a reactive system for build tools. Another is the difference between imperative and declarative build system languages.

So you take a pick which one you want to address first. I'm curious how you define reactive, since reactive is a big buzzword now. I think it's a buzzword that I'm very excited about, to be clear. I think I just stole the word from your blog post. Oh, okay. Good, good, good. You can read the blog post then. Reactive to me just means I update one thing

and the thing that depends on it updates without me having to tell it to update. And there's kind of various definitions of what that means. Dependencies managed automatically. Yeah, it just kind of rebuilds without being told to do so. Rebuilds without being told to do so, okay. And just having that automatic, I mean, that is to me is like the React JS kind of definition of it. You update a model, the view changes.

This seems to be where these tools should go. And so how do you architect a reactive build system? That's a good, that's a very broad question. I think it's... I'm not sure I even know how to answer that in a pithy way. Okay. Maybe I'm misunderstanding what you guys are doing. You're not doing something...

No, we are building a reactive build system, but I'm not sure if I can summarize how you build one. There's definitely the... So there's a couple of schools of thought here. How much do you know about Bazel? Bazel. I think you...

I read your blog post on it. Yes. So Bazel is Google's build system. For Go? Or just for everything? For everything. Oh, Google builds in a huge repo. All the code is in one repo.

And everyone uses the same build system. And that build system is Bazel. Modulo some letters that change. And the idea is that you describe a build graph. Yeah. And that build graph exists in very much an abstract way. And they are literally modeling this build graph. And then they follow the DAG.

They follow the DAG? They follow the DAG. The DAG, yes. The direct exit graph. Yes. We think that might be the way to graph. Yes. We think that might be the way to build build systems. We are not convinced it is the way

to build build systems. One of the things that Windmill is experimenting with is this is going to be a little bit bananas crazy right now, but maybe you don't have to have the whole DAG in memory. maybe you don't have to have the whole DAG in memory. Maybe you don't have to have the whole build graph in memory.

Maybe you can explore that you start with a point and you say, okay, maybe I have two inputs. What if I assume, just for the sake of argument, that one of these inputs is okay? And just rebuild the other one. Or maybe the better way I would put this is that not only do you not have the whole build graph in memory, but one of the great insights in computer science that we keep rediscovering over and over again is branch prediction.

That is, you're giving me a puzzled look. Yeah, what's branch prediction? Branch prediction is when the hardware guesses what the output of this if statement will be. And starts executing on the assumption that it is true or on the assumption that it is false. The hardware makes the prediction. Yes. Based on... You would have to talk

to a more hard... It sometimes records. It records the history. So similar to statistical machine learning-y type things? Not that sophisticated. I mean, this is a great insight type things? Not, yeah. Not that sophisticated? Not that sophisticated. I mean, this is the great insight of the Java VM, too, right? That, hey, the Java VM, if you do, like, an if statement check, right,

or if you do, like, a virtual method call, it will say, hey, I'm pretty sure I know what this is. I'm going to jump assuming that it probably is what I think it is, and then I can rewind if I have to. Interesting. So like if you run a loop a thousand times and every time the if check statement is false, it like, it kind of, it'll just, it'll, yeah. Right, if you know the loop is going to run a thousand times, you don't really have to do the if check. You can just keep running the loop and then, oh, you went too many times, let's back up. I think buildisms could benefit a lot from this kind of thing in the sense of like, hey, 90% of the time you're running a test against the database, you don't actually need

to restart the database. Interesting. Does this make sense? Yeah. So you can just say, I'm just going to leave the database up, and I'm going to run the test again. And in parallel, I'm going to restart the database and run the test. And maybe I was wrong when I left the database up. Maybe the database really does need to restart from scratch to make the test work. But now I can get faster feedback by just assuming everything's OK. Interesting. Yeah.

So yeah, you're using compilation techniques that normally were used for hardware compilation of code, but kind of more in the cloud. You're using similar ideas, but different, like, compile target? Yeah. The idea is, I mean, I guess this is an idea from bytecode execution of, hey, could we just treat a build system as any other interpreter and do all the kind of cool techniques that we think of in any other interpreter to kind of speed things up? Certainly for correctness, there's a big difference to me between what you're willing to do for correctness versus what you're willing to do for fast feedback.

And those can actually be separate pipelines. Oh, interesting. I kind of want to dig into that. Yeah, so why are those distinct? Correctness versus feedback. Because you can cheat. If you're not worried about correctness Because you can cheat. If you're not worried about correctness, you can cheat, right? Isn't correctness important for feedback?

That's a good question. I think it's more of like, hey, we can get you feedback quicker, and we will eventually get you the correct feedback. And maybe we can communicate you two in some way, that hey, this is what we think is going to happen. Like we think this error is going to happen. And in a lot of cases it will be like, hey, this is going to fail.

We're pretty sure this is going to fail. Or we ran compile first without rebuilding the dependencies because we think that's the smart thing to do right now. Got it. So you're giving really fast feedback, but it's not 100% sure correct. And then if I wait a little bit, then I'll get the correctness guarantee.

Or you could just look at the error message and see. Maybe a classic example. Do you program in Go at all? No, I've never programmed in Go. Do you ever use protocol buffers? No. Or Thrift? I'm sure listeners have.

Anyway, suppose you have some JavaScript code, or JavaScript or whatever. But you depend on some generated code. So maybe your grunt build system rebuilds the generated code each time, or does the transpilation each time, because that's what it has to do for calculus. But actually, you don't need to do that. Most of the time, the transpilation will succeed.

And most of the time, it will just count the same results. Yep. Okay. Oh, I see. So you don't need to do that step. Right. And if you see an error message related to, say, the generated toad, okay, you're like,

oh, yeah, it's still regenerating that part of it. And so that's why those error messages are showing up. Yeah, I think, like I said, this is the crazy banana pants kind of build system that we're not even really doing yet, but we are excited about if you have a cloud-based build system, there's a lot of cool things to explore. Yeah. I'm getting excited about the idea of sharing things between colleagues somehow. If it can detect that you're building the same sorts of files as colleagues, it can just share the results from a task? Yes.

Yes, that is another big one. What's another exciting example? Yeah, the sharing results is a good one. The sharing... To me, there's also the sharing... Sharing artifacts, which is the way I would describe it, but also sharing results. That is, hey, if I build something and it failed, but I don't understand why,

I can send that link to a coworker. And the coworker can say, oh, yes, I can look at, because all of this exists in the cloud, I can look at the error message. I can look at exactly what's in your code base and not have to do the dance of, oh, I'm going to shove my failing branch up to GitHub and then copy a bunch of paste and such and stuff.

Yeah, that's a really good point. I was just, when you showed me the demo recently, just to describe what I saw to everyone who didn't get to see it, every time you hit save, it runs all your check. It creates a new URL for you that has all the tests that were run and all the error messages. So there's no copying and pasting error messages. You just copy and paste the build link.

I guess it's similar to when you, like, submit – when you push a commit to Circle or whatever you have in the cloud, you should just send that link to someone. It's that, but for every save. So there's no need to commit. There's no need to worry about Git in order to share links. Right. We can just do it automatically for you.

And yes, the best part about doing it on every save is you can say, like, oh, I broke this. When was the last time it succeeded? Like, has it been broken for a while? And I'm excited about a lot of those possibilities rather than having to explicitly create checkpoints. It's more of the, I mean. Fascinating.

Have you used Glitch? Yes. So Glitch has this live mode that I'm actually super excited about, where you can kind of rewind back to a project and see the rerun state. Yeah, I think this is, oh, yeah, that's exactly. Like Google Docs, like the rerun state. I think this is, oh yeah, that's exactly. Like Google Docs, like the rerun. And you guys can do that too, given that you have every save.

Yes. I guess you can't do keystroke by keystroke rewind. We can't do keystroke by keystroke. Yeah, we can do save by save rewind. Cool. I guess on the downsides of running the cloud, I did some research into Kite, which a lot of people are familiar with. It's similar in that they store the user's code

in the cloud. And I saw on Hacker News and just in a lot of places, there was a lot of backlash against Kite. Well, for other reasons too, but I think there was a lot of negative response for like, ah, I don't want my code in the cloud. Like that's insecure. What are your thoughts on like the downsides of coding the cloud? How to overcome those? This was the hacker news. So this is something we hear a lot, that there are definitely some companies who don't want to store their code in cloud. We think that is not the way the world is going.

Do you have an on-prem solution? We are a very early startup. If someone comes to us tomorrow and says, we will throw money at you to give us an on-prem solution, we will figure it out. You'll do that too. Okay, I got it. Yeah, so you can do it either way. But you think everything's moving to the cloud, GitHub's in the cloud.

It's like a myopic view. Yeah. I mean, I'm actually super interested in the on-prem space and how that space seems to be evolving as, you know, when I worked on Docs, Docs had some interesting, we call them geolocation problems of people who want their data to be restricted to a certain geographic region, right?

Somebody who only wants their data to be in a certain data center, or someone who doesn't want their data to be in a certain country. We won't describe specific countries involved in this. And this would be like a company, like a Fortune 500 company would say, we don't want our data in Turkey, whatever. I'm just making up a country.

And you'd be like, okay, we'll add you to the list of, and they're a paying customer? Or could I contact Google and say, I I don't want to get it stored in California? I think if you were enterprise customer of like Google Apps, you can set restrictions. Oh, interesting. I don't know how it works now, but it's interesting to me, there's definitely, there are definitely some people who believe that on-prem will be a thing for the foreseeable future. And what will end up happening is that you will have these virtual private clouds. And any software as a service will just say, great, I'm on Kubernetes. I can deploy to your cloud if you want me to.

Yeah, I see. The interface will be the same. And it'll be seamless whether or not it's your cloud or their cloud. It's seamless either way. Yes. I'm super interested in that vision. If that vision of the world comes to fruition, I think that will be... I will be surprised by it, but it will still be super interesting.

Yeah. Yeah, fascinating. Because at the end of the day, it'll still be on Amazon's cloud, probably. But I guess if you want to buy a computer, you can buy computers. Yeah. There's also the other interesting question is if you have a couple of clouds, what would be like Coke and Pepsi? If there's two clouds, or if it just ends up just random real estate company is getting

into coasting clouds. It's not a space I'm a lot involved in, but I just, I like hearing about it and gossiping about it. Cool. So I find it fascinating that you're in the build tool space, particularly just randomly. I had a recent experience working, doing some contracting work for a company

and I got like up to speed with their build tool system. And it was just a frustrating, frustrating, like, six hours, like, learning their commands. Things wouldn't compile. It was just, like, the thing that watched files wouldn't work. It was just, like, a whole nightmare. So I'm, like, really excited to find someone who's, like, trying to make this experience better.

Another thing to mention is I think that I particularly don't like build tools more than other engineers. I run this project for kids. I make this online programming language called Woof, and it has logins and stuff. It's like a website, like a normal app. But I refuse to have a build tool. It's like just HTML, CSS, and JavaScript files on GitHub pages. And then there's Firebase.

I hate build tools that much. And a few times it's bitten me, not being able to import files and stuff like that. So I've tried to add build tools. And every time I get an hour or two in, I'm like, I hate this. This is the worst. And I just stop. So I thought he'd be a good person to explore my hatred and terrible experiences

with build tools with. This is super interesting. Can I ask you to a little bit explain more? Have you used a JavaScript linter? Or a CSS linter? Yeah, yeah, I have. Linters are fine.

I don't have a bad experience, especially when they're integrated with the text editor and they show up in the gutter. I have no problem with that. Yeah, so let's dig into that. So you're not opposed to build tools then? You do use a linter. Yeah, yeah, that's true. That's true.

Okay, so what do you not like about the build tool thing you dislike? Build tools, usually there's, like, a lot of frustration involved. Installing the build tool is, like, a headache for everyone involved. So that's, like like one big pain point. That could take hours. And then configuring the build tool isn't a one-time cost. Like once it happens, like they're immediately, like they're like constantly problems and you have to like reconfigure it.

So that's like another series of problems. And then I think there's like a set of abstraction choices that the creator of the build tool makes that don't always make sense to me. And so understanding their way of thinking. Yeah. Do you get a sense of why I'm so allergic to them? Yes. Yes.

Because the app itself is a tool that people use to learn to code, I have a lot of newbies who want to make it better. And I think it's a good project for that. And in order to, there's one piece of the code that needs to be compiled by Babel. And so that's the one thing that needs to be installed and run. And I made that compromise.

And even that causes a whole headache, just running this one val command. Yes. So anyways, I'll let you. I totally agree with that. To me, there's so much about using build tools that is being a sysadmin for your own machine. Yes.

Every time we onboard someone on the windmill, we have to go through the whole Python 2 versus Python 3 dance. And there are just some things on that machine that are Python 2 and some things that are Python 3. And everyone wants to manage it with PYN for whatever the newfangled thing is. I don't want to do that anymore. I don't want to business this man. But that's not why I came into this industry. So how are we, how, like, sometimes it feels like this is an unsolvable problem. Like, you know, you're combining a lot of different languages and they're changing dependencies.

Like build tools kind of like fill in the gaps of where languages kind of leave off or connect to each other. Yeah. Can we ever fix? So the problem exactly is that you're running build tools on your own machine. That's the first problem. And because the build tools all have to live on your own machine, they all have to coexist on your own machine

in a way that once we start running build tools in the cloud, which is what I'm most passionate about, is like, oh, right, you can run the Go compiler in one container and the Babelgen compiler in a different container. And they don't actually have to live on the same solution. Yeah, so that sounds like a dream. But now I'm wondering, I actually

want to see the result. Running the tests in the cloud, that's fine. But what about I want to interact with my whatever code I wrote. I want to, like, you know, like, have a repli experience. Are you, like, sending back, like, how am I interacting with my code? You know, like, just because the tests are in the cloud, does that mean I don't have to build anything on my machine ever? Is that the world you're building towards? Yes. Interesting? Yes.

Interesting. Yes. Okay. I pretty strongly feel that we are moving towards a future where the code will not live on your machine. And there's a question of, to me, the big question is not if that future is, but it's like, what is the path towards that future? Okay. Because, yeah, definitely in the near term, that's not going to happen.

Like, we're not, you know. Right now, you're just running tests. You're not, like, running a REPL kind of thing, you know. You see the, like, because still, even with Windmill, like, the Windmill that might exist a year from now, I'll still have to also run, I'll have to set up all the build tool stuff on my own machine, too,

because I, like I need to interact with it on my machine. Yes. I think one year vision, you also have to build on your machine. Five year vision, maybe you ask Windmill for the artifacts. Artifacts aren't quite compiled code or more of a... Could be. Could be.

You ask Windmill for what you need to run the binary on your machine. I don't know what the path looks like. Honestly, I'll be totally clear with you. I think we're trying to figure out at this point what are the baby steps towards that reality. And we think

tests are a pretty good start. Yeah, we may be wrong. Maybe there's another... It's going to be another path. Got it. Okay. But I'm glad that you are moving towards this world where, yeah, you don't have to be a sysadmin. You don't have to understand, yeah,

I guess it's the sysadmin world in order to be a programmer. Yeah. Yeah, Heroku, I guess. Like all the DevOps as a service companies helped move us in that direction. And this is probably one of the last remaining vestiges of programmers are also sysadmins. Yeah.

I mean, I've definitely talked to people who believe the future of web IDs. I've talked to people that say, no, the future is you're going to keep a persistent VM in the cloud and just put SSH into it all the time. So that's what I do. Really? You do this? Oh, you're one of the few specials. Cloud9 plus, like, Cloud9 provides, like, an SSH, like, box for me.

But, like, sometimes if I want to, like, run Docker, I can't. They run Docker, so I can't run Docker inside Docker. So, like, I need to, like, they run Docker, so I can't run Docker inside Docker. So I need to find my own box. But it's terrible. Like installing. I still have to be a sysadmin. Interesting. So you still have to do a bunch of install commands to get the NPM into a good state.

Yeah, totally. Because you want to install NPM. You want a different version of Node. And then, yeah, it's like a whole mess. Yeah, yeah, yeah. I mean, one of the bets we're making is that you will run around some part of your build process in one container and some part of your build process

in a differently configured container, and that a lot of the system and stuff is just making the tools coexist. I'm not sure if that's the right frame, but I don't know. I'm excited for the future. Let's see what mistakes we make tomorrow. I'm curious what you think the

upper limit on how good we can make, or I guess a lower bound on how bad build tools have to be. How good can it go? Where is the inherent versus incidental complexity in this space? Yeah, what's utopia? I mean, there's different visions for utopia. There's the one vision of utopia, which is that programming languages of the future look very

different than programming languages of today. There's another vision of you have a server and you make a code change and you reload that server and just everything's been recompiled and it's a new server up. A new... So I reload the server? That is, you recompile the complete... You totally recompile the server and bring up a new one every time you... Every time you continue to save. In the same way that JavaScript development works today.

Or live reload JavaScript, not all JavaScript development, but live reload JavaScript development works today. And that's one possible vision. I'm not sure, I don't necessarily have the answers. So your vision of the future is more like, programming looks like the language we have today, but the build tools feel like hot reload React JavaScript development. Right. Yeah.

And will I still have to write a makefile-y type build system, or do you think one day we'll be able to get rid of makefiles? Oh, I dislike. Oh, we haven't talked at all about MIG files. I am frustrated with the current state of build tool configuration. File-y things? Like the NPM... What is it for NPM? The NPM JSON.

Package.JSON. I'm not a big fan of the CircleCI or the Travis YAML files. I'm not a big fan of makefiles. To me, the problem with all of those systems is they're, on the one hand, they're very declarative, which is nice in some ways. But declarative languages are kind of hard to debug and hard to visualize what's going on. And you end up having to do a lot of visualization in your head of what's going on and you have end up having to do a lot of visualization in your head of what's going on uh the windmill build language which is more just configuring what commands to run looks very imperative it looks uh more like just normal python you would

write on a rainy day. I don't know if I, we like that much better as an approach than rather than trying to like voodoo a declarative language into YAML, which I see a lot of people do. Yeah. I think, but I think there's entirely a possible ability like visual build languages, just like being able being able to see the graph and see the steps and say, hey, I want to rerun this step.

OK, yeah, yeah. And you're imagining nodes, like a DAG, like a DAG that you can add a node, wire it out. It could be a DAG. Some people have pushed back against this. There's also one UI paradigm I thought is just layers. You just say, you want to build this thing. Here are the layers that you could rebuild.

And rebuilding one layer builds all the layers of it. Got it. Sometimes I think YAML files approximate this. Like, just so, yeah? And so you just want to make it you know, just... Yeah. And so you just want to make it, like, just a better UI. Yeah. I think, yeah, I think YAMLs are basically not a good UI for this. Interesting.

I want to dig into the declarative, imperative, hard to reason about, hard to debug thing. Yeah, why do you think? So walk me through your reasoning on why declarative's harder to debug. Well, let me twist the question around then. Are there declarative languages that you like? Yeah, that is a good way to think about it. Because SQL, the canonical example of a declarative language, is a mess to debug. Debugging, more or less, is a very breakpointy thing. And imperative makes that very easy to do.

So yeah, you kind of have me there. Is that your argument? When you look at declarative languages and you think about the experiences you had, they're bad. So declarative languages are bad to debug. That's a reasonable argument. I think that is some of the argument. I mean, CSS is the other big one that people use.

And it just took us many, many years to come up with a good debugger for CSS. Yeah, I think they're just very difficult to approach, very difficult for new people to learn. I just know very few really great CSS engineers or really great SQL engineers. To make a declarative language successful, you need to be able to have the computer expand it into understandable steps that a human can read and process and make sense of. The classic example being the CSS debugger, where it gives you that stack of, hey, here are the rules that I applied in the order that I applied them. And here are the rules that override the other rules.

And even though you don't quite understand how it figured that out so fast, you can kind of see the steps. Yeah, yeah. It sounds similar to SQL, like, explain. see the steps. Yeah, yeah. It sounds similar to SQL explain. Yes. Yeah, yeah, yeah. Yeah.

Do you ever use SQL explain? Not in years. Maybe I use it once. I guess the point you're making is that it's, like, not a very good explanation. It's, like, not human readable. I've used SQL explain. It's okay.

I don't always understand why it's doing something or like why it's like, why did this step first instead of that step first? Interesting. And that's frustrating to me. To me, it sounds a little bit like declarative languages are trying to build this beautiful abstraction. So you don't have to care about the details, but you're saying that like the abstractions are always going to be leaky so you need you need someone to make the translation for you so you can like debug the leaks um because in theory we shouldn't have to care like it should just do the smart thing there should be no problems even if the even if the abstraction isn't leaky even if it's a perfect abstraction you will still need to understand when you use this abstraction problem.

And you think imperative is the way? Because I feel like there could be a declarative arrow just saying, oh, on this line, you declared the CSS to be this. But over here, you used important. It could declaratively explain to you the issue. It doesn't have to go like, well, first I did this, then I did, you know. That's interesting. Wait, let's talk about that for a second.

So you imagine like I click on a tree and I ask, why does this, why is this tree blue? And it traces me back through to like figure out why it's blue. Is that, is that your? I'm wondering if the explanation could also be declarative as opposed to an imperative explanation. And so I guess I'm begs the question, what is a declarative explanation? Yeah. I like that.

The declarative languages could work if you just had better ways to kind of interact with them and query the results. Yeah. Yeah, I guess, yeah. Again, I think you're going back to kind of interact with them and query the results. Yeah. Yeah. I guess, yeah. Again, I think you're going back to kind of the Brett Victor approach of just being able to click on something and see why is that?

What's the history of that thing? Yeah, yeah. Interesting. OK, so I want to talk more about the imperative language that you have. Is it truly imperative, or does it just seem imperative? Oh, it's truly imperative. So I'm wondering how do you do concurrently, how do you parallelize things if it's actually

imperative? How does it know what it can parallelize? Sure. So the language we use is called Skylark. It was built by Google for their build system. It is a subset of Python. We use it much differently than Google uses Skylark, whereas Google uses it to set up a build graph. We use it where you write a function, and that function takes as input your code base. Okay. And that code base is immutable.

And you can do things to that code base like, say, install a bunch of dependencies. And when you install a bunch of dependencies, you get a new code base, which is the dependencies overlaid on the old code base. Okay. And then you can pass around, okay, now I have my code base with dependencies. Now I can pass that to, say, go build job. Okay. I'm following.

Are there limitations that, like, because it's defined so imperatively, you can't make certain optimizations that a declarative build system would be able to make? That is a good question. We think no. There's this, when we've talked to people about this, one of the complaints is that one of the nice things about something like Bazel is that Bazel builds the build graph up front. That if you made a mistake, it will be able to tell you we have the entire build graph. Whereas with our imperative language,

it's stepping through a bunch of functions that may or may not schedule runs and or may set up jobs to run. And that we may not actually know that your build graph is wired up completely incorrectly until we get pretty far down the line. Oh, okay. Yeah, yeah. Yeah, that's a perfect example of why you want something that's more declarative. Right. The declarative can check up front that, like, hey, this dependency doesn't exist,

whereas we have to, like, go all the way down and then realize, oh, wait, we don't know what this is. Yeah, because you're evaluating the lines of code as you get to them, like a normal imperative language. Yes, exactly. Interesting. But I guess you think the benefits outweigh the costs. And so the benefits are the imperative languages

are easy to pick up, easier to debug. And is there another? Yeah, those are the big ones. Just much more approachable. Much more approachable. Cool. Yeah, maybe. Yeah, I'm curious.

I've never. I uniformly dislike build tools. They're also uniformly declarative. So I'm curious. Maybe I would not hate an imperative one. Maybe the whole time you just hated declarative tools. It's interesting. I like the idea of declarative languages.

It seems like a good idea. Were you also someone who thought declarative languages were a good idea and then you kind of reacted negatively to them? Yeah. Or you never liked them? I think that's exactly, yeah, I'm kind of a languages nerd. I wish declarative languages were better because they seem so cool when when you see in the abstract and then when you try to use them

you're just because they're like they're dense they're elegant they're you know mathematically kind of interesting yeah and then it's not fun in practice yeah i mean, yeah. Have you ever read, you've probably read worse is better, right? Yes. Yeah, I mean, I think that, it's functional languages I think have the same problem, I really, really want to like functional languages. But there's just so many ways to shoot yourself in the foot. Like code up an n factorial algorithm accidentally. Yeah, it's true. code up an n factorial algorithm accidentally.

Yeah. Yeah, it's true. I, you know, like, a language like Haskell is, like, my favorite language until you ask me to write some Haskell. Then it's like, never mind. Have you ever built anything in Haskell? Like, no. Nothing that's non-trivial.

I guess, sorry, the easier way to say that is I've only built trivial things at Haskell. Yeah. I really like building trivial things at Haskell. It's actually just a lot of fun. Yeah. It is. So, yeah. Yeah.

Tough stuff. Let's see. A few more. Maybe one or two more questions. So it sounds like you're going the for-profit company route for this project. Maybe walking through, like, have you raised money? What was your thinking

to go for-profit? Did you consider other routes? Oh. It's funny you put it that way. We definitely did, we spent a bunch of time, we were kind of very interested in this idea of live build tools and reactive build tools that kind of automatically built as you went and built in the cloud. And we thought about what would it be like to do this at a big company. And we just kind of decided this would not,

because it cannibalizes CI in some ways, that we would be competing for resources with CI at a big company. And that would not be a successful way to run this kind of experiment. And we talked to various people, we of experiment. And, you know, we talked to various people. We just kind of decided, you know what, this is a good thing to start a company around, just to experiment with it, and this is what we're going to focus on.

I mean, to me, that has kind of been the advantage of a small company, is that you can pick a problem, just really focus on it, and not have to worry about competing resources. Cool. Have you guys raised any money at this point? Yeah, we've raised money. We've raised enough money to do this for a while. Do you have a sense of when launching will happen?

A lot of what we're doing right now is showing it to companies who are interested in the idea, who are excited in the idea, who are excited about the idea, but are willing to kind of put up with the warts, that I will be very clear that we have a production tool that you can use, but it is not easy to use. It is not really that fun to use.

We are still figuring out the UX and still figuring out how to make it a fun to use. We are still figuring out the UX and still figuring out how to make it a joy to use. So a lot of what we're figuring out right now is, how can we make this a tool that a few companies really love using? And then once we have that, we raise more money and really go out the door

trying to grow it to as many people as possible. We're definitely in the phase as a company of just doing a lot of product experimentation. And there are certainly things that we built where we're like, yeah, we built this, it's not very good, let's go in a slightly different direction. That sort of thing. Got it, cool.

So you're still making something worth trying. Yeah. And then you start doing some early testing with users. Cool. So you're still making something worth trying. Yeah. And then you start doing some early testing with users. Cool. Yeah. You mentioned that you're not a huge Brett Victor nerd like I am. I'd be curious to know, you seem very passionate about this very specific problem. Whether you would do it at a big company or this company, it seems like you're excited about this problem. I'd be curious to know

where does this motivation and inspiration come from? Do you just have really terrible experiences with the lack of a solution, or is there someone else who's motivating this or inspiring this work? I think this is mostly just working on

WYSIWYG editors in general for consumers and just realizing and I have a strong belief that is just the way people interact with the world people interact with their tools like close feedback

you instantly see the change you made and you feel that direct connection to the change you made. That's cool that you were inspired by your work on, yeah, WYSIWYG, Medium. Yeah, and I certainly don't want to denigrate the perfect talk, because I think it just gets thrown around a lot as the kind of city on the hill. Yeah, of course. Cool dev tools tools demos.

Yeah, well, so many of the people I talk to are overly obsessed with it, so I'm excited to find someone who has different motivations. Yeah, yeah. I mean, to me, the more interesting problem is how we get there, which I think he talks about less. I mean, the classic example is that everyone who writes

WYSIWYG text editors, or WYSIWYG rich text editors specifically, the first thing they do is say, oh, let's store HTML in a database. And I just, no, no, that's actually a terrible way to write a WYSIWYG text editor, because HTML is a terrible editing service. And to me, what excites me is, OK, we want WYSIWYG with dev tools, but what is the path

to get there? How do we store them? What is the data model that supports that WYSIWYGness? Yeah, yeah. That reminds me of one question I meant to ask earlier. Maybe this question doesn't even make sense to you, but what would a language that was designed for build tools look like? Yeah, does that make sense? Oh, that is a really good question.

I have no idea. I am a programming language enthusiast, but I don't feel like I know what that future looks like. I'll let somebody else invent that future. Okay. Cool. Well, thanks so much for spending time with me. This was great. Steve, this was fun.

Thanks for having me on. Cool.