Adam Stacoviak: Yeah, the anti-crypto sentiment… If it couldn’t play out well. Because it seems like it should. Because you can’t argue with the graph. You can’t argue with the importance that gets placed on it, or the weight, the perceived weight and value that comes from that as a result. And the developer can keep doing what they’re doing, not remapping around this new idea of how to get paid. They can just keep doing what they’re doing. The dependency graph predicts their future.

He can stick against it if he wants to, which increases my yield, increases his yield… Seems like it has the right kind of ideas. What’s the reception so far? Like, you’re in the percolation stage… What’s the sentiment?

Jake Shirley: Yeah, definitely. Discord, for better or for worse, is the place to be for a lot of developers these days. Yeah, I’m DarkNavi on Discord. If you search on learn.microsoft.com, we do have a page somewhere in there that talks about more resources and external resources. And we have some links to some pretty well-established community Discord servers, some pretty well-established community documentation websites and stuff like that. So I think learn.microsoft.com, googling “Minecraft documentation” or something like that [unintelligible 00:53:07.26] pretty easily should yield some pretty good results.

Carlana Johnson: I think the backwards iterator thing is actually a pretty good example. Like, somebody was trying to say “Oh, look at this backwards iterator. It’s too complicated.” But if you think about what does it take to write a backwards iterator with a Next method, the way that you would have to write it is you would have to – you would have to keep track of where you are in the loop, and then on every try you’re going to see… Well, first you have to decide you increment before or after, but then decrement it either before or after the call to next; either at the beginning of the call, or at the end of the last call… And then compare it to zero, and then… I don’t know, it’s just a little bit tricky. Versus the way that you do it with the Go 1.23 iterators is you just like write a normal for statement. So you write the for statement the way you would always write it, and then on the inside of it you call that iter function. And then if the inner function returns false, that means “Okay, I don’t want any more values.” So return, stop giving values. And if it returns true, then you go through the loop again.

[00:27:56.05] So from a writer side, again, once you wrap your head around the weird functions calling functions part, the weird signature, the actual code on the inside is much easier to write… Because again, you’re just writing it in a normal for loop way, of like “I’ve got a for loop, I’m going to start with a value that’s one less than the length, I’m going to break the loop when I get down to negative one, and i–.” So like the normal three-part for loop. And the only hard part is – yeah, the yield statement, you have to do “if not, yield value”, instead of just saying something, I don’t know.

Roie Schwaber-Cohen: I’m excited about the fact that we’re seeing sort of like a resurgence of what you would call traditional AI kind of come back into the fold, in the form of, for example, Graph RAG. I think the notion here is that, for the longest time - and I think it’s been since like GPT 3.5 - you basically saw this over-indexing on LLMs. And for good reasons. They’re super-exciting, they’re very powerful, and they can do really, really cool things. But with that said, it’s as if every other technology that has ever existed before just like dropped off the face of the earth, and nobody has ever talked about “Okay, wait, so what can we do with those things AND LLMs?” Like, where do LLMs fit in the bigger picture?

I think that vector databases kind of like put LLMs in their place a little bit, in the sense that – you know what I mean? You’re not thinking of the LLM as being the end-all-be-all, like “This is the only tool that we need.” I’m very excited to think of LLMs as these operators or agents that can tap into the capabilities that exist in other systems, and I think that what we’re going to see more and more is that people are going to figure out in what subset of the ecosystem does each tool belong, so what set of problems does each tool solve. For example, a vector database solves the problem of bridging the gap between the semantic world and the structured world, a graph database can solve problems like formal reasoning over well-structured data, relational databases can solve a whole set of different problems that they used to be solving, like aggregation etc. And then you can imagine that LLMs and agents can sit as sort of like an orchestrating mechanism, and a natural language interface mechanism on top of all those things together.

And that’s what I’m excited to see… It’s kind of when the community as a whole is going to like wake up from its LLM fever dream and sort of realize that there’s other things out there, and realize that it has so many more powers that it could yield to make really exciting applications.

Eric Clemmons: Yeah, I mean, it makes a lot of sense, but it’s inevitable that there will be some sort of bundling for performance reasons… And it makes a lot of sense that you want to develop the way that your code gets delivered to your end users at the end of the day. So bundling will be a step, building will be a step… And even though that the web eventually makes it way to browsers and language features out there, we go through our proposal in stages, one, two, three, four, five, for browser adoption… So if you ever want to get ahead, or take advantage of new language features, at some point you’re going to have to build down to the lowest common denominator. So I feel since it’s an inevitability, it’s better to just embrace it early, pay the tax soon, upfront, get it out of the way, and then you never have to think about it again. I yield my time.

Eric Boyd: They’re just literally typing, right? And I’ve actually seen here in Seattle, in the medical facilities I go to, they’re not using Nuance DAX, which is kind of exciting for me… And it’s just a different style of conversation. So that’s a really high value use case, where saving doctor’s time is valuable, and it’s not a lot of calls, and you’ll pay a good amount of money for that… Versus if you take sort of the complete other end of the extreme. Online advertising… We know these models will help online ads, but online ads are such high volume, and such low yield. They pay pennies per ad, and so how much would you call [unintelligible 01:45:53.07] There’s almost no situation where a large language model is value-add in an advertising scenario.

You ask how are people thinking about their budgets… Well, it kind of depends on the scenarios that they’re sort of going after. What are the applications? What’s the value they can deliver to the users? And at some level – I mean, these people that are building these applications have to make money, so what can they charge their users? What are the users willing to pay for that?

And so the more they can sort of control their costs, then the more the application makes financial sense for them. And so that’s also where because we’ve seen such – I mean, you talked about the 12x reduction in costs and the 8x, 6x (I forget which) increase in speed, that people have now, we’ve lit up a whole lot more scenarios that didn’t make sense economically before. But I think as developers, that’s kind of what you have to think about, is I want to be in a scenario where - yeah, the cost of running the service is less than the value that I’m providing, that someone’s willing to pay for me. And so that’s where you kind of have to balance.

Michael Knyszek: Okay, fair enough. But goroutines basically before Go 1.14 could only stop executing, or like be asked to stop executing by the garbage collector at the start of a function. Like, when a goroutine entered a function, and when it blocked on a channel, or… There was like a whole bunch of situations where it would yield its time. And this would cause latency issues in a lot of applications. If say one goroutine didn’t call a function for a runtime - let’s say it was just like encoding or decoding some really big thing, and it would just be in this tight loop, doing like arithmetic, and nothing could stop it. So the work to make it possible to stop a goroutine, basically at any time, was largely – the problems that it was solving was very much visible in an execution trace. And I think at the time, Austin was the TL of the Go compiler runtime team. They used the execution trace view to sort of visualize that “Hey, this isn’t actually just a latency problem, this is a throughput problem.” And you could see that this one goroutine was executing, the garbage collector was trying to stop all Goroutines, and it stopped all of them except one. And so what that basically meant was that if you had – like, if your application was normally going along happily at, say, 16 cores, there was a period of time, maybe even milliseconds, where only one core was actually doing any useful work. And that’s not just a latency problem, adding milliseconds of latency to basically everything that’s happening at that point, but it’s also a throughput problem, because nothing else is executing. And that was super – I think the visualization in the execution trace was incredibly powerful to display that particular problem and to motivate fixing it.

Rick Viscomi: I could speak for Chrome… Yeah, I know that the Yield API is available in origin trial, and we’re hoping that it will be available later in 2024 in Chrome stable.

Eric Clemmons: So this is really interesting to hear, because – I mean, it kind of takes me back and triggers some nostalgia, but also, the data… I’m gonna use those numbers. So before PHP application, 800 milliseconds. React application, 200 milliseconds. And then finally, we landed around 40 milliseconds. That was a win. Could it be sub millisecond today? Yeah, probably… But at the time – so all the same data fetching existed. So React was just the implementation detail of how were we going to make… I think that UI as a function of state has done so much heavylifting in terms of selling React, and also composing components, and writing Markdown with event handlers and everything kind of like together… It just clicked. Versus the progressive enhancement days of jQuery, like you mentioned, where you’re primarily mutating DOM nodes, and you don’t even know what it’s even supposed to look like at a state 20 of 400.

So whenever we got to 200 milliseconds – the first open source library I wrote was called React Resolver, and it was using decorators at the time, which were experimental, and that I actually had to remove from some old code at my job, actually. We had legacy decorators still in the code, and it’s like “Ooops, gotta nix that.”

But anyway, it effectively just wrapped components with “Hey, fetch this API, and then you can keep rendering.” And that’s what got us to 200 milliseconds. We were rendering the full tree synchronously, whenever we hit basically that React Resolver decorator. It’s like “Okay, fetch the data. There’s gonna be waterfalling, but we’ll paralyze anything at the same time. And then we’re going to re-render the tree until we hit it again.” So it was very inefficient, but it was still four times faster than whenever we tried to do it with PHP, and render the templates and everything.

[00:38:10.13] Finally, we actually said “Well, hang on… Do we need to fetch all this data right here?” And we took out some of the server side rendering, and we ended up rendering just basically the initial shell, with a Suspense-like spinner, loader in the middle of the page, and then the rest of it we fetched on the client. And that’s where the server was spending 40 milliseconds. But in terms of the user experience, it felt faster, because now it was five times faster to actually see the code on your screen.

So whenever I see React today, it feels like all of the Wild West paradigms and hacks that I had to put together to get the experience I want are really taking all of the data needs, that never went away, but I was just kind of moving on from the right, to the left, and then threading on through different parts of the UIs to yield the best UX… It just seems that over time, with the introduction of Suspense, that it’s like okay, now there’s first class primitives for me to use to get the behavior that I had to hack around myself for. Would you say that’s kind of accurate?

React today compared to the React ten years ago is to me honing in on web problems. The data fetching was always kind of there. The latency across network boundaries and API calls was always there. Talking to the database was always there. Caching was always there. And where do you cache, and how do you invalidate? That stuff was always there.

What I see for React in the most recent RFC discourse is we have 10 years of learning, of people building, going from counter examples, which I personally don’t find very helpful for illustrating the value of frameworks anymore… So I wish button counters disappeared. Unless it’s PartyKit showing a demo. That’s totally fine.

Carlana Johnson: We’re still going in circles. This is a pretty exciting change. So in Go 1.22 there’s a Go experiment to introduce range over functions. So as listeners probably know, generics were introduced a couple of years ago inn Go 1.18. And so basically, ever since generics were introduced, people have been saying “Alright, generics are great. I can write libraries to work with slices, to work with maps, to work with channels… But how do I write something that will go over an iterator?” Because Go does not have an officially-blessed pattern for iterators. So if you look, there have actually been a number of discussions and proposals. I actually made my own proposal a couple of years ago, which was not very different from what other people had done… And I think a lot of people, if you just think “How should iterators work in Go?”, your first thought is “Well, there should probably be some sort of interface, and the interface has a next method, and the next method returns a bool, and either there’s also a value method that returns the value, or the next method could return the value and a bool…” People propose both. The problem with doing it that way is that it’s not backwards-compatible. So if you have a slice, and you define methods on the slice, this would change how it’s interpreted. So Go would have to look at it and say “Should I be calling the next method on this slice, or should I just use it in a range the way I always have?” And so that was an initial concern, of “How do we do this in a way that’s backwards-compatible?”

[00:14:03.02] So Russ Cox realized that a way that you could make this backwards-compatible is - right now, range loops are based on the type of the value passed. So you could be ranging over a slice, over a map, over a channel, and the range statement is based on the underlying type of the value being iterated over. So Russ Cox realized that the function type is not being used. So right now, if you have a function, and you say “for range f”, that’s an illegal call, because f is just not the right kind of type to pass to a range statement. And so based on that, he came up with the idea of “Alright, well, what if we have a function, and the function will yield the values that need to be iterated next?”

So it’s a little bit funky to look at, when you see the code. It kind of bends your mind a little bit, because you’re taking a function, and returning a function, and getting a function back… But when you actually sit down to write the code, it’s not so bad.

And so this is the new way that you can essentially just write a little function that returns a function, and now you’ve got an iterator. So this is really good if you have, let’s say, a binary tree, and you want to iterate over the binary tree. Traditionally, if you were trying to write that using methods, and you would have to create like a tree iterator type, and give it a next method, and the next method either returns the value, or there’s also like a value method, and you have to keep track of where you are in the tree, and it’s pretty complicated… But if you do it as a function, actually the code is pretty simple. You just have to call the yield parameter - so you’re taking a function that takes a function - and you just take the yield parameter and it works out pretty easily to write your own iterators.

So I’ve already been playing around with this for the HTML package. It’s not in the Go standard library, but it’s in the semi-supported golang.org/x library. There’s a nice package for parsing HTML. And so I just wrote my own little iterator to go through the nodes of the tree… And so then once I do that, I can filter out items, or collect all of the things that match some selector underneath it… And it’s been really helpful; it’s been very useful.

And like I say, it’s a little mind-bending to get used to, just because there’s functions returning functions. But once you get used to it, it’s pretty handy. And then it lets you build up libraries that will take an iterator, loop through it, collect it… You know, do all those functional things that you’re used to from languages like Haskell, or Python, or JavaScript, where there’s a little bit more of the functional language influence than there is in Go.

Cory Doctorow: Now we’re back to the forces that constrain firms. This is why Adam Smith said “A free market is not one that’s free of regulation, it’s one that’s free of rents.” Because when a company doesn’t have to worry about competitors, when it doesn’t have to worry about regulators, and when it doesn’t have to worry about its suppliers and customers helping themselves, then the worst people in the company win every critical argument. When you’re sitting around a table and you’re like “I built this Uber app. I missed my kid’s birthday party for it. I worked through that kidney stone for it. And I care about this app. It’s good.” And the person sitting next to you says “We’re gonna send notifications about like tacos.” And you say “Fuck no. I didn’t pass a kidney stone so you could send notifications about tacos through my awesome app”, you will lose that argument unless you can also say “And we will lose a shit ton of money if you do it. Because we’ll get fined, because our competitors will move in, or because our users will install a blocker, and that will shut off some other important source of revenue to us.”

So this is not about – I don’t actually think Jeff Bezos is worse than many other people. I think that he’s a normal – like, this is actually my… I think that if you and I have a disagreement on Jeff Bezos, it’s I think that he’s fundamentally a normal person. Both normal in terms of his evilness, and normal in terms of his capacities; that he just got really lucky. But the difference between he and others is not that he has less of a moral center, it’s that his moral center wasn’t disciplined in moments where it was easy to talk himself into doing things that some part of him thought was wrong.

In the same way that if you’ve got a startup, and you’ve convinced 100 of your friends to quit their jobs, and put their kids’ college funds on the line to come work for you. And your investor comes to you and says “I know we said we were on board with this open source shit, but fuck it. It’s going proprietary.” It’s really easy to talk yourself into saying “I’m not going to turn these 150 people out on the street. Google just laid off 12,000 people. I can’t do that.”

[01:29:30.23] And to talk yourself into thinking that the right thing to do in that moment is close your source. But here’s the thing. If you’ve GPL-ed your code, that is an irrevocable license. So when your investor comes to you and says “It’s time to close your source”, you can say “Bob, you’re right. You’re 100% right, but here’s the thing - we can’t. We just can’t. It’s irrevocably licensed under GPL 3, and there’s nothing we can do to take that back.” And there’s a name for that in economics. It’s called the Ulysses Pact, and it’s named after one of the most important hackers in history, Ulysses. And Ulysses was gonna go sailing through the sea of the sirens, or the mermaids, and there was a standard protocol for surviving a mermaid encounter, which was to fill your ears with wax, because when you heard the song of the mermaids, you would jump into the sea and they would drown you. But being a hacker, Ulysses wanted to hear the mermaids. And so he said to his sailors, “Tie me to the mast, but leave my ears unplugged, and no matter how much I beg, do not let me go. Do not untie me from the mast.”

And so Ulysses heard the mermaids. Not because he was stronger than the call of the mermaids, but because in the moment before he became weak, he used his strength to bind himself against an anticipatable moment of weakness. When you go on a diet, you throw away your Oreos, right? That is a Ulysses pact. When you irrevocably license your code, when you organize as a public benefit company, when you do any number of things that constrain your future actions so that when you’re tempted, you can’t yield to temptation, you prevent yourself from doing things that you’ll be ashamed of on your deathbed. And without that, you and me and everyone we know are handily capable of reasoning ourselves into doing the worst things we can imagine, and convincing ourselves that we’re only doing the right thing.

Rich Harris: Yeah. To be fair, it all began with an interview on a website that I had given. I talked about the fact that we were switching from TypeScript to JavaScript, and I’d explained that this was going to yield certain benefits. And the way that it was written up didn’t really explain what we were doing. And so some people saw that interview and they were like “Oh my God, Svelte is moving from TypeScript to JavaScript. Surely that’s just a typo, or a mistake on the part of the reporter.” And I did an even worse job of clarifying it at that point. I said “No, no, no, the article is correct. We’re moving from TypeScript to JavaScript.” And that’s the point at which everyone just said “Well, you must clearly be a gibbering idiot, because no one would do that.”

David Chase: Right now that happens at compile time. We have been talking about how to do more of it, and do a better job… Among ourselves we have these competing proposals, and we go back and it’s kind of a “Which of these is going to yield the most improvement? Are they going to have associated – like a runtime tax to have this little gadget sitting around, helping?” And sort of what’s the risk in the implementation? How hard will it be to get this done and not have screwy bugs prop up? So there’s an idea that you might tell a function that returns something that it – since it returns memory that it allocated, it says “Well, I can’t put that in my stack, because when I return, my stack will be gone. So I guess it has to be on the heap.” And there’s this question of, “Could we change the calling convention to functions that return pointers to say “Here’s a place – you could use this memory here.” Because the caller might see the lifetime of the result and say, “Yeah, I get this thing back, I use it, and I’m done. And I don’t do anything more.” Is there a way to hand it to him?

In Java, there have been implementations of Java… There was actual hardware with features for this by a company called Azul, where you would allocate initially, and it would try and keep it on the stack, and it said “Oops, sorry”, and the hardware would have sort of high-speed fault, and it would record “That one was a bad idea to do on the stack. Don’t do that again.” But since it was in a hardware, the overhead was slow; it was not like some software gadget. So in the future, it would know “Take the other path. But meanwhile, this thing that you were just about to overwrite, that you need to escape, put it somewhere else. Fix it. But in the future, don’t do this.” So it had little clever hardware gadgets to help. And the question is, how far could you go in software? Would it be worth it?’

The Go garbage collector is not – when you compare it to others, like the Java garbage collector, it’s a little slower to allocate, and it’s a little slower to collect garbage. What you get back is that it doesn’t move memory. It handles interior pointers, and it has an extremely small stop-the-world pause time. So you have kind of like these interesting trade-offs in it. It doesn’t have a lot of overhead to use pointers. But what that means is that – so the trade-offs for what you might want to do to avoid a heap allocation, you might be able to spend a little more and have it still be profitable.

Nathan Sobo: Yeah. So GPUI is an application framework, a UI framework that we basically created because at the time - what was it, like 2019… I think there were some experimental Rust graphics libraries out there, but none of them that we looked at really solved all the problems we knew we would need to solve, and just from a stylistic perspective if I can’t pick up a thing that does the things I need it to do, then I’d rather build it myself, so I really understand it, and I really have control of it, I can map it to my intuition.

So GPUI covers just the shell of the app, so interacting with the platform APIs to like pull up windows etc. We did that ourselves. And then once we have a window open, it’s just like a giant right now metal canvas that we’re going to render graphics into… But there’s also just like “How do you structure the views?” So it’s based on data flow, rather than control flow. So what does that mean? Well, Rust’s ownership rules are really strict, so we have this kind of global object that owns all the top-level views and models. And then the views and models can kind of interact with this global object via this standard protocol, where you know, say a user clicks - that models as an event, that calls an action on a particular view, and we call that into the view. And then the view can do whatever it wants. And when we call them into the view, we kind of yield the guts of the application to the view. And so if the view wants to emit an event, it says, “Hey, I’d like to emit an event.” And then Control Flow returns back up to the parent object, and then we move that data to any of the subscribers of that event.

So in a language where ownership is more promiscuous, like JavaScript, you might model an event as like “Oh, on click I’m going to attach this closure here. And inside the closure, I’m going to implicitly capture this, which creates like a cyclic loop. And so when the click event happens, I’m just gonna loop through all the event handlers and call them.” But in Rust, ownership is one way. That model, of like attaching a click handler that calls a method on you, and creates these cyclic data dependencies - that just doesn’t work.

So that’s a big part of GPUI, is sort of how do you structure the application logic, the models, the views etc. so that you can have these bi-directional interactions which are really common in UIs… Like, I open a modal; then the user clicks the X on the modal? Well, the thing that opened the modal needs to know about that, so it can hide the modal. That creates this bi-directional relationship.

So a big part of GPUI is just like a scheme for modeling bi-directional data relationships between these big views and models in the app. And then there’s another big piece of it, which is, “Okay, once we have updated the state of a view, how do we represent that view on screen?” So there’s this concept of a tree of elements, which is kind of inspired by React, but the difference is that in React you have the virtual DOM, and they’re diffing it with the underlying DOM, and then that produces some mutations to this retained mode representation of the state of the UI, and then a bunch of other stuff etc. Like, there’s this big chain that occurs… Where instead, anytime any view you updates its state, we basically rerender the entire window. So we build this tree of elements, and we do a pass from the top that lays everything down. And this is inspired by Flutter, which we found via the writings of [unintelligible 00:36:04.16] Levine.

[36:07] So yeah, we do this layout pass-down that says the constraints, how big or small anything can be, then everything passes, it sizes up. So there’s one linear layout pass, and then one linear paint that populates this cross-platform scene representation. Then we go straight into GPU memory and draw it.

And so we bypass all this nonsense that occurs on the web. I mean, this model of the web vastly predates the availability of GPUs, and introduces a lot of complexity that’s not relevant to the problem we face, of like keystroke to pixels. I get a keystroke, I want pixels on the screen on the next frame. And so yeah, GPUI is the system that we built, that kind of aligned with our intuitions, and everything we’ve learned about doing UI… And I’m sure there’s many ways to do it, but this one’s ours, and it’s worked pretty well for us.

Alex Russell: [28:05] Right? You got all these people with C in the name to get the phones out of their pockets and put them on the table. It’s all the latest iPhones. They don’t live like their users; they have not done the work to develop an appreciation inside of their product organization, that the product is the experience that the users have of a digital service, and that you have to be there with the user if you’re going to do a good job at the product.

And this is a million miles away, by the way, from how the most successful digital brands operate. Facebook, for instance, since we’re on the topic, famously had kind of like 2G Thursdays, I think it was, where all the Wi-Fi APs in the entire company would suddenly go down to slow 2G speeds. If you ask what framework google.com uses, I think it’s still some JS action stuff that was built in-house in like 2009… Because it can’t afford more than that.

What is the framework that Amazon is telling you all about? Right? They’re not. Why is that? Because that would absolutely destroy their numbers; that would destroy their business. So they’re not doing that. I’ve heard so many tales out of eBay, for instance, about people coming in and being extremely excited to get rid of Marco. “We have to move to React, because blah-blah-blah.” And then someone pulls out the spreadsheet and says, “Okay, is it worth X?”

[laughs] An acquaintance was telling me recently that they had thought that each kilobyte of JavaScript on their mid-market (again), not high-end product, like their mid-market SPA eCommerce website was costing them, at scale, about 100k a year in lost revenue. So they did the study. It turned out it was 700. Every kilobyte was worth $700,000 of revenue. Right?

So when I say that I’m getting called in, and people have this kind of terrified glint, because they’ve launched the big React rewrite, and the numbers are f*****g tanking; like they’re going – like, I’ve worked with so many teams that either can’t move product now, they are dead in the water, because everything they do feels like it’s making things worse… Or if they’ve got a kind of enlightened management organization, someone will have gone “Oh, I tried the new product. It’s no good; you can’t ship it.” So the thing they’ve been working on for 18 months is now blocked and dead in the water. Right?

So sitting with these teams who are in real pain, because the business has finally connected the fact of the flammable construction materials with the fact that it looks like there’s an arsonist on the loose, right? Like, those two things actually have a relationship. And when the business makes the relationship, it’s a bad time for the team.

So some teams can skate, right? Maybe you are selling Prada handbags. Although, okay, cool - are you doing it over an airplane Wi Fi connection? There’s just a lot of like situational stuff that you really want to work through if you’re really going to make a high-confidence assertion about who your users are, and where they’re situated.

There are some teams, who I’ve been lucky to work with, who absolutely have full control over their deployed client base. It’s amazing to work with them, because you can actually agree on what the business wants. But a lot of times, you’re in this sort of counseling session, trying to get the product owners to enunciate the things that they thought were constraints, that they never told anyone were constraints. They didn’t sign up to lose a ton of money when they did the rewrite. They knew that these JavaScript people were much more expensive than the HTML and CSS and PHP people that they had been employing before… And they thought that was going to yield a higher-quality product, not that it was going to tank revenue, right? Not that it was going to turn into a UX problem. Now, they do get more interactivity on the other side of it, but they didn’t sign up for that specific deal.

Luca Casonato: Yeah, yeah. I get it. So I think right now what Fresh does is it will hydrate the islands as quickly as it can, but it’ll still try to yield to the browsers as often as it can, so you don’t block animations, stuff like that. But it is actually totally possible that we add an option in the future where you could just export an options bag from your islands file, in your islands folder.

So the other restriction is that you have to have one island per file in the islands folder. So every file is specifically one island. So you can have an options bag there which says “This island should only be hydrated once it scrolls into view.” Or “It should only be loaded on small devices” or “It should only be loaded when this media query matches” or whatever else. It’s just not implemented, because – yeah.

Jerod Santo: The engineering team at Prerender.io just finished a multi-month migration off AWS and saved themselves a bundle of money in the process. Their annual server costs reduced from $1 million to just $200k: that’s an 80% reduction.

Now, it’s worth noting what they were doing with AWS. Prerender caches and prerenders their customers’ JavaScript pages so search engines can have a pure HTML file to crawl and index. They’re handling over 70,000 pages per minute, and storing around 560 million pages.

Side note: perhaps server-rendering and pre-rendering HTML are good ideas after all? Just sayin’

Turns out storing multiple terabytes of prerendered web page contents in this way on a 3rd party server is hugely expensive. Not only that: but traffic costs add up too.

Moving off AWS and on to internally owned storage and saved Prerender big, but they state the major savings was on the outbound traffic cost. “The true hidden price for AWS is coming from the traffic cost, they sell a reasonably priced storage, and it’s even free to upload it. But when you get it out, you pay an enormous cost.”

I wonder what a switch to Cloudflare’s R2 would’ve done to their costs? Outbound traffic on R2 is completely free and it would probably be a much faster and easier migration that might yield them most of those same savings.

The takeaway for me: the cloud is a great place to get started, but when your business begins to scale it pays off to revisit that strategy and see if there are better options.

Chris Benson: Yeah, why does it work? What is it about alpha and other things that you’re using in the software that yield that level of insight that you’re describing?

Luca Casonato: Yeah, yeah, I get it. So I think right now what Fresh does is it will hydrate the islands as quickly as it can, but it’ll still try to yield to the browsers as often as it can, so you don’t block animations, stuff like that. But it is actually totally possible that we add an option in the future where you could just export an options bag from your islands file, in your islands folder.

So the other restriction is that you have to have one island per file in the islands folder. So every file is specifically one island. So you can have an options bag there which says “This island should only be hydrated once it scrolls into view.” Or “It should only be loaded on small devices” or “It should only be loaded when this media query matches” or whatever else. It’s just not implemented, because – yeah.

Leo Mutuku: Yes, so I had started describing our project earlier on, but just to go into a little bit more detail - we are trying to build a localized early warning system for the nutrition security. The idea is that existing early warning systems tend to basically look at agriculture from a regional perspective, and by the time let’s say there’s a likelihood of crop failure and the information is reaching the farmers, it’s the same issue that Joyce mentioned; I mean, you can already see that my crops are failing.

So if we could pass them on information, as well as possible interventions and remedies in near real-time, or just-in-time, so that they can change their current agricultural practices. So that is the motivation for the project we are doing. And for us, it presents an interesting challenge, because 1) we are trying to build it for smallholder farmers, and of course, the policymakers who work with them. And the issue of smallholder farming is very unique, because unlike what Chris was mentioning, there have been those commercial farms; farms there tend to be very small, about 0.5 to 3 hectars in size. And then at the same time, a lot of farmers tend to do practice of intercropping. For instance, on the farm they may not just have maize, they might have maize and beans. So how do you detect maize, how do you detect beans, and how do you detect whether they’re getting the right amount of moisture, whether they are likely to maybe dry out, or you need to change, apply fertilizer, apply different inputs to prop up the yield. So we are trying to collect groundtruth data with tools that are very locally available to farmers and to their representatives on the ground, so using mobile phones, using the typical camera on a mobile phone, and trying to see if we can use this groundtruth data and reference it to app observation data, in order to basically start predicting instances of crop failure… Again, using a very similar process to what Joyce was describing for the disease interventions, but now here in general plant health, and especially as related to climate variances… And then trying to see whether we can detect that early enough, and then in near real-time send messages with interventions to both the policymakers, but also to the farmers.

[44:46] So for us it’s a very interesting challenge, given that, again, we are trying to use low-cost technology, but figure out sustainable ways to scale these AI to various seasons, and monitoring from maize to other different crops that tend to be what farmers plant for subsistence.

And maybe just a small addition - given that we are trying to also estimate predicted yield, such data can also be used in other use cases, such as insurance, and access to financial services for these farmers, because if we are able to estimate their yields, then it’s very easy to offer them the right financial services, that make sense for them.

Alon Klein Orback: [08:06] Sure. So I must be honest, I’m not a farmer as well. I am from the technical side, but I like what we are doing. In the beginning image, I think you can divide the interests into two; the one that gives tools to all the farmers to get more information and more details about the field, the crop, the yield, or anything like that. And you can divide the other group as the tourists that make the decision by themselves. So you get a lot of cool companies like in Israel, Taranis, Prospera, the other that doing a lot of intelligence in the field. They collect the data, they analyze it and show the farmers insight. You get drones there, you get satellites there, you get pivot and cameras etc. And from the other end, you get decision-making tools, driving the tractors, autonomous sprayers, like the same domains that we are, Blue River and John Deere, a position that was, I think, four years from now.

Vincent Ambo: So in Git, my preferred way of creating revision numbers is actually kind of implicit. So what you do is you count the number of commits in your current branch, and you use that as the revision number.

There is one complexity here, which is that if you are using merge-based development strategies, you can end up with two different points in the repository that have the same number of commits. So in that case, the number of commits is not actually unique. But Git has a feature for this in its command for counting the number of commits, which essentially lets you traverse only one side of a merge tree.

For example, you are always sticking to the left side of the merge tree, meaning that the merge commit itself is counted, but the things included by that merge from somewhere else are not. And then you get unique, monotonically increasing version/revision numbers for Git.

[36:08] We have a setup in the TVL repository where our CI system, whenever a commit makes it to the head branch, which is called canon for us, a new revision number is created and pushed to Git as a ref… Which means that you can run a git fetch command locally and you get the refs that exist in the remote, and you have the same revision numbers locally.

But even if you don’t run this fetch command, there’s a one-line shell command that you can run locally that will use your CPU for a couple of minutes while it’s going through the Git history, and it will yield the exact same numbers as remotely So you’re not really dependent on keeping the state anywhere, as long as the actual Git hashes are the same.

Natalie Pistunovich: Yeah. What I can imagine is that sometimes when using the different OpenAI engines, like GPT-3, Codex, whatever, you have to write the prompt – or you can write the prompt in different ways, and one way would yield you a better result than another, right? That’s kind of the concept of prompt engineering. So I can imagine that this is a little bit similar in that sense in Copilot, in the sense that if you write your comment in one way, it will create one function, and if you write your comment a little bit better, it will create another function.

And back to this Advent of Code with Codex, I noticed that sometimes some of the days when I just copy-pasted the entire instruction of what is the Advent Code of today that you need to solve, for some languages it solved it perfectly from the first attempt, for some other languages, other days, were just not working. So you can even change your comment or change your instruction to the computer… So you can argue that prompt engineering can be even used in Copilot.

Cameron Balahan: I would say that Robert is probably the better one to speak to this, but I can say that the overall theme has been that because this is the biggest change that we’ve ever made to the language, by its nature it’s very deliberate. I couldn’t identify a specific thing as well as Robert could though, so maybe I’ll yield to him to potentially give you a better answer than that.