Brett Cannon: Same thing here. And it’s really, really fast. And it’s done so well, actually, that Charlie got VC funding, so he started a company called Astral.sh, to hopefully do more of that. So it looks like the Python community might start to be leaning towards what the Typescript and JavaScript community have done, of “You know, for this stuff where someone can sink the time upfront into the tooling, and thus it isn’t eating into my development time - this uses the fastest language we can to get that those tools as fast as they can be, while my time, while I’m doing my development can be in the language that I’m most productive in.” So let’s write the tools once in the really fast, fast, low-level systems language that’s going to take someone else a lot of time; let them pay the time penalty to get that working, so I can learn as quickly as possible. But then I get to code in the language that I’m most productive in” and in this case, I would say Python. So yeah, there’s definitely some synergy there.

[01:18:03.00] We actually use TOML, partially on the recommendation of the Rust community. When we decided to standardize the configuration files for packaging, there were a couple options, and we considered TOML, and we went and talked to the Rust community about their use of cargo.toml.

Bram Adams: [37:23] I mean, I actually want to – earlier in this conversation I brought up the notion of using the low cost way of using these models to basically doubt yourself, to add new layers of ways of looking at this, like “Let me write this as a poem, let me write this as code, let me write this as a different idea.” A different modality, like use DALL-E to make an image, or Midjourney to make an image, and kind of rethink it. I think that that actually helps people make better judgments. I think if you can kind of have a broader opinion spectrum from a trusted source of knowledge, you get to make better opinions that you might not see on something like a Twitter, for example. Whereas like a Twitter is like a recommendation algorithm that’s sole purpose is to kind of keep you there, and kind of compete for eyeballs, I don’t think that GPT-like models care for attention nearly at scale. And that was one of the big things with Stenography with me, is that “Oh, well, Stenography is as useful to one person as it is to a million people.” And you can’t say the same thing about Twitter. Twitter needs a million people to be useful. Tools like Stenography can be useful to individuals.

So I don’t think that this necessarily follows… I think that this technology is useful, and will be misused, because everything that is useful will be misused. Cars are useful, and kill hundreds of thousands of people a year, right? And we still drive them. So I think that –

Gerhard Lazu: That’s a friend recommendation, okay? [laughs]

Kris Brandow: Yeah, we can add it in the show notes. The premise of the video is basically this question of “Why are people so bad at writing?” And kind of spoiler - the conclusion it kind of gets to is for a lot of us, we spend all of our time in school, learning how to write to demonstrate knowledge, instead of learning how to write to teach others, or to communicate with other people. And I think conference talks are a lot like that. I think people tend to go and think that they need to demonstrate knowledge to an audience of people, but the mode you should be operating in is this “I want to teach these people something.” And when you’re trying to demonstrate knowledge, you’re trying to really pack in as much as you can, and be like “Look, I understand this.” But your audience in that case are people that already know the thing that you know, and you’re just showing them that you know the thing. That’s pretty much any conference talk; people that already know the thing are probably not going to go to your talk. So the bulk of your audience are going to be people that don’t know, and probably don’t have a lot of context for what you want to talk about.

So whatever it is you want to put in your talk, probably cut it down - to take your rule of threes, Johnny - by a third. Do a third less of – like, a third of what you were going to do originally. And that will probably be Roughly the right amount of stuff.

In a piece or a series of pieces I wrote about CFP a couple of years ago, I gave this recommendation of - and I think I got this from Dave Cheney… For like a 20-minute talk, kind of like one main thing you’re trying to teach people, and for a 45-minute talk you can have like two or three… But don’t go above that. So once again, your rule of three there, Johnny, of really keeping to those three solid things, and demarcate them in your talk. Because any more and people are just not going to be able to remember what it is you sad, because it’s just, once again, assaults of information, no matter how much you try and strip it down.

Duane O’Brien: I would love to sort of bolt onto that and sort of challenge everyone on the call - and I’ll talk slowly and go first - to provide one tangible, specific recommendation that any of your listeners can do after listening to this episode to show their appreciation or to otherwise show up for a maintainer during maintainer month. My recommendation is going to be specifically for people who work in an organization, or who otherwise are sort of interfacing on behalf of their employer. You don’t have to find all the maintainers, you don’t have to understand all of your dependencies… Pick one. Find one maintainer, of one dependency that you use every day; if you don’t have any funds to give them a sponsorship, or if they’re not signed up for sponsors, just take the day, take a moment to say thank you to them for the thing that they built. Overwhelmingly, what maintainers hear is a negative feedback, bug issues, sort of constraints on their time. Just taking a moment to appreciate the work that they’re doing can go a very long way. If you are able to make a funding decision, great. Pick one maintainer, give them a little injection of cash. That’s my recommendation.

Jonathan Norris: Yeah, I think it’s just that the V8 runtime for WebAssembly is the most mature runtime, so they have those development tools built up. And I’m sure that the Wasm time by Code Alliance team are definitely working on similar types of outputs for all the different runtimes that they support… But yeah, the common recommendation is if you really want to get that low-level optimization, plugging it into some type of a browser engine that has Wasm support is the best way to get that low-level sort of profiling information. And obviously, Node, being that it just runs on V8, is probably the easiest way from a server side use case to get that data.

Adam Argyle: Don’t worry. If anything, everyone is probably in the same seat, sitting in their car, listening to this episode, going “I’ll just still use HEX.” Well, I have news for y’all. This is the best time to ramp up. Skip HSL, skip HWB. Go straight for OKLCH. If you want my recommendation right now, go straight to OKLCH and start playing with it in the browser. Go see the colors that you can get from it; maximize the chroma, change the lightness, and look to see how these things change. And go build a little color system with it.

I also have convenience things. Open Props has a couple of packs that are OKLCH packs, ready for you to go, where you just import this one line; it’s like Open Props from like unpackage and you get 15 OKLCH prompts from me that you can then go change the hue and the chroma of, and get entirely new palettes in any hue and any color that you want. You can start playing with those right away. I’ll put those in the show notes, too. It’s cool stuff. It’s a cool time to start switching – I think by 2024 we’re going to see it well supported in browsers, and it won’t be an issue, and we’ll be off to the races with wide gamut colors in our apps.

Break: [52:35]

Erik Bernhardsson: Yeah, it’s kind of a longer story maybe… But I’ve been working with data for 15 years, or maybe more, but most of my career. [unintelligible 00:03:05.02]I was at Spotify for seven years, I built the music recommendation system there, and I open sourced a vector database called [unintelligible 00:03:10.29] I did kind of everything, from deep learning, to like business intelligence, to large-scale, big data type, like Hadoop stuff… Then I was a CTO at a company called Better for six years, I managed data teams, but also managed other teams… And so as I was thinking about starting a company, I kept coming back to data, and my starting point was really just like, it’s hard to work with data, and I feel like data teams don’t have the tools they need. And initially, I was super-agnostic as to what to build. I kind of frankly wanted to rebuild everything, which is not particularly realistic…

Erik Dunteman: So we use this phrase called “Skate ahead of the puck.” It’s a phrase from hockey, where - don’t go to where the puck is, go to where it’s going. So applying that to auto-scaling - auto-scaling really has two components. You’re auto-scaling the underlying nodes, the hardware that’s running the GPUs, that’s running the Kubernetes cluster, or whatever your deployment target is. And then secondly, you’re auto-scaling the deployments themselves, going from replication of zero to one, to many, within the confines of whatever nodes you have set up.

So you’re effectively auto-scaling to things: Kubernetes pods and the nodes themselves. So my recommendation - if people are building things like this in-house, what they should absolutely do is use a platform that has an automation API for the underlying VMs. Right now, GPU cloud is sort of the Wild West, there’s a lot of new players; traditional hyper scalar clouds like Google Cloud, AWS, Azure - they have the automation, but the GPU prices are not as competitive as you could get on some of these newer clouds.

So my biggest recommendation for people building mature systems would be to choose a provider that you get ideally guaranteed access to GPUs, which allows you to scale your GPUs up ahead of the demand of whatever workloads you’re running within your cluster. And then it doesn’t have to be homogenous, the workloads deployed; just as long as you maintain GPU capacity to handle those, you should be good. But because you’re auto-scaling, the applications within Kubernetes allows you to have a little more lead time for like super-slow scale-ups on the GPUs.

Amal Hussein: Yeah, there is. But I think this kind of comes back to like a wider point… I’ve always thought for a long time that hey – this explosion of ChatGPT and generative AI is fairly new, but we’ve been using machine learning in products and technologies for a little while now, in lots of different ways, whether it’s a recommendation engine, or like a natural language processing, or a chatbot, or whatever it is… There’s all kinds of machine learning in products that you use every day, and I’ve always thought that it would be really great to educate users around how their models are trained. And that goes back to Amelia’s observability… Knowing what type of data was used to train it, and giving people facts on how this information was curated? Is there some way that we could kind of – similar to like a Chrome Web Vitals, kind of these three simple metrics… Is there a simple way of communicating to average people, “Hey, by the way, this data came from a machine learning model. These are the metrics, and this is how well the model scored on diverse content.” Was this human assisted or not? There’s ways that I feel it’d be nice to expose that. Does the average person need to know? Probably not. But should they want to know, should they have access to that answer? I think yes.

Natalie Pistunovich: As you were saying this structure of what you would do there, it reminded me the recommendation of how to introduce yourself - always follow the Inigo Montoya. Say “Hello.” Say something nice. “My name is…” Introduce yourself. “You killed my father.” That’s the relation, or that’s what happens, or that’s kind of the problem. “Prepare to die.” Let’s go on that ticket adventure. This thing goes everywhere. It’s such an amazing, short, four-lines meme to remember.

Estelle Weyl: [14:11] And CSS is also a living standard. I don’t think they call it that, but if you look at certain things… Like, CSS Flexbox has CSS flexible modules one, and then it has two. And Grids has one, and then two. I believe Subgrid is in two. Colors - I think we are at… 4 is a candidate recommendation, which means it’s been approved, but they’re working on – I can actually look… So if you look up – you know, get your browser to have MDN as your default…

Daniel Whitenack: And yeah, if other people have input on graph neural networks, or have used them in certain ways, definitely let us know. One of the other interesting ones that I know just doing searching when I was looking into graph neural networks is from Pinterest. I guess the system that does recommendation of items for users within Pinterest is – their real-time system for recommendation is built on some sort of graph neural network called Pixie, which… Yeah, if any of you are on that team out there, and you want to come on the show and talk to us about it, we’d love to hear more. But you can look up, they do have a paper about it, and all of that.

Amal Hussein: Well, I’m looking for a setup… So I’m going to hit you up for a recommendation, because I’m thinking I want to start having karaoke parties. It’s like, winter’s coming… I need some indoor fun activities to do with my husband and friends, so…

Jason Bosco: Yeah, so we came up with it mainly to mirror the cost of running the service with how much we charge users. So that’s one core principle that we held on to, because - sure, from a business perspective, that probably doesn’t make the best idea, because you’re very closely tied to your costs… But that’s what we chose in service of trying to make sure that we offer something that’s as affordable as possible.

So if you were to run, for example, Typesense on your own cloud accounts, we wanted the cost to be somewhat similar. And where we get savings is from economies of scale, essentially, like running thousands of clusters ourselves, so both the management effort involved, and the savings that you get with high spend. So that’s what we capitalize on. And then we pass on – you know, some of the savings we get, you know if you want to call it that, all savings back, instead of trying to do value-based pricing, which is what I’ve seen some other SaaS companies do. Now, that does make the pricing a little bit more complicated, because people have to know how to calculate RAM, how to calculate how much CPU they need… And that’s why we added a little calculator which says “Just plug in the number of records you have, or the size of every record”, and then we’ll calculate and roughly give you an estimate of how much RAM you might need. That works out well for most use cases.

[01:00:08.08] If people choose x as the size of their dataset, Typesense typically takes 2x to 3x RAM, and that’s given out as the recommendation in that calculator. And then for CPU, we just tell people, pick the lowest CPU available for that RAM capacity, and then as you start adding traffic, you’ll see how much CPU is being used and we can scale you up from there. Or we say run benchmarks – if you already have high traffic in production, run benchmarks with similar kinds of traffic, staging environments, see how much CPU use, and then pick good CPU. So that does make it a little bit more complicated to calculate CPU.

And then the other configuration parameters, like you can turn on high availability, meaning that we’ll spin up three nodes in three different data centers, and automatically replicate the data between those, and then load-balance the search traffic that’s coming, search and write traffic between all the three nodes. So flick of a button, you have a HA service.

And then we have this thing called Search Delivery Network which we built in Typesense Cloud, which we essentially replicate the dataset to different geography regions. So you could have one node running in Oregon, one node running in Virginia, one node running in Frankfurt, another one running in Sydney etc. And anytime a request originates, we will automatically route it to the node that’s closest to the user.

It’s similar to a CDN, except that in a CDN they only cache the most frequently used data, whereas here, we replicate the entire search index to each of those nodes sitting at different locations. So it’s as good as it’s going to get in terms of reducing latency for users. In fact, this search delivery network is what prompted some users to use Typesense as a distributed caching JSON store. So instead of having to replicate your primary database, which is probably sitting in one location, out to different regions, which is a hard thing to do, they instead send a copy of the data into Typesense, and have Typesense replicate the data to different regions, and then hit Typesense directly as a distributed cache. So that’s an interesting use case that people have used Typesense for.

So yeah, these are the different pricing angles. And I think when people realize that, “Oh, if I were to host this on AWS, or GCP, this is how much the incremental spend I have to spend with Typesense Cloud” - when that delta is tiny, when people realize that, that’s when hopefully that’s a convincing case for people to let us deal with the infrastructure stuff, rather than having to spend time on it yourself, and spend that engineering time and bandwidth. However tiny that might be, we still take care of that on an ongoing basis.

Jerod Santo: Which as a guy who likes design, I don’t know if that’s a sincere recommendation, but I’ll take it nonetheless…

Jerod Santo: Very cool stuff, with big implications. Well, we’re running short on time, but when I get to shout-outs, because you’ve teased it a couple of times, and we have to deliver this book recommendation which you’re in love with, Tejas. Explain the book, why you love it, where people can find it.

Solana Larsen: I think here there’s accountability in a lot of different areas as well, because you have accountability from businesses, or governments, you have big tech accountability is one that I think is probably most familiar to people, where we ask for more information about the content that’s harmful, and how it’s moderated, and how recommendation systems work on social media platforms, that type of thing.

But you also have – one example that stood out for me is with the gig work. In the episode we did on gig work there’s one woman who was a delivery worker, who’s the head of an association of delivery workers in Ecuador. And she’s on the streets of Quito, and when she’s interviewed about how these systems work and what concerns her about them, one of the things she said is that the government is so scared to fall behind with AI that they’re willing to go with anything. They’re so happy to have all these gig platform companies coming from all different kinds of countries, with almost no demands made at them for the fairness for the human rights of workers, because they want the system was to be there and to thrive and to be like part of this story, this happy story of AI success. And she’s saying “But in this eagerness to have a seat at the table for the governments, they’re willing to overlook all kinds of things that they wouldn’t overlook necessarily in other areas of labor.”

[30:17] And so you have a lot of that, I think, where you have this obfuscation through the technology that somehow makes people look the other way, whether it’s the consumers, or the workers, or the governments, or the tech workers themselves. And that’s part of what we need to – when we’re talking about transparency it’s not just “Can you make a privacy policy that’s really clear?”, it’s all these other things as well, like being really clear and honest about what are the limitations of a system, who are they actually working for? All that stuff?.So it’s a difficult question to answer, because AI is everywhere.

Jerod Santo: That’s all it takes, to see your own stuff in there. You’re like “This is a good recommendation.”

Daniel Whitenack: So this is maybe a lower-level question, but I think it’s connected to this… If you are an AI practitioner out there, or a technical person, or a tech lead, or a manager, whether it’s in a government organization or in a corporate organization where this sort of trickle down of AI strategy is reaching you and you’ve sort of got a mandate to do something with AI, but it’s unclear to you maybe what that means or how the value comes out of that… What recommendation would you give to such a person to like navigate that scenario? Because I do think it’s happening in many places.

Ken Kantzer: Yeah, exactly. That’s why we eventually just started – it got complicated to recommend something there, and so that’s where we ended up with our recommendation being “I know it’s a little bit more work… Use JSON, pass user data as JSON, in your own code do the right checks and construct the object on your side.” It’s a little bit more work, but it gets very hairy otherwise.

Lee Robinson: Yeah, I’m very fortunate to have people on the Vercel team who’ve helped our organization grow and provide a lot of good feedback. I think outside of the Vercel team I try to connect with other folks leading DevRel at developer-focused companies.

[01:10:07.10] So my recommendation for people wanting to get kind of a pulse on how DevRel is going is to connect with the individuals. It’s more about the people than it is the brand or the company, because that’s where you’re gonna gain insights on how their worldview is shaping, how they interface with their communities.

So I would find some of the tools that you’re interested in, maybe the tools that you use, that help make your life easier, and see who those developers are who are leading the communities there, and DM them. They might be more open to your outreach than you might imagine.

Nick Nisi: Nice. Yeah, that’s very exciting. That’s a lot of different exciting projects to work on. Now, as we mentioned, you were here a few weeks ago (at this point) talking about Socket, and supply chain security, and the whole product around that. Well, today we have you back to talk about a topic that was brought to us by the community, by [unintelligible 00:05:23.03] so thank you for the recommendation on the show… And we’re gonna be talking about logging and error handling. So let’s start off by talking about logging, and just kind of digging into that. Does someone wanna give a definition for what logging would be?

Mohammed S. Al Sahaf: That’s a tough one. One of the things that I had to look at, that’s an easy one to look at, is look at when was it published. If it was published in the ‘90s, cross it out, look for something more recent. I’m not a cryptographer, I’m gonna admit this, but I know from a few readings that elliptic curves is a bit controversial, probably… And if you know that, then you might correct me. But at the same time, there is a strong recommendation for it. And this is why one of the defaults that I opted for is to have elliptic curve DSA.

The same thing for RSA. We know from recent findings that RSA 1024 bits isn’t safe anymore… So higher bits, and so on. It’s more following the recommendations of well-known cryptographers, for example.

I remember reading one of – some of the stuff I came across, and I used a few blog posts by Matthew Green; I don’t remember exactly the titles, but it was part of my research that I went through and I’ve found which algorithms should I use and which not.

Mike Riley: Yeah, I use the pod peer-to-peer, so that I’ve got those spread out. And it’s a continual mesh network, so that it’s persistent and I’ve got a full bar across anywhere I go in the house. Now, it took me a little bit of tinkering to make sure that wherever I plug those mesh repeaters in, that I was getting a really solid connection, as well as being able to broadcast to all the available space in that particular location. Yeah, and it was a little bit expensive, because each one of those Wi-Fi 6 repeaters do cost, you know, some money. But if you wanna make that investment and you’ve got the Wi-Fi 6 devices to take advantage of it, that would be a recommendation to go with.

You could always go less expensive if you don’t need Wi-Fi 6 throughput, but again, I always like to future-proof… So make the early investment first, and then you don’t have to worry about it for another couple of years.

Natalie Pistunovich: Joining the recommendation, for sure.

Jessica Kerr: Yeah, yeah. Can I make another book recommendation?

Michael Matloob: Yeah, I feel like one thing that we learned after some experimentation with modules, after some time using vgo and then modules in the Go command, we learned that multi-module repositories should be rare. They have a lot of surprises when you’re working with them. So now our general recommendation is for people to usually have like one module per repository, unless there’s a specific, very rare set of use cases where they wanted to have a sub-module in their module. So in that sense, yeah, I guess we were overusing modules, because we were learning how to use modules. Now those modules exist, and we kind of have to work with them.

Johnny Boursiquot: [11:50] So I’m trying to figure out where features fit in the greater set of tools that you would use; if we’re talking personalization here, for example, I do know in having used some commercial personalization products that there’s different algorithms that are used and different models that are used – or rather different approaches to training and being able to produce recommendations… Like the example you gave - if I’ve liked a few things, searched for a few things, then “This should be the next set of things that you might like.” Kind of like going on Amazon and you search for one thing and you see other recommendations and you’re like, “Oh, I’m seeing things I didn’t know I wanted.” Or you go to Netflix and you watch something and all of a sudden it’s just recommending other things.

So these kinds of recommender systems - it sounds like these are a kind of problem that the features that you’re creating would feed into sort of helping these kinds of problems. So I’m trying to imagine in my head where the layer of things needed to have a fully-operational recommendation engine, what unit – where’s the feature at? Is it one of the first things that you do as somebody who’s building a model, or once you train a model? What’s the workflow? Where does that enter the picture?

Forrest Brazeal: You know, it’s changed a lot for me over the years. There was a time when my answer to that would have been very tactical-engineering-focused and saying “Hey, I really just love not having to configure a server” or “I love not having to go out and rack and stack something. I really like just being able to deal with this API and have material provisioned for me.” I think as I’ve progressed, some of the things that I’ve grown to appreciate about cloud are just about the consolidated and centralized nature of expertise that you have access to… And of best practices, and even, honestly, sometimes corporate responsibility.

Something that I really loved - and this was a super-small announcement that came out at Google Cloud Next, where it could have even just flown completely under the radar… This tiny feature where they added a sustainability recommendation into this tool they have called Unattended Project Reminder, where Google’s now able to tell you “Hey, you created this project, but it doesn’t seem like you’ve really been using the resources in it. Do you wanna shut it down to help reduce your carbon footprint?”

A lot of us, for a lot of years, have thought about cloud resource optimization as something that is just about optimizing our build. But when you think about it, it’s actually something that has a societal and planet-scale implication. That gets very interesting.