Daniel Whitenack: One thing that was kind of brought up in the midst of this talk of the Trump administration and AI is this sort of AI and China discussion, where there’s a thought AI is kind of thriving in China, and maybe China is pulling ahead in AI… I know we’ve talked about this on the show before. There’s kind of this discussion of China and AI every time policy decisions are discussed on this show, and kind of factors in… And one of those things that I think is relevant is just the dominance of Qwen-based models in recent times. So if people aren’t aware, one of the things that I think is interesting to follow recently is Alibaba’s Qwen family of models. That’s spelled Q-W-E-N, Qwen. The latest of these is the Qwen 2.5 model family. And generally, these Qwen 2.5 models are quite impressive. They generally top the open LLM leaderboards in various categories. You’ll see them in the top spots.

So obviously, these are Chinese models, that is they’re models being built by a Chinese company, Alibaba. The CEO of Hugging Face, Clem, is quoted in one article I was reading of “Qwen 72B is the king, and Chinese models are dominating.” That’s a pretty clear statement. That was earlier in the summer, but I think we’ve seen continued domination of these models.

Any interesting takes on that, Chris, in terms of how you’ve seen the model landscape shift from closed model providers, to open, to maybe more geographically diverse, and certainly China being within that?

Jerod Santo: I’m curious how to short the commercial real estate market.

Jerod Santo: [04:11] The big difference now from the previous Apple News… “Long story short, I used to…” [laughter] I like how you like to give the long story, and then you give the TL;DR.

Anima Anandkumar: Thank you, Chris. I think I’ve had amazing mentors and amazing support as well from the community to enable that. At Amazon that’s what I’ve found. I learned a lot in terms of “How do we think about the customer? What are the needs? How do we have this short timeline to the product, but still make the customer happy? What would the requirements be?” And PR FAQ, which is the press release with the FAQ is how we first think about the product. That’s to me so non-traditional… But again, I like that… [laughs]

So that was an amazing and a very busy time there. I launched the topic detection algorithm that I described earlier to categorize documents, that’s running today in the AWS cloud, in the Comprehend service.

Angelica Hill: Yeah, I feel like I was running around like a headless chicken. I would say, this is not just representative of GopherCon. I just tend to live my life a little bit like that. But in terms of GopherCon - yeah, I mean, so as you know, I helped organize a lot of it. I also felt a very deep need to check in with some of our first-time speakers, and those who had expressed they were like nervous about their talks… As well as the fact that I had to make sure I was on point for Kaylyn and me doing lightning talks. So I wrote a very exorbitant list of like names of people, short descriptions, fun facts.

I’m trying to think through how to combat this next year, but I feel like at GopherCon I feel such a need to make sure there is never anyone who is like left in a corner, chilling, who can’t engage… So I kind of take it upon myself to buzz around, and if I see anyone who looks like they’re on their own, on their laptop… But not deeply engaged in their laptop, because they might be working, but kind of you can see them like looking up and being like “What’s going on?” I’m like “Hello! I’m Angelica. Are you excited? How are you?”

Josh Goldberg: Yeah. I think long-term it might simplify things, but short term it’s definitely not going to completely overhaul how we’re doing everything.

Marcos Nils: To me, the serverless story is very appealing. Today, I don’t see a strong use case to move everything to serverless, because I currently see that there are some things which are not yet solved. The compute thing is still a problem. The statefulness of serverless still has some quirks on it. For example, if you need to have like a persistent database connection, that’s something that you cannot do, because they could eventually scale to zero. Since I’m not working on very sensitive systems, I don’t care that much about cold starts, so to me that’s not a problem, but I know that some people complain about that. So even though I agree that I would do a lot of things in serverless, I don’t think we are right on the spot to basically fully translate to that. But I do believe is going to be disruptive in a very short time, about how people think about shipping and building and packaging apps. And it makes a lot of sense to start thinking of apps as a combination of Lambda expressions, of like basically different sets of logic that get connected to each other, instead of like a shippable binary that you build into a thing, and then have to deploy.

Gerhard Lazu: So what that means is that cert-manager today manages our certificates, and then we have to upload them to Fastly, even though cert-manager manages them, because there is no integration currently that cert-manager has with Fastly, and it can’t automatically upload them there.

So our source of truth today for the certificates is Kubernetes, we store them as secrets, and then from there, we sync them to other places. Today it’s just Fastly. But if, for example - and this is happening right now, we’re migrating to Fly… If we want to use the same certificates, then we would need to sync to Fly.io as well, because it’s almost like we have the old-school unmanaged certificates, which we used to pay for. Obviously, that’s not the case, because we use Letsencrypt, and it’s all nicely managed and automated, and all the renewals and everything. But because of these interactions and these limitations, we can’t get our certificates to those places.

So long story short, and - because this was leading to a question… How would you solve that problem? What would you do in that case? I mean, you understand the different limitations and you know what we need to do. What are your thoughts there? What would you recommend?

PJ Meyer: And there was a couple other ones on there, and there was also a number of contributions and things like that… But yeah, I think in short the question “How much does the community contribute to the growth and improvements in VS Code?”, it’s a lot.

Angelica Hill: For sure. And because you have such a short amount of time, how do you decide what idea to bring, what idea is interesting enough to captivate your audience, while also being able to kind of fit into seven minutes of time? I don’t know, Jacob?

Godliver Owomugisha: Thank you so much, Chris. Really, the future should be very exciting. If I see in a short time with my experience how these farmers are adapting to some of these tools that we have, I think it will be really good in the near future. I only had a concern, maybe to Leo or someone else - she mentioned about bias in terms of technology… And also, we’ve had some of the assistants incentivize – like, give an incentive to these smallholder farmers to use this tool.

So I don’t know how this is going to work well in the future if we still have incentives in place, but [unintelligible 00:46:57.16] challenges say in languages, and also sometimes maybe typing… Or if we could just have visual graphics into these tools, that maybe when someone’s talking, there’s something happening with their tool they are using, so it could make life easier in the future. Thank you.

Bryan Liles: Yeah, actually. Since I’m on an open source podcast, I wanna talk about my open source. Actually, it’s really relevant to this whole thing. I’m working on a piece of software called Octant. I wrote it over the last year, and the long story short is that we wanted to solve the problem of how can a person who is not familiar with Kubernetes sit down and understand what’s going on with their workloads? It’s a really heavy topic. So I created a proof of concept last year, and we went through and we got it all approved, and now it’s a piece of software. But that’s not really what I wanna talk about.

I wanna talk about the power of open source, and this whole concept of a 10x developer. I like to think of myself as a 10x developer, and I can just imagine people stopping this conversation and they’re like “That guy Bryan - what is going on?” So this is why I think I’m a 10x developer. And no, I’m not telling the binary joke; that’s not even funny.

My job as a developer is to inspire others to do things and to write software that allows others to do things. But the real testament of a piece of software, whether it’s good software, or even mediocre software, is if someone can take your software and do something with it that you’d never even thought of doing.

The reason I brought up this piece of software of Octant, where you can actually go and view your Kubernetes clusters, and we’re putting more features in there, like terminals and all sorts of things… But what I’ve found is that I’ve put a plugin system in there a few months ago on a weekend - because why not? Plugins seem pretty cool… But being at this conference this morning, I found 4-5 people that came up and said “Oh wow, your software is pretty cool”, and I’m like “Yeah…” But I’m like the developer who’s saying “Well, I could have fixed this, I could have fixed that…” They’re like “No, no, no, no. It’s amazing. And I wrote a plugin using your plugin system, which is crazy, because we didn’t document it.”

[16:04] So people are creating software based on software that I wrote, so I’ve actually inspired people to do things, and someone has come and created something that I could not imagine with my software. That’s what makes me a 10x developer. I’ve made more than ten developers more productive, so guess what - 10x. I’ve 10x-ed myself. And that’s what I actually wanna leave everyone with - this whole myth of the 10x developer; your job, if you can make two developers more productive… So if you have two times two, that’s four, so guess what, you’re now a 4x developer. So if you can do it for 10, or 100, or 1,000, or in some cases at high levels, like a million, because it’s possible - that’s how you actually scale yourself.

And here’s the crazy thing - am I a good developer? I think so, because I practice. Am I the best developer? Probably not, because someone’s practiced harder than I am. But we can still all be developers who are multipliers, and open source is actually one of the greatest ways of doing that, especially whenever you’re using permissive licenses and you’re allowing people to build things that aren’t even possible without your software. And that’s crazy. So I just wanted to leave everyone with that, and that’s actually why I do all of this. I’m here to inspire on the stage, but I’m also here to inspire in software, and just be inspirational all the way around. So that’s my positivity moment for the afternoon…

Aimee Knight: Yup. So I am not super deep-diving into CSS anymore because I’m at a new job now… But I was at Warner Brothers for about two years, and I was doing frontend there, so I’m back to full stack now… But while I was at Warner Brothers – I guess the talk is a deep dive into CSS and how the browser renders your style sheets. The back-story on that is, you know, when I first started programming, JavaScript was the part that really scared me, and CSS was like “Oh, this is super easy… Just change a color here and there”, and JavaScript was the part that I was really scared of. But then somewhere, you know, kind of like my progression as a developer, I felt really confident with my JavaScript and my ability to debug my JavaScript, and like you give me a problem with JavaScript, eventually I’m gonna be able to figure out a solution, and I’m gonna be able to reason about it and tell you if it’s not working why it’s not working… But as I got more advanced with CSS, I did not feel that way.

[23:59] I felt like I was just blindly throwing darts at a dartboard half the time, and when I got to Warner Brothers - really amazing designers, and they hand you something and you have to implement it, I really felt like I couldn’t call myself a frontend developer, because I could implement the logic all day for the JavaScript, but I just felt scared sometimes when they’d hand me these designs… I was like “Oh my god, I don’t know how I’m gonna be able to do this…”

Long story short there – also, with JavaScript, I’m kind of one of those proponents for understanding the language before you really deep-dive into the framework, so I wanted to apply that same reasoning to CSS, so I figured if I really want to be able to debug my CSS, I need to understand at a lower level what’s happening; so I wanted to understand how the browser is actually parsing my style sheets… So I started going into that, and then I also wanted the talk to be a little bit more practical, and common problems developers face… So that’s the stuff I dug into.

Stephan Ewen: The short answer is it’s really, I would say, the state of the art to build backends that are supposed to – backends that do any non-trivial state management and coordination, it’s completely unsustainable, I think, the way we’re building this today. Just to give you an example… Or let’s actually start with an example. Let’s stay with LLM, because we just talked about it, right? So let’s say you’re building a chatbot; you’re submitting something, like a message there… This thing in the end has to reach the LLM, but it has to look up the context in which that chat happened before, it has to make the call, it has to go back, store the context… You don’t want it to just lose everything if you lose your connection in the middle of – let’s go with the F5 thing again… You don’t want it to actually trigger the same request twice, or lose the entire session, make you start over. So you’re probably just putting this as an asynchronous request that runs in the background, that you’re sending from your from your chat session, from your browser, but it’s a separate asynchronous request that runs, that talks to the LLM. You want it to be actually retrying in case something fails, or is overloaded and it’s throttling your [unintelligible 00:15:19.22] And then you want to be able to reconnect to that task or request in case something goes wrong in your browser, or you accidentally hit the Back button, or whatever. Just implementing this is a surprisingly complicated thing, where you start to stitch together probably a queue, a database, and a bunch of tasks to manage that.

To give you another example - we just talked about Stripe, right? So let’s say you’re sending a request there for a payment, and sometimes they tell you “Look, this is good or bad.” Like, they accepted it or didn’t. Sometimes they tell you “I don’t really know.” “Our fraud detector is still running.” Or “We have some weird thing in the background that we’re still asking, and it hasn’t told us, so I’m going to send you a webhook in a moment to tell you whether this went through or not.”

[16:02] And now you have like a synchronous request there, and then somewhere else is an asynchronous request coming up. You just want to make those two reliably meet. Even if this one fails, you want it to sort of like recover somewhere, understand where to reconnect with the webhook that you’re awaiting… And this little piece - it’s really just one case handling in the backend, where Stripe says “Okay, I’m processing”, instead of yes or no. This is actually many days of work, to make that look reliable, to make that work reliably. And it’s like lots and lots and lots of things like this, that just get in the way, with so many moving pieces, so many… Yeah, so many APIs to talk to, so much work. So much more work than originally happening asynchronously, and like in separate requests, than just in the synchronous user interaction. Just gluing this all together has become such a complicated thing that we felt “This does need a better solution.”

This is like the motivation more from, let’s say, the use case side. I can give you a motivation more from like why we actually ended up doing this. I think this is a motivation that probably lots of folks stumbled across ultimately, and so like “Okay, this needs a better solution.” I think there’s different projects approaching that problem. Why are we approaching it the way we’re doing? This has to do with where we come from. Before we worked on Restate, we were building Apache Flink. This is a different system. It’s a stream processing framework. It’s basically events and analytics. So you have these events coming in, often through a message queue, and you want to aggregate them, join them. A few examples where this is used is like fraud detection in banks. Some payment events go in, you aggregate feature vectors of that through a fraud model, or… Things like the TikTok recommender use Flink to actually join information from users and interactions together in real time, and understand how to update the features that will go into the recommendation model. I think companies like Uber use it to determine pricing and traffic models and ETA.

So it’s whenever you have events and you want to analyze them in a way that you aggregate them into some sort of – yeah, typically statistical value, or a materialized view. This is what we were building before. So it’s an analytical framework. What did actually happen then is at some point in time we saw folks were using that thing to solve the distributed transaction processing. The types of things where you would say – let’s assume an order processing service that takes the event, checkout that order, and it has to do a bunch of steps. Let’s say update the inventory, trigger payment, call the service to prepare logistics, maybe call another service to put this in the user’s history… Maybe more steps, and so on. And we started to see folks using Flink for that, because it had this interesting property that it had sort of this baked in way of reliable communication and state management. It was all built for analytical use cases. But they found this is such an interesting property that they started to apply this to the transactional use cases as well, like order processing, just because they’ve found that this is otherwise way too complicated to build… Way too easy to build it in such a way that it is brittle and not scalable, and it has corner cases for when it violates a lot of these properties that we’ve just said.

[19:48] And when this started happening repeatedly, we thought “Okay, but apparently there isn’t really a good tool out there yet.” And apparently, this property of like correct, stateful coordination is something people really appreciate. They feel like it makes their life easier to build this type of frameworks. And then we set out to build a solution for that, and that became Restate.

It’s in many ways, actually, from the way it approaches things, or from its architecture, it’s inspired by our work on Apache Flink…But it’s almost a complete mirror image implementation of it. It takes almost the opposite design choice in most aspects, because it’s really optimized for low-density transactional processing, rather than high throughput analytical processing, which was Flink. But what we retained from this idea is - yes, stateful orchestration, and event-driven foundation and so on, this is something we should build and we should be working on. And yeah, that became Restate.

Beyang Liu: [00:24:24.07] Yeah, so the equivalent of a day in the life for an engineer is what does it take to take a feature from idea all the way to getting into production? It’s like one whole loop of the software development lifecycle, which we kind of model as this two loops that are connected. There’s kind of an inner loop, which is your kind of read/evaluate print loop in your editor, where you’re kind of quickly iterating on the idea, and making it come together… And then there’s the outer loop, which is sort of like the ops loop. You plan out the feature, you actually write it, you push it up, it gets reviewed, it needs to pass CI/CD, it gets rolled out, and then after it gets deployed, you’ve got to monitor and observe it to deal with any kind of production bugs or things that emerge.

So a day in the life of an enterprise developer or a developer working in the context of a very large existing codebase, it’s kind of like you have an idea for a feature - what’s the first thing you have to do? Well, the first thing you have to do is you have to go and acquire a bunch of context about the existing codebase. So in the pre-Sourcegraph world, what does that entail? It’s a bunch of grepping for stuff in your existing repository, maybe you’ve got to clone down a couple of additional repositories if you’re very intentional about it… Sometimes people just don’t bother, because they’re like “Ah, it’s too much work. I will just assume that this thing that I’m building doesn’t exist yet, so let me just go build it.” Sometimes it involves pinging your colleagues for help. So if you’re onboarding to a new part of the codebase, or you’re a new engineer, you’re going to go bug the senior engineer who was around when that code was written, who’s very short on time, and kind of crotchety because there’s like five other people you who have asked them a very similar question in the past two weeks… So that is a whole kind of tooth-pulling exercise. And that can take you, I don’t know, weeks, even months… In some of the codebases that we worked in while we were at Palantir, it’d literally take months just to orient on “Hey, this is the part of the code that actually needs modifying.” And there’s a bunch of false starts along the way, because you start writing something only to realize “Oh, you should be modifying this other piece over there.”

Okay, so that’s just getting to the point where you’re ready to start writing the code, right? Once you start writing the code, you’re in your editor, most of the code you need to write is probably boilerplate, or what we call boilerplate plus plus. It’s not exactly something you can copy and paste, but you basically want to find an existing example of using that one particular API that you need to use. And then you’d kind of turn your brain half off and just pattern-match against that example, because that’s the reference point. So provided you’ve found that example, then you can pattern-match against it. If you don’t find that example, then that’s kind of this arduous “Hey, let me discover how to properly use this API, because there’s no docs on how to use it.” And someone’s probably done this probably like a dozen times before, but I’ve never done it before, so now I have to essentially go and rediscover how to do that.

So you go through that exercise, there’s multiple rounds of kind of iterating on it, and you finally get to the point where “Okay, I’m ready to push it up.” You push it up to review… Maybe there’s multiple stakeholders that have to sign off on on the change. There’s the people you work directly with, maybe that’s part of your code review process, maybe you also made some modifications to some other shared libraries, and now other teams that own that code have to also sign off on it…

[00:27:57.29] A lot of times those other teams don’t necessarily care too much about the change that you’re trying to land, because they have their own priorities, and they’re incentivized to work on those, and not anything else that happens in the company. So who knows how long it’ll take to get all the stakeholders to sign off on that change. Or maybe you realize through the review that you get from a senior engineer that this whole approach was wrong, because you didn’t do enough search and discovery.

So it’s almost like this game of chutes and ladders. You have a potential to shoot all the way back to scratch; you just wasted a week, a month’s worth of work because he built the wrong thing. Best case, it takes a lot of time getting people to approve it, you finally get it approved, it rolls out to production, maybe it breaks something, maybe there’s a test that breaks that you didn’t catch locally, and so on and so forth… Once it gets into production, there’s a long tail of issues that could arise too, in terms of it triggered some bug, or maybe there was some security vulnerability that got introduced… Anyways, I don’t have to sketch this out, it’s already painful just describing this.

Jerod Santo: Writing a good design document

I made a short plea for design documents (just give us a paragraph, please!) while discussing documentation strategies on Friends a couple weeks back. In this post, Grant Slatton does a much better job of discussing the topic, because he actually tells you how to do it (well). What’s a design document?

A design document is a technical report that outlines the implementation strategy of a system in the context of trade-offs and constraints… Think of a design document like a proof in mathematics. The goal of a proof is to convince the reader that the theorem is true. The goal of a design document is to convince the reader the design is optimal given the situation.

Grant lays out your goal when writing, how to organize it, editing, and more. Then, he drops a bunch of nice tips he’s learned over the years: use short paragraphs, use an appendix, etc. Useful stuff!

Jeff Smith: So let me do two things. I’ll take you through the use case. And so I’m now cherry-picking certain data points, and addressing it… But, I mean, the short answer on your question is it depends on your baseline, repeated listening, tilt your mood in a direction, based on certain behaviors you’re doing. So I would say short answer is it depends. And I can kind of walk you through how it works, and then it’ll be fun to get your response on it. And then of course - I mean, that can go into the AI, and what… Let’s start high level.

Music, like AI, artificial intelligence, it’s limited inputs, exponential outputs. If you look at music, there are 12 notes. You’ve got seven letters, you’ve got major/minors, but in the end, you’ve got 12 notes, and that gives you everything from Mozart to Megadeth.

Then you look at music behavior. People on average, like I said, listen to so much music. But then how they’re doing it, when they’re listening to it, their playlist, the repeat, and everything else. And so all that data is there, and we’ve built the engine to capture that, and then AI to analyze, interpret, decode for wellbeing.

And if you look at – I guess on the AI side, you’ve got the traditional to discern the mood of the user from the acoustic features (a lot of what I described from the songs) and then generative to customize messaging, and so what that output is. But if you look at an experience inside of a company, a use case - so you’re an employee at a company, you get an email from HR “Hey, we’ve partner with these rock and rollers of corporate wellness. We care about your personal wellness journey. Opt in with your Spotify, Apple, YouTube, get free perks along the way. Learn more about yourself. All data’s anonymized. We’re looking for trends on how to better serve you, your job and your wellness.”

And so like I said before, we wanted to tap into their current music listening, not create another app they had to download, but it’s just say “Hey, this is the behavior. This is how you’re listening to -” I think say Gregorian chants, and what’s going on in the background.

And so what happens is when that user opts in, there are two paths. One’s for the organization end. The data is anonymized, clustered… They’re looking for trends. This way, an executive/leadership team can look at dashboards, report outs, company-level, department, division, down to team. You don’t want to get to the individual to avoid any liability of selection. “Hey, Johnny [unintelligible 00:26:48.13] was listening to Kid Rock and he got fired.” You want to avoid the one-to-one. But they want a better solution for insights that are one to many. And then you have bespoke recommendations for how to actually intervene or serve those teams.

On the individual side, they’re offering more intel about their emotional buoyancy. After a few weeks, they get a weekly email, encouraging them to check out their E-score. So think of a WHOOP band for mental health. Your sleep score. What does that data point on you? What does it say about you? Because your interaction with music is unique. And they love that, because it’s a data point in their life and wellbeing.

And then we throw in that little added perk, because we do want them to feel seen and heard. “Hey, it looks like you’re feeling a little melancholic this week. Here’s [unintelligible 00:27:31.27] your favorite coffee spot.” How do you actually take that data, not only to be self-aware, but given tools for self-regulation, and everything.

And so when you look at that model, it’s very personal, yet anonymized on the organization side. And so we’ve always had that tension to make sure we have a strong firewall. But then as we work with them and as they listen more and more, it just get smarter, smarter, smarter. It’s fascinating.

[27:59] So to answer your question, I personally don’t know, if you were listening to Taylor Swift this afternoon and then the Wiggles in the morning, how you’re feeling. But I can tell you by running through Chrp for a few weeks, you will see a mirror of your emotion, which is fascinating.

Kris Brandow: The link in presidential debates and how they were like three hours long, and there was like a one-hour opening statement… And because people were used to reading books, they could like hold their attention for that whole hour, and hold that attention over the course of three hours. And now that we’re so used to short snippets of information that we consume, we just don’t have as much of the ability to do that. But one of the ways you can kind of combat that, because our brains are so plasticky, and they can kind of mold to their… They have plasticity; that’s the word, not plasticky. Plasticity. And they can mold to new things; like, you can actually train yourself out of that by like turning off your phone for a day, and sitting down and reading books, and you can kind of get yourself out of that consumption of really short snippets of information, and the doom scrolling, and all of that. But it’s certainly hard.