Adam Stacoviak: The way I got here really was – we’ve shared it several times over many shows and whatnot, so I’ll try and give you a more recent version of a straight line; we did this with Adam Jacobs recently, talking about the business model of open source…

For me, things began really with Geocities, and wanting to put something on the internet, and then WordPress and the open source nature of it, being able to see the source code, and putting something on the web… And a personal blog that turned into something that was meaningful for me to learn, but then meaningful for my family… Like, “You’re actually really good at this. You should do more of this.”

Timeframe-wise, I would say this was like 2004-2005… So I hadn’t really considered at the time – the web wasn’t as mature as it is now, to say “Okay, there’s a real future here.” Because I think now it’s more mature, to the point where it’s pretty clear there’s a future here… Whereas then it was sort of like “What’s gonna happen here?” It was still sort of like being proven.

[04:06] But it was so far back, I was like “I should try this, I guess. I should dig a little further in.” So like with any good advice – I took my mom’s advice. My mom said “Adam, you’re really good at this. You should really do something with it.” And that’s when I took it more seriously. I didn’t go to school for software development, I didn’t go to school for design, or user experience, or the things that I consider skillsets I have as a frontender, or something like that.

I sort of just played, and tinkered, and there you go. I got into more design stuff, I eventually got into Sass, I had a blog called The Sass Wave for a while there… The repo is still there, but the domain actually expired accidentally… And so the domain isn’t there anymore, unfortunately, but the Twitter handle is still there, and the repo is still there… But the impact was still there around Sass as a processing engine around CSS, and programmatic stuff around it. It was really interesting, really pushing CSS3 at the time forward…

I think I pushed a little bit further there, got into open source, and it was around 2009 a buddy of mine and I was sitting there, and I was like, “You know, we should really do a podcast around this idea of open source.” Because GitHub had just made itself exist basically the year beforehand, and it was like “Well, open source clearly is moving fast. How do you keep up?” And so that became our tagline: “Open source moves fast. Keep up.” We established a blog called ChangelogShow.com, and we quickly named it TheChangelog.com, which was almost as bad as the first one… TheChangelog stuck around, but we eventually moved to Changelog.com. We decided to make a podcast and a blog really chronicling what happens between versions of open source software. And so that’s somewhat of a short answer to that story.

Lucas Fernandes da Costa: It’s been a few years now… I remember when I started, to be honest, I’d seen a friend of mine using it, and it looked so cool, and he was super-fast with it. So at the beginning I was more impressed than I actually – it was not as if I had made any formal decision. I was just impressed by how things were happening.

I remember we were sitting next to each other in college. He was using Vim, and I was like, “Hey, how do you do things so fast?” And then he showed me his dotfiles, and the explained how the whole Vim code works… So then I just started trying it out in my free time, because at the time I was doing an internship. If I had used Vim during work, and stuff, I think I wouldn’t have been productive enough, but after a month – I just persisted; I just kept trying…

In the beginning, I’ve gotta say, it was very frustrating. But after a month, I was just so much faster, and my workflow got so much more comfortable that I just couldn’t quit. And now that I started using CLI tools more often, all I know how to do, all my workflow revolves around CLI tools. I tried some IDEs, but it’s just not the same thing, even with Vim mode. It’s just not the same thing.

Jerod Santo: Well, I think you’re spot on there with regards to like the order of precedence of things that you need to get right. I mean, as a user, if I took those three things - performance, extensibility and collaboration - and I said, “Which order do you want them in?”, that’s the exact order that I want them in. And so many tools – to this day, I’m a Sublime Text user, because for me, I use Vim in the command line, but for text editing in Sublime Text, because it’s just faster; it’s faster than VS Code. It’s faster than Atom used to be.

I liked the ideas behind Atom, I love the extensibility, and just the whole – it’s web tech, you can hack it yourself. But it was always just a little bit too slow. VS Code feels the same way, especially when I start searching and navigating files. It’s just a little bit slower. And so performance for me - it has to be there; like, it has to be there. And then extensibility is awesome, but comes next. And then for me, because I code mostly by myself, collaboration and that kind of stuff is - yes, I could do better. Yes, I’m an outlier, because most people have teams… But not as important.

I’m curious, though… So this Xray work that you did, one of the things about Zed and this breakthrough performance that it has - according to the website; I’ve only used it for 15 minutes, and it does feel fast… But it has built like a video game thing, so like you’re doing this whole – because it’s like “Well, how do we actually make it fast?” And you could say Rust, but okay… That’s not going to get you all the way there. It’s going to get you to be faster than v8 maybe in some context… But this 2D rendering GPU thing - ha that that come out of your work on Xray? Is that a brand new thing you guys built for Zed? So in other words, is it just like a spiritual successor, or is there actually code that you built on this version of Atom 2.0, which was called Xray, that made it into Zed?

Perry Mitchell: [20:18] Yeah, it’s a really fine line to walk… It’s like, how slow do you make it before it actually gets annoying? And I think that we’ve skirted that a long time. It’s been a huge challenge for us, because if you take your MacBook, for instance - it decrypts and encrypts insanely fast. It’s ridiculous. So us using 250k or 300k key derivation rounds is actually quite low; it’s recommended to be a bit higher. But the second you take that process and you try to run the same process on a phone, especially an Android phone from maybe 5-10 years ago, it’s horribly slow, and the user experience is just not there at all… So you have to be considerate, but you also have to make sure that you don’t just drop it down to an unreasonably insecure number… So it’s a bit of a challenge.

Jerod Santo: And at the time, you had released a bunch of npm modules, specifically a lot of command line tools that were very much popular amongst developers. Ever since then, I’ve been following your blog and you write quite prolifically; I can barely read them as fast as you can put them out. How do you get that done?

David Kanter: Sure. So MLPerf is a set of performance benchmarks to measure how fast you can train a neural network, or do inference. There’s a very long history of this sort of benchmarking in computer systems. So in a lot of ways, the effort was sort of spiritually influenced by those prior efforts. You know, organizations like SPEC and TPC, that help to bring together industry and academics, and kind of give folks a common set of benchmarks.

What we really noticed early on is there’s so much excitement around machine learning, around AI, but it was almost like the UN without their translation devices, and people would be talking about performance in ways that were very much not apples to apples. So the goal of the benchmarking side of things is to both provide a common set of metrics for what constitutes progress. A benchmark in some sense is a barometer on progress. And you know, does it always point true North? Not exactly. But if it’s off by 5-6 degrees, it’s fine; you’re still heading in the right direction. But it’s also about giving everyone a common language for where you are in fact heading, whether it’s sales and marketing, or engineering, or academic research, or even folks in the government… And sort of clarifying the field and providing a map and a barometer, in some sense.

Tim Stiles: No, you can do it. I’m not kidding. I had one coworker that’s like “How long would it take me to be a master in alignment software?” I was like “Master? A long time. Second-best, maybe third-best? It depends on how fast you read, but it could be this year.” It really depends on what your focus is and what you’re doing. We all have our unique specialties.

[00:46:01.00] But AI is this weird thing where - you know, machine learning is so obvious; everyone in tech knows it’s obviously overhyped, right? It’s like this thing where now we’re having all these general models, which are awesome… I was writing basic genetic programming with generative models for a weird little Pokémon a decade ago, but now we have full artistic renderings of – for example, my Twitter banner is a flying seaweed monster. I had to tweak it a bunch, and be like”Flying Spaghetti Monster, but with seaweed, and some other stuff”, and eventually, I got it to do the thing. But we’re at that point where we have these generative models that - it’s been a long time since I’ve been in deep learning, so not only has this field changed a lot, but the terminology they use is changing a lot. Every five years they have to reinvent every term for linear algebra. I don’t know why they do this, but they do. It’s a weird thing.

I had a similar problem when I was first learning it like five years ago. I think it was “What’s a linear filter?” Isn’t this just a kernel? And then the PhD [unintelligible 00:46:53.03] “Yeah, we just do that… I’m sorry.” And that’s a similar thing. Now there’s all these different terms, I’m like, “Oh, is this basically a convolutional neural net?” They’re like “Yeah, but it’s different…” And I’m like, “Uhm, okay…”

So with machine learning and AI I think there’s a lot of opportunity to get around what have been these traditional problems in modeling, where we don’t have the math for it; we don’t have – like I said with the three-body problem, we don’t have the math. No one’s [unintelligible 00:47:16.13] model three bodies orbiting each other. It’s just, we haven’t done it yet. But David Baker, who is a professor at the University of Washington - his lab came up with this game called Fold It, where essentially they’d get all these molecular biology students in college, and maybe high school even, to play this game where – humans are actually pretty good at figuring out from like a basic string and some mechanical principles, like a 3D model of this DNA laid flat, how to fold it like origami into a shape that’s what we expect at the end. So they’d have the flat sequence, and then the expected sequence they’d get experimentally, and they’d have these students essentially be mechanical turks for fun, to train this model to figure out how proteins fold… Which is super-useful.

So in this case, there’s some real roadblocks, where machine learning is absolutely vital, and you do need machine learning for it. But there’s also a lot of people that do machine learning models, and then you’re like “Yeah, you didn’t need machine learning for that.” It really depends.

But the folding stuff and the molecular dynamics stuff, stuff that is molecular interactions - I see a lot of potential there. There’s a lot of work that can be done there, especially with – so there’s something called ligand binding, which is like a fancy term for “We take a small molecule, we’ll make it attach to some protein of interest, or something, disrupt some function, that helps cure some disease.” It’s all downstream… Like, if you tried to do like a stack trace of like how medicine works, instead of a bug failure, it’s pretty brutal to be able to do that. We’re still at the point in life where we don’t really have that. The closest we get is my software, which is - yeah, that’s not good enough, I’m gonna be honest. Go’s stack trace cannot heal you. Sorry, that’s not a good endorsement of the language, but we’ll get there someday.

But that sort of space, of figuring out what molecules interact with each other and how they fit, and how they puzzle-piece together - that’s some really good use cases for machine learning, where you’re just [unintelligible 00:49:06.15] structures against each other, you’re doing - I call it sub sampling; or people call it fingerprinting, where you decide, “Oh, this is the only place where we really care about seeing [unintelligible 00:49:15.10] because that’s the therapeutic effect. And so there’s a lot of research there in that, and that’s super-valuable, and I don’t think there’s going to be many other routes to do it. Of course, there’s these classical deterministic ways, which are good shorthands, and they’re probably faster, and you don’t require like a big, beefy supercomputer to pull it off. But I think that’s the place where machine learning is really the – that’s the real strong suit there.

There are things with – people have figured out how to do DNA synthesis fixing, like I do, but like with machine learning, and it’s like… I don’t know, mine works like 99% of the time, or something, and there’s no machine learning involved… And I haven’t really looked at the other people’s models, mostly because I don’t even think they’re on Hugging Face. I mean, I’ve gotta give the Hugging Face guys super props. There’s also a machine learning library in Go that directly connects to Hugging Face. I wish I remembered the name of it right now, because I want to give their developer a shout-out. You should have him on the show, actually.

Johann Gyger: [11:45] So the short answer is I was somewhat lucky to become an ambassador… But I can start with the longer version, which goes back to 2015, and it started actually with containers. Let me tell you that story, when a colleague of mine demonstrated to me how Docker works. He just ran a container, some command, and it was so fast I was blown away. After that, I talked – at the time I was working for an insurance company, and there were some ops people, or infra people, and they immediately jumped on this train, like “Yeah, let’s do that. Let’s go with containers as the universal format for production as well.” After that, the discussion came up, “If you have containers, how do you orchestrate those?”

So there was a discussion whether it should be Docker Swarm, Kubernetes, or OpenShift. Finally, we decided to go with vanilla Kubernetes, which was pretty young… It was already there, but it was still a pretty young project… And to decide to go with Kubernetes at this time for an insurance company was a bold move. So that was between 2015 and 2018, and then in 2018 we thought “Well, there’s not only Kubernetes. There’s a whole ecosystem that’s going on.”

With two colleagues we went to New York, and we met some CNCF folks, like Cheryl Hung, and late Dan Kohn… And we thought “Well, we have to do something about that as well”, so we started our own meetup in Bern. It’s the Cloud-Native Bern Meetup. It’s a community now more than a thousand people. And if you know Switzerland, it’s not that large. It’s a small place. And that’s a huge community for such a small city like Bern. And we went on, and made like 13 meetups in between, and somehow I was lucky to become an ambassador as well. The selection process is not transparent, and I think it’s just because of the community work we were doing in Switzerland. I think that was the main reason for becoming a CNCF ambassador.

Todd McLeod: I’m not. I’m not writing a book about Go. I love being able to connect with people. I kind of view it as – anthropologically we’ve learned from each other in person; that’s the vast amount of our history through evolution as humans. We learned talking to each other, so in my trainings I really love trying to… So much gets conveyed non-verbally. You can hear my voice, but if you can also see me, I think that that conveys a lot.

[16:14] I just really love that medium of teaching where it’s online, it’s a course, you can see what I’m showing you on the screen, you get the nuances of my voice, I could school you a little bit and give you direction and tell you to do this exercise (Go do it! Go do it now! Just pause the video, do the exercise!) It’s fun; personality comes through, you can see me…I really try to do that with all my courses.

A lot of courses are just sort of a very narrated, reading a script, voiceover presentation or screencast. You can learn things from those, but it lacks that life and that vitality. I think that’s again where that sort of artistic soul of mine comes in, where I love to create and think about the aesthetics of it, and what’s the final product, what’s the feel of it gonna be, and how do you convey something and have a good time and enjoy it, and also build all that into it?

So I’m not writing a book right now, but check this out! When I do a course, like me last course on HTML and CSS – because when I was teaching it and when I got back into it, I couldn’t find any materials that taught it the way I thought it should be taught, and there’s a lot of things that would… Like, “Let’s jump really quickly into bootstrapping.” It’s like, “No, you should really understand the fundamentals of HTML and CSS before you jump into bootstrap.” I know bootstrap gives you fast, quick results, but that comes at a price and is gonna catch up with you later.

My last course that I created HTML and CSS, the outline (the outline!) for that course is 300 pages. So I’m not writing a book, but my courses are very thorough. Each lecture I’m documenting what I say, and what the points should be that you get from that lecture, so students can go back and Ctrl+F through it to find that one subject. Or they could skim it and see, “Oh, do I need to watch this video?”
I just try to get people the tools they need to learn. That’s my craft being an educator, how do I do it as well as possible and create the most beautiful and useful pieces of education material; like an architect might want - I want a beautiful and useful building… That kind of a deal, you know?

Eli Bixby: Okay, so the first thing you have to figure out what kind of model you’re looking for, what kind of model you want to build. Pretty much all models, almost all models, are broken down into two categories.

We’re in the domain of supervised learning, which means “I have data, and I want to teach you things from my data.” Within that domain we have Regression, which is “I want my model to spit out a number.” 45.2.

Or Classification, which is “I want my model to spit out a category”, Orchid/ Not orchid. So here we know we’re in a classification problem. So then what we really need to do is we need to figure out, “Okay, what models have historically been successful for image classification?” And you can see, “Oh, Google has open sourced this inception model, but it takes two weeks to train from scratch, and probably my three-million-image dataset is not going to be enough to train inception from scratch.” It’s this huge, sprawling model… But you say, “Okay, many image classification tasks share a lot in common.” Like I was mentioning before, we have to identify these higher-level features.

[32:03] “So maybe I’ll just retraining the top few layers of the Inception model.” This is a task called transfer learning, and then you teleport to four weeks in the future, when my transfer learning sample has been published, and you look at that sample, and you look at how you do transfer learning… I’m sure if you google ‘transfer learning TensorFlow’ you’ll find a sample that is not mine.

That’s the breakdown high-level model. Then what you’re gonna end up doing is you’re gonna run this code, and you’re probably gonna need to run it in a distributed environment. Inception is a big model, you have a lot of data, so you’re going to need to figure out how to do that.

We provide basically wrappers around code that starts a gRPC server. I don’t know if you guys know gRPC; it’s this efficient RPC framework from Google. It uses the protobuf serialization format, and it’s basically built to be fast for large amounts of data, it supports streaming and all that good stuff.

DaShaun Carter: That is. And mine I think was academic. I was like “What is it like?” And the approach that I was going in with this is I had a hypothesis that a company, an enterprise - they should kind of pick one. If you wanna level up everybody and you wanna pass MVP, you’ve gotta kind of pick one. I’d been on the opposite side of that; I worked for a company and they bought a startup, and the startup decided “We don’t care, just get it done. Do this, and that, and that”, and then when they sold, they sold us a bunch of hundreds of languages, and all this, that and the other, ten different UI frameworks, ten different data frameworks all in the same package, and I was like “Yeah, maybe I was biased going into it.” So I’ve just kind of had this thread where maybe if a company wants to level everybody up and be able to deliver something, pass MVP, maybe they should pick one.

I know that different languages have their own strengths and weaknesses, but I feel like a lot of them can do a lot of the things. There’s a web framework, there’s slicing and dicing any which way… Even for COBOL. Like, hey, somebody did a web framework in COBOL. These are crazy things, but what does it take to get up and get out? Because the other part of a startup is “How fast can you level somebody up in a language?” It was kind of academic, but I was keeping those kinds of things in mind. I’m not sure what my expectation was.

Daniel Whitenack: [00:23:54.21] Some of our listeners might be curious why a person like me is sort of living day-to-day in the AI world is super-excited to talk about DuckDB. I mean, certainly I have a past in more broadly data science, and this is pain I’ve felt over time… But also, there’s a very relevant piece of this that intersects with the needs of the AI community more broadly, and the workflows that they’re executing. And one of those is - where I kind of started getting into this is in these sort of dashboard-killing AI apps that people are trying to build, in the sense that “Hey–” Another pain of mine as a data scientist in my life is building dashboards. Because you always build them, and they never answer the questions that people actually have… And so there’s this real desire to have like a natural language question input, and you can then compute very quickly the answer to that natural language question by using the LLM to generate a SQL query to a number of data sources.

But then when you start thinking about “Oh, well, now I have these CSV files that people have uploaded into a chat interface, or I have these types of databases that I need to connect to, or I have this data in S3 buckets”, and my answer could come from these different places, all of a sudden this kind of rich SQL dialect that you talked about, that’s very quick, and can run with a standardized API across those sources becomes incredibly intriguing for me. Transparently, that’s how I sort of like got into this, is I’m thinking of all of these sources of data that I could answer questions out of using an LLM… But how do I standardize a fast interface to all of these diverse sets of data, and also do it in a way that is easy to use from a developer’s perspective? But I also know that you all see much more than I do, and maybe that is an entry point that you’re seeing. I’m wondering if one of you could talk a little bit more broadly of how the problems that DuckDB is solving, and the problems that your customers are looking at are intersecting with this rapidly developing world of AI workflows.

Alex Russell: [01:01:48.18] Yeah, so I’ll try to break them apart a little bit, and say that if you’re an individual who has skills in JavaScript, and you’re looking for how to improve, again, the most important thing you can do is learn to be putting the user that you’re trying to serve at the center of it, and then start to think in terms of hitting frames, every 16 milliseconds; hitting that interaction target that you would like to have hit on your extremely expensive device, on that cheaper device, and for that marginal user. I promise you can do it. Computers are fast. And you’ll find out where your framework might be a stumbling block, or where React will generate way too much GC in a critical section or something, and it’ll hurt you. And that will turn into a challenge and you’ll learn to solve it… Maybe inside the framework, maybe you’ll learn to go around it a little bit… But those are incredibly important learning opportunities for you to understand the trade-offs.

And then I would suggest, again, as an individual, if you’ve been living up in JS land, where you’re kind of doing everything in user land, the most important hours you can spend are not learning another framework; they are learning the system underneath you. Every hour you spend learning how the browser actually processes your content and actually thinks about it, actually thinks about the networking and actually thinks about how we take DOM and CSS and we construct them together, and we create the layout tree, and then we paint out of the layout tree, and then we rasterize that out in the GPU - that flow and how we do that every 60 hertz, every 16 milliseconds, learning the pieces of it and the sensitivities of that system to what you do in CSS, and JavaScript, and through your HTML, will make you a better developer in every framework.

So it’s extremely important that you learn to think about that knowledge not as something that you don’t have to think about anymore, but as something that now that you’re not a beginner anymore is extremely valuable to you… Because you’re not at the end of your career, so it’s going to be important that you be able to adapt on the basis of shared knowledge across all of it.

And then for teams and for organizations, I’d say that that hiring thing - again, that’s trope; it’s not reality. I promise you there’s a fire sale on talent right now. Go look. You could just pay for it, and you’ll pay less than you think you would. But in terms of the choices that you make in terms of stacks, I would encourage folks to be a little bit more data-oriented, right? Again, step back and look at the actual experience. How many of these tools that you think are necessary are there to solve problems that the tools that you thought were necessary created, right?

if you start with simpler output, one of the cool things about it is – okay, let’s just say you move from taking your static marketing website out of Gatsby, which is going to go with some huge GraphQL query to return a bunch of React components, and render that on the server side, and do all this stuff. And then you have to think about how you’re gonna smush all these things out, and like do the CSS minification, and all that stuff… Whereas if you just output the same basic HTML, with the SQL query, and some PHP, or some Python, or some Ruby, how much more headroom would you have in the output in terms of the cost of the output, before you ever had to think about applying a tool to start tamping down on those costs, right? Because once you start thinking in terms of budgeting, latency budgeting, complexity budgeting, you can start to think about the trade-offs as being not about like for like, but it’s about being different in ways that structurally set you up for success if your system is simpler.

Now, once you get to a very complicated product, when you know you have a really complicated product, then you will need sophisticated tools, and they will need a lot of management. But going through that process of evaluating those things, and doing bake-offs, and learning the properties that emerge out of those simpler versus more complex systems will teach you something, it’ll give you a finger feel for whether or not one style of construction is going to be more appropriate here or there, and maybe help you make more informed trade-offs in the future about the style to build in for a particular kind of use case.

[01:05:43.08] And then I’d say at a community level, we need to step back, and I think we need to think about our relationship to society. And I don’t think that that’s going to be a thing that is traumatic, or even hard, right? We’re all here to build great experiences. I believe that. I truly believe that. I think Laurie’s piece in response to mine said something about how I think that developers are stupid, which is hilarious, on a couple of levels. But I just don’t. I work with extremely talented people all day long, and I’m grateful to get to work with them. And if we take seriously that it is evidence and science that are going to get us to a place where when we apply our skills, they turn into good things for the people that we wanted them to, that’s a fundamentally optimistic way of thinking about this technology.

We don’t have to accept what has happened, or accept that it happened for good reasons, or even accept that the people who are so attached to it are correct, or worth having in the conversation, in fact. But once we put the evidence at the center of what’s working and what’s not, I think we can start to reevaluate our relationship to the technologies, and acknowledge on the one hand we’re more than our choice in Java framework… [laughs] I promise you, there’s life after the framework that you love right now. And also, that as a discipline, the more we are reliably delivering good things for users and for businesses, the more likely it is that there’ll be more work for us, more good things that we’re going to be able to create in the future, and more users that we can help. And for me, that’s the goal, is to be able to help users. So when we put that at the center, and we put the marginal user at the center of that question, then I think we get to a good place. So I’m optimistic.

Ronald Marrero: That’s where a swarm comes into play. With a simulation you can easily – we feel like we made it easy to just grab your phone and grab a gamepad and connect, and make it do whatever you want. But obviously, that doesn’t work for real life… And the reason why is if you have a robot on another planet – you know we have really fast internet here; messages that you send out to other celestial bodies take forever to get there… And that’s if it gets there at all. You’ve gotta make sure it’s unimpeded… So you can’t just pull up a screen and manual mode a robot that’s on Mars. You have to rely on autonomous communications.

So when you go out to do a dig, you as the robot need to determine “How do I get to my dig site?” and “Is this a viable dig site? Am I gonna fall off a cliff somewhere? Is there enough materials to mine here, or am I gonna break my wheels?” That’s where swarm technology really comes into play. Being able to communicate, to have a set of robots communicate with each other and know “Hey, this path I’ve already determine that you can’t cross it” saves on computational resources and possibly even saves the robot from being damaged. By working in a swarm you can also dig more efficiently.

[44:14] So that’s probably the stretchiest of the stretch goals that we had. The implementation we currently have - we’re able to spawn up multiple robots, and we can give them each a set of X/Y coordinates to navigate to, dig, and come back to. We have that fleshed out and working. And we also have a game version, where if you spawn up multiple robots and you hand four people four different phones and/or controllers, they can try to wreck each other. We call that Battlebots. [laughs]

Justin Searls: So think of a company as large as Apple at this point is – they don’t run different business units as separate companies. There’s only a small handful of SVPs that kind of determine what’s happening… But underneath them is a traditional, big, layered organization of humans. And when you think about the iPhone, the iPhone is awesome, and they’ve never shipped a lemon iPhone. And why haven’t they done that? Because they are proving themselves with excellence, year after year, iterating on that hardware, and learning from their mistakes… And we don’t get to even see a lot of the mistakes. I’m sure they get killed before we’d otherwise see them.

The other department that came to mind - Apple TV. You guys were talking about Severance… Apple TV has got some real good hits. They’re more HBO now than HBO has been for a long time. And the reason is it’s run by competent people, that clearly have a commitment to excellence, and they’ve got the feedback loop of people are watching it, people aren’t watching it. People are subscribing, people aren’t subscribing. And there’s clearly some kind of wind at their back.

Now look at the third division here, of the people who run Siri. Siri has been running in circles since 2011. How do you measure success for Siri? It doesn’t make or save money, there’s not a lot of – because it’s kind of non-deterministic, it’s very, very difficult… No one’s done a Siri benchmark, right? Like, we’ve got all these LLM tests, and stuff. No one’s been tracking the growth and maturity of Siri as a functionality over the years. You know like that story we’ve heard about how the WebKit team at Apple had this build where if you committed any code and you pushed it up, and it made the test suite duration slower, the build system would reject your commit. You couldn’t make web kit slower. And that was just a hard and fast rule. And look around you; I still use Safari every day. And why is that? Because that rule has like a major impact on my user experience, because browsers are so vital. And Siri doesn’t have anything like that. If they have an internal benchmark, like… You look at all the posts over the last year - if anything, since the Apple Intelligence thing, it seems like Siri is getting dumber at very basic facts. So that organization, whoever’s in it and whatever it is, they’ve clearly not been on some sort of loop towards excellence that’s driving them forward in a clear and steady way. And the human organization that’s built around that, as a result, how could it be anything other than a nonsensical bureaucracy of finger pointing, and arbitrary excuses? Because there’s not like some sort of cycle feeding in and reinforcing the good stuff, and trimming away the bad stuff. And that’s the organization that was handed Apple Intelligence here. Go have fun, go do the hardest thing we’ve ever done. Build this thing that is going to just be a moonshot, and also make sure it never says anything racist, and it never generates any kitty porn. Other than that though, I’m sure you’ve got this. We’re just going to go make this video now and start printing the billboards. How do you think that went? Well, we see how it went.

Beyang Liu: One year ago – 2023, right? 2023, Copilot was king, they seemed unassailable… Everyone wanted autocomplete. No one even cared about chat, or context awareness in that chat, right? Because autocomplete was where it’s at. You want it to be fast, you want it to be snappy… You want it to be a little bit context aware, but people just wanted it to be fast, right? And that was the UX paradigm that was dominant at the time.

And then in 2024 the paradigm completely shifted. I think it first shifted with GPT-4, where - okay, that was a model that had a step function improvement in its ability to one-shot applications. So now it’s like, why would I sit there, autocompleting stuff, when I could literally just generate an entire mini app from scratch? It also got a lot better at incorporating context, so now you can do kind of context-constrained code generation, which we deployed, and it had massive success in the enterprise. But then there were still certain things that it couldn’t do well. The code was often sometimes broken, or didn’t quite compile.

And then when Sonnet rolled out, that was like another step functions. Now all of a sudden these things that were kind of just beyond the capability, are now firmly within – like, I can trust this thing to reliably emit JSON, for instance. That used to be – that’s a solved problem now. People used to write entire thought pieces around “How do you constrain the model output to produce a valid JSON?” These days you don’t even think about that, because the model has been trained to treat that as a solved problem. And I think now we’re seeing it in terms of in-editor agents. That is the future, and that’s what we’re building towards. A year ago, I think if you were pushing agents, there were certain companies that were like “We’re going to build the agent that eliminates the developer entirely.” I think now people recognize that they were kind of selling beyond their existing capabilities at the time. It made for a great kind of marketing moment, and they got their name in the headlines, but there was a disappointment in the actual product experience.

Now, with the newest set of models, we’re seeing this approach, just like – this is kind of the new paradigm. That’s what we’re building for. We have kind of like a wait list of people who want to get access to the thing that we’re currently building in collaboration with a lot of these frontier shops… And it works very well in large, messy codebases as well, because again, that’s the problem that we’re solving for.

And so I think the future is very bright, and I don’t – at some point I think we might plateau in terms of model capability, but at least for the past two years, there’s just been this regular cadence of step function improvements in model capabilities. It’s just been really exciting to see that, and sort of ride the wave of the development and maturation of this technology.

Thomas Paul Mann: Yeah. First of all, I get it. I mean, I think everybody is fatigued about AI, right? So this has been around now for one and a half years. Every week there is something new. It keeps getting better, and new stuff enabled, and whatever… Every company integrates it, every company talks about it… So I definitely get this. And I think it’s also – I personally wish this gets a bit less about AI, and more about what actually is possible, of what actually features people build… Where AI becomes just like the enabler, the technology that enables it, but you talk more about actually the innovations you do, and less about AI and model.

That being said, we recently added more of those models, because we’re in this really weird timing right now where it’s one of the only things I can remember from my life where it comes out and immediately everybody knows about all the details, is an expert in it, knows when to use which model, knows their preferred model whatsoever… And it’s like, it’s kind of hard to go against this flow, and so you’re completely neglecting it… Which is basically - we did our pivot there in a way; we first wanted to just support Open AI models, and said like “Those are the clear winners. We’re making it easy. We’re just going to have those models.” But then loud and clear, our community said, “Hey, hold on. Anthropic is actually really good for XYZ.” And then there is Perplexity that is really great for when you want to have quick answers around general knowledge… And it’s like “Oh, hold on. Yeah, this kind of makes sense.” And it’s not so black and white, the details in the devil. And so this is why we sort of added more of those LLMs to Raycast, and we really see that now as like Raycast AI, it’s sort of “This one interface for many different LLMs”, and you can pick and choose the ones that suit you personally the most, or suit the task at hand that you want to do the most.

[01:30:08.13] You maybe need an extremely fast LLM, which is like less capable, but it’s good enough for what you want to do, like fixing spelling of a sentence, or something. But maybe if you’re diving down into like a coding problem, you want to make sure that you have the best LLM, and it can reason about the problems you have… And it’s fine if it takes a bit longer, because you get more value out of it.

So that’s like sort of the conclusion we came to. Personally, I don’t think that’s sort of the end state. We’re already thinking about “Can we do something automatic, so that we pick the right model for your problem, and you don’t need to care about it?” But it’s more like sort of the implementation detail behind the scenes, like we pick one or the other, and make a good guess of what’s the right model for this. Because if I think about AI, I don’t think about picking a model, right? I just think about “There is like an intelligence that helps me doing something that I would need to do otherwise myself.” That’s really what it is about.

And then the other angle to it, which - now I want to talk more about the features. What Raycast is interesting – if you use Raycast, you do it with your keyboard, you insert the text, and then we sort of interpret this text. At the moment, this is very static. You search a command to send to your window, we send to your window. There is another command to send [unintelligible 01:31:28.02] left, to move it to the left. So it’s very statically-defined what you can do. But what the AI allows you to do is that this becomes more of a fluent thing; this becomes more of something – I can enter something “I want to do XYZ”, and then we essentially figure out what to do.

And the interesting bit here is when you think about the store and the extensions we chatted about, all of them are connected to different tools. So they’re connected to your issue tracker, to your wiki, to whatever you have… And so you can then start thinking about “Oh, this is quite interesting… So now I can connect things together that I would do otherwise.” And this gets much more around like what are things that you do on a daily basis, very often, that would be good to abstract away and make it quicker to do.

And so this is something which we’re thinking about, how can we get out of this very statically-defined feature set? “This is the, I don’t know, 1000 things you can do”, to like more “Hey, you can shape them up yourself by basically chatting or talking or inputting the text, what you want to do about this stuff.” And with that, all sorts of problems come… Which is like the fun problem. So it’s not straightforward… Otherwise, we would probably have built it by now. And it’s extremely hard to build something that is reliable and fast… Which basically Raycast stands for, right? We chatted all the way at the beginning about how to replace things like Spotlight - you need to be really fast, you need to be reliable, you need to be 10x better… And now you’re going always to the opposite direction, to like LLMs that hallucinate, they’re slow… How do you combine those two things to make a good product? And some of those things will hopefully be solved over time. Things just naturally get better and faster with those language models… But how can we actually solve the unique problems to our use case, and how can we make those really, really good for what we wanted to do?

Nathan Sobo: I don’t know. I don’t know that I fully even understand what it’s gonna take to get to Linux… But I think we can get there within low-single-digit months of a fraction of the team, and then we’re going to see what the ongoing maintenance cost of it is relative to its value.

In terms of the business model, what we’re focused on right now is adoption. So adding a second platform opens up a very large number of potential users who might be interested in it. So it serves that goal. And community development is another business goal we have right now.

In my mind, again, the nature of a company is – obviously, we do need to become profitable and have a plan for becoming profitable… But every venture capitalist knows how large the market is of developers, and how valuable that market is… And so right now I think we just need to stay focused on getting adoption. I’m happy to take people’s money, and one thing we’re thinking about is just like at least giving people a good out-of-the-box code gen experience to use LLMs. And that’s something we could offer like a trial for, for example, just so that people can see it. And then it’s like, you get to the end of the trial, or you get to the end of the fast usage, and your rate limit is constricted, and now you can like decide to go to Open AI and sign up, and get an API key, or bring your own local model… Or if you want to just give us your credit card, we’ll take your money there.

But it’s not really our key focus right now, is like generating a ton of revenue. I think the key focus is like “Let’s build the community and get a ton of users using this thing”, so that we can like respectfully offer those users things that integrate with their workflow, and make them more productive down the line. And I hope I don’t turn people off with that, that we are planning on eventually offering facilities in our flagship build… But hopefully it being open source gives people the reassurance that if we’re too annoying about that, you can always build it from source, or get it from somebody else. But I think we’re gonna be able, with the collabs stuff – like, we’ve been hanging out with members of the community. It’s been small, but we’re just in these channels, coding… Like, it’s happening right now. There’s a couple of people working on Vim, Conrad and a member of the community… And it’s like - yeah, it’s been so cool just to… Even watching members of the community that we’ve granted write access just pairing with each other and not even involving us.

So I think on that front, the AI front or some unknown front, there’ll be something that we can sell to developers. I was glad you mentioned that, because I was referencing our transcript, Jerod, where you mentioned… If you want to search this, it says “The collaboration part”, the social coding part. And Nathan, you responded by talking about how you’re not trying to compete with GitHub. I think the conversation was around how these channels and this collaboration might circumvent the need for a pull request, because there’s this real-time collaboration happening… And I think that’s really interesting, because that’s what we really gravitated towards the end of the conversation, was how interesting it could be to have these real-time collaborative coding sessions inside the editor. Can you talk more about - like, when you referenced this channel, what exactly is a channel? How do you get granted write access to things? What are some of these terminologies? If a listener is listening to this and they go pick up Zed, how do they interact with channels? What is that to an everyday user? What is that to you all and how you’ve been using channels?

Adam Stacoviak: Okay, let’s go then from if we both agree that network is definitely part of the gateway to homelabbing… You mentioned Plex and storage. Let’s talk storage. I’m a diehard – I think maybe our listenership might be tired of hearing me say ZFS… And I definitely think our Slack folks are like “Adam, just shut up already with the ZFS stuff. Why?!” And so we have a couple questions behind the scenes around ZFS, but let’s just talk about storage in general, and then specifically the file system. Because I’m a ZFS guy, I think you are too… I could be wrong. Maybe Btrfs if the use case permits… But how do you then think about storage? Okay, SSDs, we talked about that, NVMe’s being potentially more power-hungry in cases than a hard drive… I don’t personally mind hard drives. I think six gigabits per second is fast enough for me in most things I need to do. It’s definitely fast enough for Plex, so why would need to abandon the massive storage opportunity, and the literally decades of usability experience that hard drives provide? And I get to keep a bunch of money in my pocket. Because SSDs and NVMe’s can’t compare size-wise, but they do compare dollars-wise, and they’re very expensive. At four terabytes they’re extremely expensive per drive. And if you want to RAID anything, or have anything substantial, you’re talking like 16 terabytes, maybe 8 terabytes to 16 terabytes… That’s thousands of dollars on the low end for SSD or NVMe. Let’s talk storage.

Chris Benson: It did, actually. Your acceleration versus exploration analogy, that was for me personally - different people get different things - that really clarified for me where I might be using Copilot, or where I would go and use Codeium on that… Because I do struggle on the exploration side myself. It’s a lot easier on the acceleration at the end of the line [unintelligible 00:35:32.09] and crank through that fast, which I’ve been able to do with these other tools… But I have struggled on the exploration side… Because I kind of want to do a thing, and I’m kind of trying to figure it out, and I’m just going to kind of see where my fingers lead on that… And having that ability to support that in the way you described - that gave me a very clear understanding from my standpoint.

So I’d like to ask each of you where this is going, both in the large and in your specific concern, with Codeium. Things have never moved faster than they’re moving right now in terms of how fast these technologies are progressing… And Daniel and I have a habit - we were commenting on our last episode about this; we have a habit of saying “Yeah, we recently mentioned this thing, and that we’d get to it”, but then we turn around and we end up talking about that we just got there way faster than we ever anticipated.

With the speed of generative AI, and you’re already creating these amazing tools and stuff like that, and you’re having to stay out front, where is your brain taking you at night, when you hit when you stop and you chill out and have a glass of wine or whatever you do, and you’re kind of just pondering, “What does the future look like?” And I’d like to know both from your own specific personal standpoints in terms of your product, and that, but just the generative AI world in general - how do you see it going forward? I’d love your insights.

Gerhard Lazu: BBC was down, and the New York Times was down, and The Guardian was down… Changelog - it doesn’t matter. It’s okay. All the other big news companies are down. Anyways, the point was, coming back, that with Apps v2, if the host is unavailable, the app cannot be scheduled somewhere else. So we have to have more than one. We can’t have just one. With nomad, with Apps v2, let’s say the host was down, the same app could be scheduled elsewhere. Basically, the apps could move around the platform. In this case, in Apps v2, they’re pinned to physical hosts.

So even though they’re faster, they’re better, they’re more self-contained, like when one thing fails, it doesn’t affect – it’s a lot more resilient; the platform as a whole is a lot more resilient. But that means that you have to design with this in mind, right? …with blast radiuses, and when one thing goes down, how do you basically work with that, with partial unavailability? And it makes sense, but it means we need clustering.

So moving something like for example Dagger Engine, it’s okay. Or Docker. Because if that’s down, that’s okay; it can fall back to whatever is local. And by the way, we do that in our pipeline. If PostgreSQL is down - well, you’re already clustering that. You know, we have, again, some sort of redundancy there. In our case, we had one primary and one replica. And by the way, I think we should look into that as well, to see if we can get a proper, managed PostgreSQL service. We keep talking about that. Maybe Crunchy, maybe Supabase, try a few and see what sticks.

[54:12] To continue, we can still run on Fly for the PostgreSQL instance, even though I think they were mentioning at some point they will want to invest in that… So we’ll see where that goes. Things may have changed; again, this was on their forum.

So we can move Dagger Engine, Docker, we can move PostgreSQL to Apps v2, to machines, but the app itself, it’s a bit more problematic. Not without the clustering part, because of what I explained, like the limitation with hosts. So while it’s a modern platform, it’s very performant - again, all the tests which are ran, you get like very nice CPUs, the AMD [unintelligible 00:54:43.23] they’re yours, especially if you get like the performance instances… You get local NVMes, again, very fast… But if the host becomes unavailable, it won’t get moved.

Adam Stacoviak: Yeah. Do you mind if we dig deep a little bit on the hardware side? I’m just curious how did you come to play with the actual hardware? Did you actually – were you in the data center? Did you rack and stack - not so much like service to demand, but how did you… Were you in some sort of like workshop and you just had a couple super-fast NICs directly attached to a CPU? Give me an example of you playing with the hardware to push the hardware as fast as it can for the software’s sake.

Daniel Whitenack: I loved so much about this conversation, and one of the things that I was thinking about in my own context is like my own tendency to not give users enough credit. So one of the things that happens when we anthropomorphize AI, and talk about it in these different ways - you know, there’s a tendency to maybe think it’s always right, or like you’re talking about more intelligence than it really does have… But I’ve also found, whether it’s like family members in my own life, who aren’t involved in the AI world, and they’re using ChatGPT, a lot of times they interact with it more responsibly, I feel, than some colleagues in the AI world, in the sense that… My brother in law, Jack - I don’t know if you’re listening; hey, out there… We were talking last night over tacos, and he had used ChatGPT to write up some speech or something that he was giving at work… And I’m like “Oh, so you wrote that with ChatGPT.” And he’s like “Yeah, I use it, but what I do is I don’t like just have it generate it for me… I’ll just type as fast as I can and just have it rephrase it into something good, that’s grammatically correct.” And I’m like “Wow, that’s – yeah, go for it. That’s really good. That’s awesome”, because that’s a great way… Or I’m thinking of teams that we work with in India, in my day job, I was talking to someone and some people would say, “Oh, we can’t just output machine translations, because they won’t post-edit them, and make them good, or like look for corrections.” And in fact, translation teams we’re working with in India - they know it’s a machine translation; they’re just happy they don’t have to type as much, because typing is really difficult in their language. Like, they’re fine to post-edit it.

So yeah, I’m wondering if you’ve seen this as well, and if you have any recommendations, specifically after working with users in conversational interfaces, which can seem kind of like human-like. It’s like you’re having a conversation. How do you set up an interface? How do you set up a system such that it produces useful behavior, and like promotes the right type of usage?

Johnny Boursiquot: I just snuck Go into every organization I could find, wherever I went to work… I just snuck it in, and I’d usually do it with like a command line tool. That was my beachhead, basically - just build a CLI tool, and then deliberately have another developer on the team extend it, say like “Oh, you wanna add support for that?” “Yeah, just go in the repo check it out, and if you have any questions, let me know.” They go into it and be like “This is in Go?” “Yeah, it’ll be fine. It’ll be fine. Just check it out, and if you don’t have Go, just download it here. It’s super, super-simple.” And they’d kind of give me the side-eye and be a little skeptic, but “Oh, it’ll be fine. It’ll be fine. Do you want me to come pair with you? Let’s just do it.” And we’d sit down, and all of a sudden you’d see all of the hesitation start to dissipate a little bit, because they’re like “Okay, this is kind of nice. I don’t need any super-fancy things, or anything heavy… Oh my God, it compiles so fast! It’s almost like I’m scripting.” I’m like, “Yeah! That’s awesome, isn’t it?” And next thing you know, we’d open up a PR, and boom. And that was it.

One at a time, I’d just be converting people – obviously, not every company was appreciative of how I was converting everybody into using a non-sanctioned language… But eventually, folks started to see the value. Because beyond the CLIs, what typically would happen, there’d be one developer - not me; at that point I’d be removing myself from the equation and letting people just run with it and see where they go with it… And somebody would suggest, “Hey, how about we write this API, this REST service - how about we do that in Go? Because I heard it’s pretty fast, pretty good at that stuff. And there’s libraries we can use already… Can we just do one of those things?” And then with some reluctance manager or technical lead would be like, “Okay, fine.” And then we’d try it and it would be so fast compared to other things, which I will not name, because that’s not the point… But it’d be so much faster than what they typically would be using… And then that’s really how that whole transition would start to happen. People would be like, “Oh, I’m more productive. This is a safe language to use; it’s gonna catch things that normally I’d go find out about at runtime.” The process for getting this work done, even when novice developers who are actually adapting with concurrency stuff and they wanted to use goroutines and everything else - with a little bit of guidance, they were so productive.

At that point, once I’ve planted that seed, I’d just step back and watch it grow. Because Go really just speaks for itself. It’s that good of a language.

Dave Farley: Yes. And there are key stages that I would a system of any complexity would probably want to parallelize and grow, to get fast feedback… What people took from the idea of continuous delivery was – when people think about deployment pipelines, I think what most people probably interpret that to mean is basically a build script that can deploy stuff at the end. And it’s much more than that. There’s more to the model than that, in my mind. This is one of the things that I can be definite about; I’m usually not definite about things, but in this case I can be, because I invented the term deployment pipeline, so I can be definitive about what I meant when I said it. A deployment pipeline goes from commit to releasable outcome. That’s its job.

If at the end of a deployment pipeline you’ve got more work to do, it’s not finished. It’s not a deployment pipeline. The objective of a deployment pipeline is go commit to a releasable outcome. It doesn’t mean you have to necessarily push the thing into production. That depends on the business, whether that makes sense or not. It makes sense to go frequently, but you don’t have to… But working so your software is always in a releasable state is the way that I tend to describe continuous delivery; the deployment pipeline is the thing that determines releasability.

So that’s what we’re trying to get to… And if you’re thinking about that - so what does that then take? Well, it depends on your system. But at a minimum, you want to know that the software works, it does what you think it does as a developer, and is deployable and does what the users want. As an absolute minimum, you must want to answer those questions in some way before you deploy it to production. So that’s my minimum starting point. That’s where I would start my template from. And then you could optionally plug in bits that would do performance testing, host where you put your performance testing.

So part of this is really to address the problem of how do you get organizations to start buying into this, and what you wanna do is that you wanna make it really easy to do the right things, or what you think are the right things, and possible to do other things. That’s my approach. So I would like it to be absolutely trivially simple that if you are willing to accept some small constraints on the way in which you organize your code, then I will be able to build it for you, deploy it for you, run all of the unit tests, because you’ve put them in the right place. And then once I’ve deployed it, I’ll be able to run all of the acceptance tests, because you’ve put them in a different place. And if all of those tests pass, I’m gonna give you something that you could deploy into production. And that’s pretty trivial and doesn’t really constrain you very much. All you’re asking is “Tell us what you wanna build.” You know, plug your build script in here, that’s fine, build the pieces that you want, but tell us where the tests are, and we’ll report them to you.

And now, as a developer, I’m gonna press the button, get my template out, start building my project against that template, and my deployment pipeline just starts functioning. Instead, at the moment, with all of the technologies that I’ve tried so far, I pretty much have to go through that exercise every time to set something up.

Dave Farley: Yes. And there are key stages that I would a system of any complexity would probably want to parallelize and grow, to get fast feedback… What people took from the idea of continuous delivery was – when people think about deployment pipelines, I think what most people probably interpret that to mean is basically a build script that can deploy stuff at the end. And it’s much more than that. There’s more to the model than that, in my mind. This is one of the things that I can be definite about; I’m usually not definite about things, but in this case I can be, because I invented the term deployment pipeline, so I can be definitive about what I meant when I said it. A deployment pipeline goes from commit to releasable outcome. That’s its job.

If at the end of a deployment pipeline you’ve got more work to do, it’s not finished. It’s not a deployment pipeline. The objective of a deployment pipeline is go commit to a releasable outcome. It doesn’t mean you have to necessarily push the thing into production. That depends on the business, whether that makes sense or not. It makes sense to go frequently, but you don’t have to… But working so your software is always in a releasable state is the way that I tend to describe continuous delivery; the deployment pipeline is the thing that determines releasability.

So that’s what we’re trying to get to… And if you’re thinking about that - so what does that then take? Well, it depends on your system. But at a minimum, you want to know that the software works, it does what you think it does as a developer, and is deployable and does what the users want. As an absolute minimum, you must want to answer those questions in some way before you deploy it to production. So that’s my minimum starting point. That’s where I would start my template from. And then you could optionally plug in bits that would do performance testing, host where you put your performance testing.

So part of this is really to address the problem of how do you get organizations to start buying into this, and what you wanna do is that you wanna make it really easy to do the right things, or what you think are the right things, and possible to do other things. That’s my approach. So I would like it to be absolutely trivially simple that if you are willing to accept some small constraints on the way in which you organize your code, then I will be able to build it for you, deploy it for you, run all of the unit tests, because you’ve put them in the right place. And then once I’ve deployed it, I’ll be able to run all of the acceptance tests, because you’ve put them in a different place. And if all of those tests pass, I’m gonna give you something that you could deploy into production. And that’s pretty trivial and doesn’t really constrain you very much. All you’re asking is “Tell us what you wanna build.” You know, plug your build script in here, that’s fine, build the pieces that you want, but tell us where the tests are, and we’ll report them to you.

And now, as a developer, I’m gonna press the button, get my template out, start building my project against that template, and my deployment pipeline just starts functioning. Instead, at the moment, with all of the technologies that I’ve tried so far, I pretty much have to go through that exercise every time to set something up.

Jerod Santo: Yeah, there’s an interesting debate or spectrum that people talk about with regard to what they call developer ergonomics versus user experience, or thinking about the developer first or end user first… And there’s a lot of push and pull. And I will admit, there’s definitely some trade-offs there, of like “Who am I optimizing this for? Is it for the developer to move fast and be happy, and all these things?” which is really at the essence of Ruby, was the developer happiness, from the very beginning, that Matt started, and Rails, of course, was all about productivity from the very start… But then also thinking about the user first and putting their priorities first over the developer’s.

And while I do see a tension there at times, where like if you’re merely thinking about yourself as a developer and you aren’t thinking as much about the user, you can sacrifice them for yourself, for example, shipping them a whole bunch of JavaScript, because it’s just easier to pull in one more library than it is to maybe write 3-4 functions yourself that are difficult to write… Or whatever it is; this is just for one example. But there’s no doubt that, to a certain degree, developer happiness and ergonomics and productivity produces user experience, produces features… Because like you said, speed is important, in both contexts - both the speed of the application, but also the speed of how fast you can put new ideas into the world really does matter.

[12:21] And a lot of these things don’t go from “Well, I can do it as a developer, but I’m not happy” to “I can do it happily.” It’s like the difference between “I can accomplish this” or “I cannot accomplish this.” At the bottom line, that affects your end users more than anything else… Like, “Well, I don’t have the skills to build this particular thing; I’m not gonna be able to do it” versus “I can sacrifice a little bit here and pull it in.” So… Definitely trade-offs to be made.

Maxime Vaillancourt: I think one of the main things I keep in mind in this is I’ve read so many articles and blog posts and opinions everywhere on the internet over the years that say “Don’t do rewrites.” That’s like the main takeaway to remember for all of those articles, and I want to be the person who does the opposite and says “Rewrites are possible. You can do rewrites if you do them right. How do you do them right? There’s many key things involved in there.” It’s not a thing where you have to push the rewrite option aside if it’s something that you don’t think is possible.

[55:47] The main thing, of course, I think is communicating early and often with the people that are involved into that process… Of course, in the example of Shopify developers it’s getting them aware that there’s going to be this new application that’s coming out, that you have to think about in terms of when your features and your roadmaps and everything have to be aware of that new application… And one mistake I did myself was trying to send an email at some point to say “Hey, this is the new implementation of how storefronts work.” One email is not gonna cut it. You have to be frequently getting in touch with people, and making sure that they’re aware.

Eventually, the word gets on, people get excited about the thing, and that’s when you kind of get this excitement going on for that new implementation, along with making sure that you have the most frictionless process to work on that new thing. When you get those two things combined, that’s where magic happens, and people want to work on the thing, but people also realize that it’s easier, it’s more fun to work on the new thing… So it becomes a self-realizing prophecy where you want it to happen, but people kind of make it happen for you… And that happens through communication, I think. So that’s one thing.

Of course, in terms of how people using Shopify benefit from this, we’re seeing some great results in terms of performance. On average, overall traffic coming up on the platform, we’re seeing around 3x-5x performance improvements for storefront response times on cache misses. Of course, we’re focusing on cache misses because cache hits are almost always fast; but whenever there is a cache miss, that’s what we want to optimize and make sure is always fast. So that was kind of the first rule, I guess, of the project, to say “Don’t really think about caching, because we want to first have very, very fast cache misses. And only when we know that we have some very fast cache misses do we want to start thinking about caching on top of that.”

So we don’t want to cheat away the cache misses by saying “Oh, it’s not a problem, because we just add caching onto there.” Sure, but what happens when you don’t have a cache hit? That’s when we want to be extra-fast. And in this case, we’re seeing some good performance there.

Some storefronts kind of surprised us in terms of how they performed, where we were seeing up to 10 times faster cache misses. So that’s something we were very surprised to see in the early process, and we kind of knew that this was the right way to go, because we were seeing those good results.

Kevin Ball: Yeah, so the thing I wanted to talk about was there’s been a resurgence of interest and focus on JavaScript performance, and in particular JavaScript load and parse performance. We had all this stuff about, okay, is React making it faster to update the DOM? Or how fast are these things to do a lot of updates? But we’ve also gotten into this world where everybody’s just adding more and more JavaScript, and there hasn’t been as much attention on what the impacts of load and parse time are… So we’re coming back around. That used to be a huge issue, then people forgot about it…

Coming back around to it, I’ve seen a ton of articles in the last few weeks looking at this. I think the one that sparked it was Addy Osmani from Google did an article on the cost of JavaScript in 2018 that blew up, and he sort of talked a lot about how expensive it is, particularly on less than cutting edge devices. Then there’s been lots of follow-ons - how do you do this? Is code-splitting good enough? What sort of other things…?

Another article I saw on this that I thought was really interesting was looking at the impact of the push to make everything HTTPS, and the fact that that essentially kills your ability to create local caching servers, because local caching servers are essentially the man in the middle. So it’s better for security, but this article was highlighting – he did something in rural Uganda, and their connection to the internet is a satellite internet access, so there’s a ping latency of half a second, and lots and lots of draft packets, so not being able to have a local caching server essentially kills their ability to access the internet for a very large number of things.

There are pros and cons to this, but it got me thinking a lot about the people who are not in the first world. This has come up before on the podcast; this last week I was in Costa Rica; T-Mobile lets you access data for free if you’re on one of their main plans, from like 100 countries, but the speed of access in Costa Rica is like 2G. So I’m on a fast phone, I’m on an iPhone, but I had 2G internet, and it was amazing how slow things were… Just appallingly bad, and it reminded me how much you get used to bandwidth feeling essentially free; things are so fast…

So this resparking of the interest in – you know, we actually need to cut down, we need to have a JavaScript budget, we need to think about the impact of all of these millions of libraries we’re pulling in… Code-splitting is a nice thing and our tooling is improving for that, but having all of these things front of mind when we’re developing, if we’re developing things that are not just for folks who are in countries with ridiculously fast internet access… Which the U.S., even though – well, actually I don’t know about the rural parts of the U.S. Certainly in California, even with just mobile access, it’s ridiculously fast. 4G LTE is wicked fast… But not everybody has that.

Kent C. Dodds: [19:52] That’s an interesting question… I guess I don’t really see them as separate. I feel like my goal in my open source projects is first and foremost to solve the pain that I’m feeling, and then secondly to – like, if I can take that solution and make it generally applicable, I can save hundreds or thousands or tens of thousands of hours of developer time… And that’s pretty cool, that’s a really awesome feeling. So if I’m going to do that though, I have enough open source projects now to realize that I can’t spread myself too thin on these, or I’m not gonna be having any more fun; it’s just not fun anymore.

I see building a community around projects as an essential part of maintaining projects. The only way to do that effectively is to have a good code of conduct that’s enforced. I’ve, luckily, never had to enforce my code of conduct, but I have one and it’s very clear that there is one. I have very good contributing guidelines. Sometimes I’ll even have a video that demonstrates how the code is set up.

Often, my projects are fairly small, and so they should be pretty straightforward. I also do a lot of things to encourage people to contribute themselves. If somebody files an issue, it used to be that I would be like, “Sweet. Time me, I’ll show you how fast I can fix this problem.” I remember saying, “I’ll have this released in five minutes” and it was nine minutes, and they were like “Oh my gosh, that’s amazing!” and I used to feel so cool about that. But that’s just a recipe for disaster. What you wanna do instead is invite the person who filed the issue to make a pull request to do it, and more often than not – well, maybe not more often than not, but pretty often I’ll have people say, “Oh, I just remembered this is open source. Yeah, I’ll do that.”

Even if it means guiding them - sure, it takes you more time to guide somebody to figure out how to do something, but what you have at the end of it is another person who’s familiar with the code who’s interested and invested.

There are a lot of things that you can do to increase people’s investment in your open source projects, and the more invested you have other people in your project, the more likely you will be able to live your life of leisure and let other people manage your project… Steps in automation and that kind of thing as well, which has also been a really valuable thing for me. I have a generator that will automatically generate all the files I need for my projects, that are really common for most of my projects. That automatically creates the code of conducts, creates the contributing guidelines that are really nicely spelled out, and especially helpful for beginners… Then I have this automated released for all of my libraries, so I can actually merge a pull request and it gets released when I’m on my phone. That’s pretty awesome.

So being a good maintainer of a project, in my mind, is not separate from being a really cordial and friendly person, because your effort to build a community will improve the maintenance of your project in the long run anyway.