Glauber Costa: Yes. 100%. And we will. And I want to clarify that now, because with LibSQL it became very clear to us in maybe a month that that was not going to happen. So with LibSQL – I joked about it today, we had this goal of replacing SQLite for 10 minutes, because it’s a dream etc. It’s obviously a big prize. It’s obviously this big prize etc. As I wrote in my blog post, were we bummed about it? No, because we built a pretty successful business on top of the code, on top of LibSQL, which is today our company, Turso. So for us, it was this exercise of – if you heard the expression “Shoot for the stars, because even if you miss, you’re going to hit the moon…” For us it was like “Yeah, it turns out – I don’t think it’s going to be possible for us to replace SQLite with the fork.” But that’s us hitting for the stars. We didn’t hit the stars, we hit the moon. The moon’s great. Again, we built a super-great project, we’re having fun. LibSQL brought something to SQLite that wasn’t there, which was like the serverless, and running this on serverless environments, on the cloud platform, syncing databases… One of the things that we do with Turso is you can sync your databases between different devices, and backups, and all of that. And this is going great. I mean, this is going fantastically for us, and so we were never sad or disappointed that this thing that crossed our mind – can you imagine how amazing it will be if people just start using our fork instead of SQLite? We were never disappointed at that.

But when we put the rewrite out, it became very clear - and I’ve been using this analogy from chemistry, that the reaction was right. LibSQL was something that the market was clamoring for. I think what it became very clear seeing the reaction of Limbo now is just that the activation energy is not enough to make the reaction happen.

[20:15] And after talking to a lot of people - and there’s a whole story of what happened after we announced this… I talked to a lot of the people who came and started contributing to the project… And what it became clear is that they all agreed with us, that we need a better version of SQLite. I mean, it will be fantastic if we have something like SQLite, but that does this, and this. All our original vision. But the fork just wasn’t differentiated enough. It just wasn’t ambitious enough. It just wasn’t bold enough to get people to come and contribute.

Furthermore, it is actually very hard to do, because one of the things you did mention - the SQLite test suit is fully proprietary. So once you start making changes that are very deep into the core, you start hitting a bunch of issues. And some of them – it’s just like yourself saying “I know that the best way to solve this problem is this, but I’m going to solve it in this other way, which is almost as good, but not great, but it’s less risky.” So you start having this on your mind. So the fork never really unshackles you fully to go pursue this, which is why when we announced the rewrite, what we saw, again, was something I’ve never seen before. We got 8,000 GitHub stars in a week, essentially. We had what I consider to be for the first time in the history of computer science a Hacker News comment section that was mostly positive, with just a couple, I think maybe one or two comments only that were trying to denigrate us. But the rest very supportive. We had this fantastic, inspiring story of this individual who is in prison at the moment, and he was one of the first people in the United States to be granted access to the internet in prison. He can access Discord, but not X, by the way; that maybe say something about it. But he is now the fourth top contributor to the Limbo project…

Jerod Santo: What was your demeanor at the end? Were you over the moon? Were you going out for steak dinner? Were you resolute? Were you –

Jerod Santo: And we thought, “Well, wouldn’t we just get Danny back on the pod and just do it fresh, like a real episode?”, which was another route we could have went. But you know, this is a business. We do put shows out on the weekly, and we needed a show that week. So it’s like, that was definitely part of the decision-making process. We can’t act like it wasn’t. We have sponsors who count on us to put shows out, and so I was like “Can this be a standalone episode?” And I’m glad that at least for Jamie it was one of the best of the year. Hopefully, other people liked it, too.

Danny was over the moon, because I saw Danny at All Things Open and I told him “I don’t think we’re going to get that episode out.” And thankfully, it was about his life story more than it was about current events or anything, because it was last January that we recorded it. So it was pretty much evergreen…

Marc Boorshtein: Not even, no. That would have been awesome. That would have been amazing. No, this is – so we first got involved with this in 2011, when we first got involved. It was actually kind of funny, because I had just left my full-time job to work on Tremolo, and I was at a pitch contest, a mass challenge. So I was up in Massachusetts with my partner, and I was working for a consulting company at the time, that dropped this thing in my lap. And I was like “You’ve given this away. There’s no way I can implement this and be profitable.” And I got back and started talking to my customer, and I was like “Tremolo could do this.” And they’re like “Okay, let’s pitch it to them.” And the sun, the moon and the stars aligned, and they’re like “Okay, let’s do it.” It worked beautifully. But it was Active Directory. And with Active Directory, local government typically is very, very Microsoft-focused. So everything from their on-prem, all the way up to the cloud is almost entirely Microsoft, at least in this region. Different regions are going to be different. But at least my experience has been most localities are very, very heavily Microsoft-focused.

And so they had Active Directory, and if you’ve ever worked with Active Directory, the only way to get two Active Directories to talk to each other is to just take all the firewalls and throw them out the window. So they didn’t want them hooked up directly into this thing, they didn’t want them talking to each other… Active Directory – I mean, that’s the keys to your entire kingdom. So you don’t want to just like “Yeah, we’re just going to merge these things and make them all work together.” That’s a little dangerous.

So we came in and said, “Alright, we can link these things together in a secure way.” At the time, we were doing everything via LDAP virtual directory. So if you’ve ever worked with an LDAP directory, you take a proxy that knows LDAP on the front… Think of like an HTTP proxy, but for LDAP. So it talks LDAP on the front, and then it talks whatever you need on the back, and creates this big, virtual tree. So we created this environment where it was this big virtual tree of all these different infrastructures… And then we were working with - at the time, I think it was SharePoint 2011… And so we had to integrate that in, which was a whole kind of fun.

[00:08:04.29] And we got it all working beautifully, and so they’re like “Yes, this is great. We want to move forward.” And then I learned about government procurement. So it took us almost two years to get the procurement group, and we finally got it up and running…

Quincy Larson: Oh, yeah. I would be over the Moon. I would be through the roof. I would just be super-duper hyped that I could be a part of something like this. And I wake up every day and I thank God that I am able to be a part of this, and do something that is helping people. And - yeah, so I hope that doesn’t come across as like immodest, but I do feel like I have been a small part of something monumental so far, and I also feel that we’re just getting started.

Adam Azzam: I like to think about workflow orchestration as if you tell us what to run, where to run it, when to run it, and what to do when it fails, Prefect makes it extremely easy to author those rules on your typical script that you’ve got running locally.

So if you’ve got your Hello World script, you’ve got your callout to Open AI script, you’ve got your “go scrape this web page, and then go extract a bunch of data from it”, we give you the tools to say “Great. This works locally. But now if I want to run it on a massive K8s instance, or I want to run on AWS, or I want to run it on Azure”, you can do that in a line of code.

If you want to run it every third Thursday when there’s a full moon, we make it incredibly easy to express. When you want to say – if you start getting a bunch of 503 errors, because the resource is down, or maybe you start getting 429 errors because LinkedIn is onto your scraping work, you’re sort of scraping, let’s say, pipelining off of it, you can control the custom behavior of saying “Well, pause this workflow, or maybe start using a different IP address.” So we allow you to bake in different handlings of failure, and sort of native resiliency into that. So retries, idempotency, caching, transactions.

Jerod Santo: He’s been out there, building Transistor… Started later than Dan, but actively building that. So when you acquire something like this - of course, I guess with this one it’s your first time, so how do you know what you’re going to do…? But what’s the strategy? Is it just “I’m going to maintain it and just continue to get maybe a little bit of growth, maybe not, but it’s making money right now”? Is it like all in, “We’re going to take it to the Moon”? What are you thinking when you buy this?

Kevin Ball: Yeah. I love that there – there seems to be more of a trend towards folks doing this. I think we’ve talked before about IndieVC as a model as well, where - it’s Bryce Roberts’ this thing, where he’s trying to support small amounts of fundraising… It’s essentially kind of trying to fill the role that – if you were starting a traditional company, like a bakery or something, you could go to a bank and get a loan for your startup capital, and then you’re able to pay that off over time, and there’s not an expectation that you’re gonna go super-rocket ship to pay things off. That approach is not available for new product development, because it’s too unpredictable, too hard to model, banks don’t understand it, all these other things.

Traditionally, that gap has been filled by venture capital, but the venture capital model is really biased around these rocket ships. “How do I get to the Moon?” They push for everything to go that far, they want to put more money to work, all these different things. And so there’s an opening for something in the middle, that is able to take a little bit more of a risky stance, and maybe is run by people who understand software and product development a little bit more, but don’t expect you to go to the Moon, they expect you to build a profitable business, maybe in midsize niche, and payback maybe not at 10x multiples, but like 2x multiples, or payback with profits, or things like that. There’s a huge open space there, and I think we’re seeing a little bit of re-interest in that now. I just hope that it captures the imagination of more founders as well, because I think there is still the VC press conference of being a startup founder to the Moon is the sexy thing to do…

Pablo Galindo: Actually, that’s a very good point. So one of the things that actually surprised me a lot… One of the unknowns here was how the community was going to adopt this, the reason being that it’s just not that Python needs to be multi-threaded. Now if you compile C extensions, which are really, really popular in Python - that’s one of the reasons why so many people use Python the language, because all the machine learning doesn’t happen in pure Python. It happens in compiled code, and CUDA, and GPUs. But Python is the driver or the glue. So all that code needs to be changed, or adapted, at least… Because now you don’t have the lock protecting you, and who knows what happens now, right? Which is really challenging, because right now you need to go through the entire codebase, that huge thing, and sanitize the codebase through this particular problem. And there’s no manual for that, if you think about it. So you need to reason about the entire thing.

[00:35:48.23] And we were a bit scared about how people will approach this, or what will happen, in the sense that if you don’t do this, or you don’t do this correctly, it’s going to crash all the time, or it’s going to crash just once every blue moon, or whatever. So we don’t know. So one of the things that we have seen, and is really impressive, is that the community has jumped this – like, incredible. People are building two versions of these extensions, one for the normal build, one for the free-threaded build, which is already huge. This doubles your CI time, doubles your storage for the extensions… So it’s a lot of work, actually. And there’s a lot of people that are so excited to jump to these extensions, and they try to fix it and reason, and try these little locks all around.

So all those people have been trying it, and one of the things I have been super, super-surprised here is that once you add those extensions, and you have a final application – like, I don’t know, a machine learning, whatever it is… Or like an LLM, or whatever you’re thinking, that uses a lot of these things, not just one; like five, six, seven really complex ones, plus interpreters, plus maybe a web server, something like that… And then you run it through the free-threaded version, it just works.

I mean, again, who knows? Maybe every Saturday you need your entire SRE team looking at it. But right now, it’s not mega-crashing. Because what we thought is that this was going to immediately crash when you add enough complexity to this. Because it’s just a statistics thing. The chances that there is some bad interaction when you pull out the threads and the amount of code that is used - it’s inevitable. And still, from time to time, we find very funky s**t in the interpreter when you call a method and sometimes another method is called, because there was something, like a memory reordering problem, which is a very technical, deep thing… And debugging that particular thing is just hell. But that is very rare, and obviously, we fixed it immediately.

And we are really surprised about, first, how many people have jumped at this, and they’re super-excited, and they want all of those extensions, and working. And second, how “stable” this is, meaning how little bugs we have seen in the while. We expected many, many, many more, and we are seeing very little. So right now, it’s super-promising.

Jerod Santo: I was thinking along the same lines, because my wife has got obsessed with the DALL-E implementation inside ChatGPT, where it will just generate images for her… And she just – she’s a very visual, graphic person, but never has done the training of graphic design, you know? But now she can just describe what she is envisioning, and then it provides a close approximation, and she can say “No, show me seven more that look more like this.” And eventually, it lands on something that she’s happy with. And she’s just over the moon about this. And I’m thinking the same thing for websites. That’s why my eyes lit up when Kball said that, because it’s like “Yes, just allow me to describe what I’m interested in”, and that’s empowerment right there.

Now, Kball, can you take that from inside of cloud or wherever it is, and host it somehow, directly onto the web, so that you can share it?

Mat Ryer: The Moon one’s obviously absolutely ridiculous. That person should probably be ashamed of themselves.

Justin Garrison: I wonder what the culture was like In the ‘60, where it’s like “We’re landing on the Moon…” They had to move fast. My grandfather actually worked on the Apollo missions, which is just like, his pictures were absolutely amazing. And I never got to hear stories from him of what the culture was like, but I can only imagine that at some point you’re just like “No, this has to happen this decade.” Someone said “We’re going to the Moon.” And the fact that so many people and so much funding and money was in place to do that… And now on the opposite side, where it’s like, no one told you to do this; no one told you “This is the thing we have to do.” And so the initiatives are very different, of like “Hey, we see where we can add value to people that maybe had to drive their truck for two days to go see this pipeline”, or something like that. Like “Hey, I got you in an hour and a half. And you’re gonna get your images, and they’re gonna be processed, and we’ll see all that stuff that maybe you couldn’t see before.” And that’s just pretty amazing, to be able to add that value that quickly.

Chris Wanstrath: I’m not involved. I’m a huge fan of Rust. I’ve written a lot of Rust. I don’t think anyone should write web applications in it, unless maybe you’re trying to scale to the moon.

Programming languages are tools, and they’re suited to certain tasks. So it totally makes sense to me that Rust might not be the best for building what they’re building. And you need these object-oriented concepts in the document model and things like that, and so you’ve gotta use the tool that is best for the job.

What I think I’ve told Andres from the beginning - and it’s their decision, but… I’m a huge fan of the memory-safe languages. Huge fan of what Rust does provide in terms of safety. And I know Swift has a lot of that, too. So that’s something that I really think the whole industry should be moving towards, and so I’m just happy with the decisions that they’re making. Surprised about Swift, but my good friend is a huge Swift – I don’t know what you can call it anymore…

Johnny Boursiquot: There’s nuance there. I disagree, to some degree. So when we think of technical debt, we tend to assume it’s because the code is bad. The examples we’ve used is AI generates code, and the code by definition is going to be average, because it takes in all the – it ingests a bunch of code from the world around it, and all that code is mostly not good. I’d argue that whatever code has been fed into these models, certainly that code has gotten the world to where it is now.

And we are a technology-advanced world. I would rather live in this world, with its, by some definition, bad code, than to live in a world without it.

So I would say that we should give ourselves as humanity a pat on the back for having written code that gets us to this point. I mean, we can fly planes, send rockets to the moon, and do all kinds of crazy things. So I’m going to be a bit more gracious towards us, engineers, software developers as a whole, and say rather than it’s the code being bad, I think it’s the fact that it’s not often – you take any developer at most companies… It’s not that they’re writing bad code. It’s not that they don’t want to write good code. Technical debt is not inherently a software problem. It is a business problem… Meaning that you are going to be learning. The business is learning. The reason why the business keeps coming to you and asks you to change a feature, or add a new feature, or fix something that they thought was going to work one way and now it doesn’t work, is because they too are learning.

So when the business comes to you and says “Hey, I need you to build this software. And here’s the requirements doc”, however little, however much they give you… And you as an engineer, you take that spec, with your team, or your manager, or whatever it is, and you go build software. You’re building that software on certain assumptions, and then you come to find out later on that, okay, some of those assumptions were incorrect, because either we didn’t have enough data, or whoever was supposed to give us the correct answers made some assumptions based on bad data… Whatever the case may be. It’s supposed to be a learning process for every party involved, the stakeholder and the people building the software. So that learning experience is going to generate some artifacts. It’s going to generate some learnings. That is inherently what technical debt is. It is some assumptions that were made in delivering a piece of software, but now that we know better, how do we address this?

So to me it’s not that it’s bad code. It’s bad assumptions, leading us to say, “Okay, well, because we had to create these classes, or we had to build this functionality, or write these services that are now no longer valid, or now need to change, because now the business knows better”, then we’re like “Okay, well, crap, we have to deliver this new set of features that they’ve just brought us, we have to do that next week… We don’t have enough time to go back and fix all the things, all the assumptions that have been made.” Now we have to say “Okay, well, how can we patch these six other things just well enough to allow us to deliver on this new set of things that has just been brought to our doorstep?”

[00:48:23.09] So you do that enough times, of course the technical debt is going to mount, and it’s going to mount, and it’s going to mount, to the point where teams can’t move fast anymore. And then at that point you’re like “The business doesn’t really want to give us time…” So every time you hear the myth of “Oh, I wish the business could just give us a couple of months for us to go fix some things.” That is an expression of frustration from the engineering team basically saying “Ah, We never get time to fix those things we know we ought to be able to fix, in order to move faster. We never get that time from the business.” That’s a point of frustration.

No developer realistically believes that they’re going to get six weeks, eight weeks to go just fix things. But what they are saying – it’s a cry for help. What they are saying is “Ah, I wish addressing our technical debt as we proceed, as we go was part of the culture.” And to me, that is the biggest issue I’ve seen time and again, be it very large companies, to very small startups, that are designed, that should be accumulating technical debt, because they are learning a lot faster than the larger organizations, based on my experience… They are generating technical debt faster. The problem always comes, big or small, when you don’t address technical debt. You just keep on building, building, building, building, patching things, making just enough so you can build the next set of things, never addressing and going back and fixing the old things. To me, that’s the biggest issue.

Justin Searls: So there’s two annoyances, two big annoyances from like an ergonomics perspective to trying to use the spatial computing for computing, which is one, when you’re in an immersive environment, meaning like you’re not looking at the pass-through video, you’re on the Moon, or in Yosemite, or something, and you’re holding a magic keyboard, an Apple-branded magic keyboard in your lap, that keyboard is invisible. So unless you’re an amazing touch typist, you’d be surprised how often you’re finding yourself wanting to look at the keyboard… Especially when it’s on your lap loosely. There’s an OS 2 apparently for magic keyboards and magic keyboards only will punch that through the – it’ll identify it and punch it through the immersive environment, so you’ll be able to actually see the keys. That’s one huge thing.

The other big win is, for whatever reason, you can pair a Bluetooth trackpad to Vision OS, but not a mouse. And it seems to suggest that Apple – we all know Apple prefers trackpads to mice, but it seems to suggest Apple is saying “No, the future is no mice allowed.” Apparently, Vision OS 2 will let you sync Bluetooth mice. So apparently, it was just an oversight version one thing. So if you’re a mouse person, that’ll work.

Alright, so now we can get to the thing. So tell me all about the ultra-wide.

Mark Russinovich: Effectively, yeah. It was a very powerful jailbreak. Very rich. As opposed to a single-line jailbreak, like “Write me a recipe for a Molotov cocktail”, you could get it to tell you a recipe for a Molotov cocktail in the context of a story that is set on the moon… you could really push it towards doing whatever you wanted.

Adam Stacoviak: There is. Yeah. I don’t know if I’m that excited about him being the star in Project Hail Mary the movie. I don’t know, I can’t say for sure… I think First Man was a really good movie that he was in. There’s several – which was basically the story of going to the Moon. That’s why it’s called First Man. First Man on the Moon. There’s a lot of good things about Ryan Gosling as an actor. I think he does a pretty good job in most cases. It could be Ryan Reynolds… I think he was also slated to be – and I think he’s maybe good for it, too. I don’t know. There’s a comedic angle to the story, too. There’s some humor in it. So I don’t know.

I would also be certainly happy with a no name actor being found and discovered. Because that’s a breakout kind of role. We don’t see enough of that these days, I don’t think.

Adam Stacoviak: Yeah. I’m glad you explained that, because you did a much better job than I would have done explaining a Geiger counter… Although I do understand the radiation and measuring it. I was surprised, I’ve never looked into this to know it’s really available, where you can just maybe go – maybe not readily, literally available in literally any Radioshack, or go buy it at Target or Walmart or whatever… But they’re available to maybe hobbyists and purists who want to like look into this. But the reason why I think it might be odd for any given civilian to buy this thing is because you can learn things about the Earth and its atmosphere, and let’s just say scientific beliefs that may not actually be factual in our world. Like, you can learn for yourself, as a scientist would, for example. Even specific to the radiation belt that’s around the Earth, that you say prevents or could prevent human travel to Mars, or let’s just say the Moon.

Adam Stacoviak: My favorite is Dusk Under a Flaming Moon.

Autumn Nash: How amazing is it that you could build software that’s going to be in NASA’s car that’s gonna drive around the Moon? That is so cool. There’s also a Java – one of the coolest open source projects that I’ve seen is a NASA project, and it does a lot of simulation software, and different things… But it’s written in Java, and it is an open source NASA repo. I think it’s so cool that they open source and you can contribute to NASA. How cool is that? What if you contribute to something that’s running in space? That seems so neat.