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.

Liz Rice: [58:13] Yeah. And then on the security side - so Falco was probably the first security project, certainly in the CNCF, that was using eBPF. This project from my former colleagues at Aqua called Tracy… And then in Cilium we have a sort of Cilian family, we have a sub project called Tetragon, which is allowing you to create low-level security primitives almost in Yaml form, and apply them to your Kubernetes cluster. And you can do really cool things with Tetragon. I get a bit overexcited about this, because if your kernel is modern enough, you can not just detect that something is potentially malicious behavior, a process is opening the wrong file, or connecting to a cryptocurrency miner, or whatever malicious thing that you’ve detected - you can kill that process synchronously from within the kernel. And what that means is the process gets killed - to me it’s not like you have to go and tell somebody and then eventually your process gets killed… It’s happening right there and then, and it stops the attack before it happens… Which is super-fun to demo. I love it.

Joshua Meier: So the trends happening right now are really exciting. You called out a couple of them right now, graph neural networks, figuring out ways to train large language models, and then use them effectively with things like prompting. We do a lot of work in those areas as well, and thinking about how to apply those to biology. One of the things that we’ve realized though is that a lot of the work happening in the field right now, like AI for biology, when you test it in the lab, it actually just doesn’t work as well as you’d expect. And that’s because the computational metrics that are available today are kind of flawed. You don’t have access to the right training data, you also don’t have access to actually test things in the lab… And I’m very familiar with this.

Before Absci I was working at Facebook, Facebook AI research. And there was an awesome team of AI researchers there. We wrote a series of really exciting papers, but we were never able to actually take sequences that we would, let’s say, design with the models and test them in the lab. So we were fundamentally limited to just showing how our models would perform on datasets that we would just mine from previous publications. And when you start to take some of those methods and actually apply them in the lab, you start to really understand where the shortcomings are and identify areas for improvement.

So there’s a lot of very rich AI research happening at Absci right now, because we are really able to understand what is the surface level of the problem, where are the opportunities, and really do some cutting-edge AI work there as well. So it’s really inspiring a lot of the best AI researchers to come and talk to us, because we have this knowledge of what the right problems are, and we’ve got this extra dimension of what training data is useful, what’s the right way to validate your model… So it really makes it a thrilling place to do AI research.

And we actually just opened up our new Absci AI Research Lab. We’re calling it the AAIR Lab, in New York city, and hiring a ton of people over there… So bringing on some of the brightest AI researchers in the space and really creating an awesome environment to really make AI and drug discovery, some of the most exciting technologies of the decade.

Amal Hussein: Yeah. Well, I would say you’re definitely really good at hot takes. You’re also really great at – I feel like when there’s gasoline all over the floor, you’re really great at showing up with a match on Twitter, and then dropping the match… And it’s like BOOM! [laughter] There goes Twitter for today, you know…? Literally, three weeks later I’m still getting likes and mentiones on threads where Rich inserts himself into sharing a very reasonable opinion about JavaScript. For what it’s worth, I agree with you 99% – actually, 100% of the time, if I’m honest. But yeah, seriously, you’re awesome.

So kind of just to continue our hot topics… So React - I’ve been using the library forever; really, it helped me even be better at JavaScript. It helped really democratize the component model that we were kind of skirting around for a very long time as a community. So I’m very thankful for the way it’s helped push certain things forward. However, I think there’s certain things around performance and other things where I feel like maybe React has kind of stagnated. And for me, I think a product of its success in many ways, React is a product that really supports a wide variety of applications and platforms. And this reconciliation algorithm, and this virtual DOM, and the synthetic events, and all these things that are kind of like extraneous and not necessarily found in other projects on the web… You can look at Preact, Svelte - y’all don’t need a virtual DOM, y’all don’t need synthetic events… Extremely performant, much smaller bundler size… But the constraint that React has is we output to many DOM trees; or not DOM trees, but platformy trees… iOS and Android being the other two major platforms. So it’s got some bloat because of that.

[47:48] A friendly argument that I was having with a friend of mine a few weeks ago was like “Okay, is it safe to say at that point that maybe React is not the best choice if you’re writing for just the web?” We agreed, and he was like “Yes. If you’re just writing for the web, React is not the best choice.” Because I was just trying to say, I don’t think React is – like, if I was starting a project in 2021 (or 2022 now almost) for the web, I wouldn’t pick React. I wouldn’t. Just because it’s bulky. I would try to pick something that’s really gonna force me to use as little JavaScript as possible. And React is more than I need, it’s more engine than I need, if I’m just writing for the web. So I’m just curious, do you feel like Svelte is – like, how is Svelte tackling this problem? Because I feel like for me Svelte feels very web-first, web-only right now. Is there a mobile story? Have you tackled those constraints around multi-platform? Because if I’m working at a company and I’m trying to get my manager to adopt Svelte, my manager is gonna say “Well, is there a native library? How does that work? I don’t wanna have to hire folks to write Swift and Kotlin, or whatever.”

Cyrille Le Clerc: Thank you. The most important takeaway for me is the importance of the open source and standard nature of OpenTelemetry to succeed, to observe CI/CD pipelines, both to succeed in instrumenting these very rich communities of tools involved in the CD processes, and also communities that will consume all the observability data we produce, which are not only CI administrators, but as we have said, also developers for their pipelines, people doing cost accounting, people doing reporting on the delivery process… And CI/CD data are gold mines that we succeed in exposing thanks to the popularity of this open source standard which is OpenTelemetry.

Matt E. Patterson: Sure. Let me start with a kind of anecdote and an analogy. A couple years ago I was having beers with a friend of mine who’s a really excellent Rails developer, as well as a really excellent Ember developer… And he had been spending most of his career recently working in both, with Rails as his API and Ember as his frontend. And we were just talking about this sort of topic, the future of what the web is gonna look like… And I posited - because I spent a couple of years in the video game industry - that if you look at game companies that are doubling down now on this notion of a sort of thin terminal streaming future… And say whatever you will about Cyberpunk’s issues, the fact that it actually runs reasonably well on Stadia is nothing short of astounding. The game industry would much rather push towards that than asking everyone to buy an $800 monstrous gaming rig in a tiny box that you put in your living room.

So I posited with my friend, “Well, wouldn’t web apps ultimately go the same route as broadband penetration increases across the country and the world?” Wouldn’t the right approach be to ultimately get to where if I’m a business that’s serving you a website, I’m paying for all the cost of serving you that site. I’m not without your consent jamming megs and megs of JavaScript onto your device and asking your device to give up 60% of its computing power in order to look at my website.

So at what point do we say “Hey, you know what - there’s a way that we can give users on this sort of thin terminal approach just as rich of an experience, but everything is constantly just being pushed to them, streamed to them (if you wanna use the video game approach) from the server side.” So he thought, “Yeah, that’s an interesting idea” and we kind of dropped it at that.

[16:07] Fast-forward a few years and I discovered Stimulus Reflex, and of course, that kind of was born out of Chris McCord’s LiveView over the Phoenix framework, and I thought “Gosh, this is kind of that.” So to your actual question, the general approach, and whether you’re really using WebSockets or Basecamp’s new Hotwire library can even fall back to just using Ajax to essentially accomplish the same thing… But the idea is that rather than have a server that’s presenting an API of raw data - your list of users from the database, or your list of widgets - instead, just like in the old days of a server-rendered app where you would push a whole HTML page to the frontend on every click, every action, every page change, instead what we’re gonna do is we’re gonna send you the full page to start, and then any action that you take, just like if you’re in an Ember or an Angular app, we’re gonna have a seamless interface, because what we’re actually doing under the hood is sending that request down a WebSocket and telling the backend, “Okay, this is what the user wanted to change.” But unlike the HTML request/response cycle, all we’re really doing is telling the backend to do this. So it changes the database, it changes state, whatever.

And then it on its own terms, because you have an open, full duplex socket connection, can then just tell your client “Hey, I need you to change this chunk of the DOM.” The silly example is you create a button and a little counter, and when you click that button, it just tells the DOM to replace that number with another number. But the point there is that the backend knows what number it just told the DOM to change to. It’s not a “the frontend has a data store, the backend has a data store, and gosh, we hope that they’re in sync”, which is where a lot of the complexity comes in. It’s not that it’s an impossible problem to keep those in sync, but the complexity of what happens when the backend just flakes out on what the user just told it to do from the frontend… So now you’ve already updated the frontend to make it look really slick and fast, but now the backend didn’t actually do the thing, so then the frontend has to have some code to then figure out how to roll back the visual change it just made…

Karolina Szczur: Calibre is actually kind of like an after-hours project of mine; it’s actually a company founded by my partner, and I just end up helping out a fair bit, because I’m really passionate about it. So I don’t actually work full-time on it, but it’s something that I’m really passionate about; I love performance, and I love advocating for [unintelligible 01:09:27.10] so it really aligns with my values, so to say.

And surprisingly enough, you mentioned that everyone cares about performance - I can guarantee that that is not true… Because if that was true, we would be really rich, but we aren’t. Yeah, I think it’s really surprising, because you would assume that everyone in the tech industry should care about web performance - JavaScript performance, front-end performance, back-end performance - but it’s actually something that is oddly still not very popular, so to say.

It’s very hard to convince people to make a case for it, to make a business case to even sign up for a product that’s a performance monitoring tool, which Calibre is, which we find quite astounding, so to say, because again, you should feel for your users, you should really care about them, and that’s a massive part of it.

I think a lot of people focus on the user experience part and on the business metrics - sales, conversions and so forth - but they fail to recognize that assigning 2 megs of JavaScript might not be optimal, and might actually prevent people from using your product on a worse device than an iPhone 6… Which is probably your phone, because we are all developers and we all have money for a $1,000 phone or a $2,000 laptop. So I really like to advocate for stepping out of the bubble - the bubble of developers and designers and people who are working in the industry who are usually well paid and can afford those high-end devices, and to actually try to experience the web as it is, elsewhere.

For example in Australia the internet is fairly slow. The latency is absolutely horrifying, and you would be surprised, because Australia is a highly-developed country, one of the most livable cities in the world are here, Sydney and Melbourne, but still we have bad internet. So you kind of take those things for granted and you don’t care about performance, but you really should be doing that.

So I guess long way around what you just said, I wish more people would care about performance, but they really don’t, and we really have to do a lot of advocating and writing articles explaining why this is important and why we should care about it. That’s not really business-oriented, but just kind of a part of trying to include everyone into the community of internet users.

Dustin Kirkland: Well, so they are working hard on the underlying system call that it depends on. It needs to be able to allocate a TTY, basically, it’s just part of the underlying terminal technology, but it’s one of the top bugs, top priority bugs that the kernel team is working on right now. So it doesn’t yet work, but it is absolutely on the roadmap and certainly planned. It’s one of the most asked for features missing right now. So yeah, Byobu is a passion of mine. I am surprised and delighted that you asked about it, actually. It’s kind of a part time project, it’s certainly not part of my day job, and for the most part it’s implemented technologies; it’s really just bug fixes I work on now. But Byobu started out as a better version of Screen - if you are familiar with Screen. Screen is a beautiful program, but it’s kind of old and a little bit neglected, and then eventually tmux came along to be a better implementation of Screen. On top of both of those, I created this project called Byobu, which ships a set of opinionated configuration defaults and key bindings that turns either old school screen or the much newer tmux into a really rich command line windowing environment, essentially. It’s all command line, but it has a number of advantages. You can run commands and then detach and come back later, which is really important when you’re doing some work in the cloud and maybe you’re on a low connection or your connection drops, but you wanna make sure your long running command continues, or maybe you wanna kick off this job and then drive home and come back and check on it later. So that’s all very natively baked in, as well as the ability to split the screen - horizontal, vertical split, chop it up, run multiple windows… Sharing the sessions - that’s actually really useful. We use it for pair programming across the world. I mentioned that Canonical is very widely distributed around the world. It’s a very common mean for us to share a screen, so we’ll have an instance running somewhere in Amazon or Azure or open stack, and then we’ll run SSH import ID and we’ll give someone’s GitHub or Launchpad user ID, we’ll pull down their SSH key and then that person can SSH into that system and then with Byobu, we are both looking at the exact same terminal. [40:09] We are both typing and we can see what the other is doing. It’s great sharing a screen, at much higher resolution than say Skype of Google Hangouts screen share. You are literally in the same session.

Liz Rice: Yeah! And then looking at what’s inside the /proc directory as well, it’s a gold mine of crazy interesting things that the kernel is doing, and… Yeah, I think there’s all sorts of fun things in there.

Mikeal Rogers: Cool! Awesome! Mine is a website, it’s called GitHub. It’s really cool, there’s projects… No, I’m kidding. My pick is not GitHub. My pick is really self-promotional this week… Request For Commits is another podcast that I do on the Changelog network with Nadia Eghbal, where we dive really deep into open source. You can check out season one. We record them in seasons, so that we can kind of really think about who to talk to and what we’re gonna think about in terms of themes for the whole season. But we have recorded some more episodes, and they will be coming soon to the Changelog feed - to the master feed and to the RFC feed.

But in the meantime, you can go and check out the old episodes, because they are all very timeless there. There is no news in them, it’s all – we talked to a lot of people about projects that have been around for like ten years. If you’re really interested in web stuff, I highly recommend the one with Brendan Eich, where we get into the history of the web and how browsers have been funded and sustained over time. So check that out - changelog.com/rfc.

That’s our show! Thanks everybody for showing up. Rate us on iTunes, do all kinds of things to promote us; tell your friends, tell your mother… Even is she doesn’t write JavaScript, she can learn… That’s it. Bye!