Preston Van Loon: That’s a question that a lot of people are debating right now. Me personally, I think that Ethereum is pretty well positioned to continue to be a dominant player in this space where there’s a potential for multiple implementations or protocols that do decentralized application platform.

[43:58] I wouldn’t say that there’s room for just one. In the crypto space we call it maximalism, where it’s like “Only my thing, and nothing else” kind of deal. A lot of people who are building on Ethereum or next to Ethereum - we’re more like building bridges and helping bring these different types of technologies together, because they each make different trade-offs, they each are trying to solve problems in a specific niche of a certain market sometimes… And it doesn’t have to be just a single platform, it could be multiple. Some of them are privacy-focused, some of them are speed-focused, and other things… But Ethereum I think is definitely the most well-positioned for it.

Solomon Hykes: It’s funny, because you’re right, we deal with that question all the time. So why would I replace Jenkins, GitHub Actions, CircleCI… And the first thing we say is “You should not.” You should keep it, but you should modernize what’s running on it, basically. And we’re really piggybacking on a pattern that already exists, because – software teams are not stupid. They know, “Okay, every line of proprietary configuration I put in this CI platform in the sky, it’s only going to run there, and it’s not real code, so eventually I’ll run into limitations.” So a lot of those teams, what they do is they try to keep the – I guess there’s two schools of thought. There’s the CI maximalists, “Just put everything in that YAML.” And the other school, the programmatic school I would call it, is “Okay, put as little as you can get away with, and then have that CI run a shell script, a makefile, something that can run in the CI environment, but also in the dev environment.” So you can actually – at least part of these pipelines you can run locally, and test locally etc. And so we’re just taking that pattern and doubling down on it, we’re streamlining it, modernizing it. So in that pattern you don’t have to replace your CI platform, you just have to use it in a more reasonable way, as a runner, as runner infrastructure.

I do think that the CI as a category - this is the market of CI platforms. I think one effective Dagger succeeding in the future - knock on wood - is that… But if somehow we fail to finish the job, someone else will, because some things just have to happen. CI as a category I think will just go away. It’s no longer needed, really.

[20:13] So these are two different things. We’re not telling teams, “Get rid of your CI platform now.” We’re doing something more incremental, low-friction etc. but the end result of everyone doing that is eventually someone - not us - will kind of say “Do we need this now?” I think that’s the end result.

Peter Bourgon: This is so good. This is so good, because it gets to the core point of everything here, I think, which is package management. Do you know any blockchain people? Like, Bitcoin maximalists, or something? Some of them are like “We can express government as a smart contract. We can define an algorithm which will solve all human problems.” And it’s like, that’s broken into the same way. Package management is not a technical problem. It is a social problem. It is a human problem. At the core of it is a human social thing, and the technical stuff is just the ancillary stuff you have to do to solve the human problem. But it’s my belief at this point that the people building and maintaining modules don’t understand that. They think it’s a technical problem, and the human factor can just be coerced into the right space, and that’s absolutely backwards. That’s backwards. And I don’t know how to convince them… I’ve been yelling at Bryan Mills in the Modules channel for like a year now, and this is not effective. This is probably my mistake, I’m not very good at human stuff, so I’m probably not the guy to solve this… But I don’t know how to do this. I don’t know how to do this.

Feross Aboukhadijeh: I haven’t pulled anything out into a framework, but yeah, there’s like a lib folder with some useful stuff in there. Maybe that’ll turn into something one day… My main thing was I just wanted to see if I just kept everything really minimalist, how fast of a site could I build, and how much of the stuff that’s out there I could just sort of not use, cut out.

[47:51] A lot of web evangelists at Google are talking about how a lot of the frameworks that are out there sort of set you up for failure before you’ve even started by being so heavyweight that on a mobile device – on an average mobile device, especially the average Android that’s out there that people in the world have, you’re gonna end up having such a large amount of JavaScript that has to be downloaded just for the framework itself to get going, that there’s not much room left for your app to do stuff. So you’ve already sort of lost the performance battle before you’ve even built your app, just because you selected a framework that’s too big.

That’s something that I care a lot about, because when I was working on WebTorrent I traveled a lot around the world, to different conferences and things, and I always used this free data plan that I got from T-Mobile, where you get free international data in a bunch of countries, but it’s limited to (I think it’s like) 128 kbs/second; I think they might have updated it to 256, but it’s basically a little bit more than dial-up speed… So I quickly realized which websites I used were actually built in a minimalist way and which ones were built in a maximalist way, “Let’s include everything.”

I came to appreciate the sites that really tried hard to keep their JavaScript amount low, and built their UI in a way that feels responsive even when the network is slow, or the network is missing. I just think a lot of sites could do better. I know that people are working on this, and there’s a lot of hard problems to solve; I’m not trying to rain on anyone’s parade but I just thought that if I could piece together my own approach using just the code that I know I need, and where I know every line in the app needs to be there, and that I understand – not that I understand every line of code in the app, but I know every module that’s included. I know the entire dependency tree and I know exactly why everything is included… So that I could build a really minimalist, quick, fast, responsive app.

And it’s not perfect… I think I haven’t succeeded to the degree I wanted to. There’s still a lot of things I need to improve about BitMidi, but it’s close. I think it’s close. It’s pretty good. There’s some stuff that’s hard to do, that I haven’t done yet, like stuff with making sure the UI always shows a loading indicator when you do certain things, and I sort of wanna do some animations between pages, some page transitions that look cool… I haven’t figured out how to do that in a way that doesn’t make you wanna pull your hair out. And I can do some server-side database caching stuff that’ll make things faster.

But on the whole, I think the site is a pretty lightweight, pretty performant website, even on old devices. I bought an old Android phone that is supposed to represent the median Android device in the world, and it’s really slow, it’s just a really bad phone, but it works pretty well, no problems. So I think I succeeded, I guess, in that sense; it actually works on an old phone… Whereas a lot more modern, or I guess more popular web apps just don’t work, or are just too painfully slow to use.

Austin Clements: Yeah, absolutely. So I do want to first say that stability is a very important part of Go. So I have no plans to come in and completely shake up the house. [laughter] So yeah, in terms of what’s sort of top of mind for me and what I’m thinking about… We like to say that Go is about engineering at scale, and engineering for scale. One of the things that was really top of mind for me coming into this role is how we can scale the engineering of Go itself without losing its minimalism and approachability. There are both technical and people aspects to this. For example on the more technical side, we’re starting to see dividends from the new diagnostics strategy that [unintelligible 00:21:58.09] has been driving. There we basically said “There’s no way that we on the Go team at Google have the resources to build all of the runtime diagnostics tools that people want and need. So how can we create a platform on which people can build their own tools?” That’s a very technical approach to sort of scaling the engineering of Go itself.

And then there are a lot of people processes. I’m thinking a lot about how we better communicate with and leverage the amazing developer community that we have. How can we improve our transparency? How can we better accept contributions? How can we keep people around better? How can we create long-term stability in the Go project, while scaling up the engineering of Go itself? Another thing that’s really top of mind for me right now is on sort of the engineering at scale perspective.

One of the sort of founding principles of Go was that programming should be fun. And while I do strongly believe that programming in Go is still fun, I also think that one of the costs of Go stability has been that there have been – there’s been a lot of experimentation in a lot of other languages. And there are places where I think other languages have been finding places that they can do better, that they become more productive, they become more fun. And I think that Go has never been about cargo-culting from other languages, but I think we can learn a lot from sort of the movement that other languages have had in recent years.

Go sort of started the development of more systems programming languages, of sort of more exploration in what can a programming language be… And I think it’s fantastic that we have both sort of Go on the more stable end of the spectrum, and also other languages that are willing to just like go wild and explore things. And I think we can learn from some of the best ideas in there, and bring them back into Go, and sort of keep things fresh… Because the bar for what makes programming fun moves. It’s not in one place. The bar for what makes programming productive moves. And I think we need to keep up with that, and we need to be learning and exploring.

[24:19] And then on engineering for scale - I’ve been thinking about how to engineer systems that scale for a long time. My PhD thesis was on the formal relationship between software API design interfaces and multi-core scalability. And I’ve been thinking a lot about Go’s approach to performance recently. We spent many years basically trying to float all boats, and we’re kind of running out of opportunities on that front. Obviously, we’re going to keep trying to do that, but it gets harder and harder over time.

So I think we’re sort of moving into a new phase with performance and scalability of Go, where we’re going to have to give people more mechanisms to do explicit performance engineering. But that said, I also deeply believe that performance engineering in Go needs to be incremental and composable. So engineers can trade higher engineering cost for lower resource cost just where it matters, without having to pay the high engineering cost everywhere… And so that they don’t have to be constantly thinking about the effects of performance optimizations as a system evolves.

Some of our experiments with memory allocation are actually a great example of this. A few years ago we put out this experimental support for explicit arena-based allocation. We never moved forward with that, because it really wasn’t composable. You had to be pretty careful to keep track of what was allocated how, and the details of that tended to leak out of APIs and libraries that used this. So that was kind of incremental, but it really wasn’t composable. For example, we’re now experimenting with a new variation of arena allocation that is composable, that works on these principles, so that an engineer doing performance optimization can drop in a few annotations in the code, and then not really worry about it again for a while.

And it’s possible to do it wrong, otherwise we could just do it automatically… But if you do it wrong or your system changes over time, it degrades gracefully, which also means that you can revisit those annotations as your software changes, but you only have to do it from time to time, and hopefully, the tooling can tell you “You probably need to look at this again and figure out what’s going on here.”

So those are sort of – there are a lot of things at the top of my mind, but those are a few of the things that I’ve been thinking a lot about.

Break: [26:39]

Mat Ryer: I see. Yeah, I used to do it like that as well, and it was just the dealing with it, just the unpacking it… You just had to know what that error type was. Usually you’d have helper methods… And this really comes from trying to be minimalist, honestly. If I can get away with just providing one interface, that’s better than an interface and a couple of helper methods. You know, none of it is the end of the world, it’s just to sort of tend towards minimalism… And yeah, I think returning the problems, just a map string string… It’s also nice – it’s a sort of user experience thing. It’s nice to tell the user which field has gone wrong. In the UI often they can line it up visually, so that the error actually appears next to the field… Things like that, which you can do in other ways, but again, map string string is immediately JSON encodable, where errors again, it’s more work there. So…

Kelsey Hightower: $79 from Atlanta to the Bahamas, each way. We got married in linen. If you stay five nights at the hotel, you get married on the beach for free. One of the cheapest weddings ever. But the people who came was like “Wow, you guys are doing a destination wedding? How rich are you?” “Not that rich. I’m like $1,300 into this thing.”

So to me it’s one of these things that when I saw how much power came with that, and how I felt with that, I felt like I was in control. So then everything became an examination. “What am I buying? Do I really need all this stuff?” So then I discovered words like minimalism. And it’s like “Yeah, that’s what I’m doing.” So it gives me a word to communicate to the outside world what I’m doing. I don’t need all of that stuff, because I don’t want to wash it all, I don’t want to clean it all, I don’t want to move it all every time I move… I’d rather stay this way.

Zoom forward 20 years, my life has been like that. “Why do I work here? What’s my job role? How does this work? Do I even need that?” And then it just becomes a formula for how you live. It’s your principles. I read Ray Dalio’s Principles book… And most people just don’t have any principles. That’s the problem. I don’t care if you’re a Pittsburgh Steelers fan, or you’re a Las Vegas Raiders fan. That doesn’t matter to me. Why are you a fan? Do you really like football, or you just like this team? The people that like football can watch any game and enjoy it. The people that only like their team, if their team don’t win, they can’t watch it anymore. They just turn the game off. “We’re down by too many points. Turn the game off. I don’t watch it anymore. My team’s not in playoffs, I don’t watch football anymore until my team is winning.” Like, that’s the difference.

Adam Stacoviak: If you’ve come to know Raycast for what it is, you know that it’s got a great, beautiful user interface, a really good UX in terms of like what you can do with a single, limited application like it is, in terms of like its UI footprint is not very big; it’s meant to be minimal. So you do a great job of maintaining that minimalism, but also allowing you to even expand the launch bar with a down arrow, for example, to see more applications, or to see the release notes, or whatever. I think those are all subtle ways you allow the application to remain minimal, but also expand when necessary. That’s going to be a challenge to do when you go to Windows or another platform, is like maintaining that stability from the UI.

Mike McQuaid: Yeah, probably. Yeah, I’m a bit of a kind of a clean freak when it comes to tabs, and desk minimalism, and all this stuff. I just like to not have stuff.

Andrew Rynhard: Yeah, so this is a question we usually get. One of the main reasons that you really would consider Talos over, like you said, something like Debian, is because these things simply come with way too much at the end of the day. They come with package managers, they come with an extra set of packages that you simply don’t need if all you’re concerned with is running Kubernetes. In some cases you even have to do upgrades of the nodes for things completely unrelated for the purposes of running Kubernetes. And this is just unnecessary, to put it simply.

So the first point is the minimalism that you’re gonna get with Talos. It’s only about 15 MB. At the end of the day, you’re gonna get something extremely small comparative to everything else out there. You’re gonna get no package manager. We don’t even have SSH or Bash. And the reason why we did things like that - or why we removed those - was because if you’ve ever operated Kubernetes at any scale, you’ve found yourself constantly duplicating work. You had to manage users, you had to manage hardening, you had to manage automation… But at two different layers. You had Kubernetes itself that you had to worry about, and then at the operating system itself.

So the whole goal with Talos is to just remove that Node element entirely, so that you can focus on just the cluster. We like to tell people that we want them to look at the cluster as one giant machine; and then nodes simply as more compute to that. So it’s just more CPU and RAM to a bigger machine. We can’t really look at it like that if we have to concern ourselves with who’s logging on there, what if they changed permissions, automating it… This overhead simply should go away. And that’s first and foremost one of the reasons why you should consider Talos.

And secondly, we have a really strong security emphasis. We recently just went through a whole exercise of actually securing our supply chain. So now everything’s completely reproducible, you can get all of the checksums and make sure that you’re actually running the intended version of Talos. The file system is read-only. As I mentioned, Talos is only 15 MB; what I didn’t mention is that it’s delivered as a SquashFS, which is only read-only, and there is no other way to run it. It is also completely ephemeral.

Now, Kubernetes of course needs places to write things, and there’s only one place in Talos that’s writeable; it’s /var. At least writeable in the sense that it’s going to be persisted across reboots. Of course, we have /temp and things like that, but that is completely ephemeral and only Talos uses those places.

So you’re gonna get a much more hardened experience. You’re gonna get people that can’t – you’re gonna completely eliminate the possibility of people going on there and making a node a snowflake. It’s really just Kubernetes that can change. So that’s a huge benefit when you’re talking about running anything more than ten nodes.

TJ DeVries: It was, I think, considered, but discarded. JavaScript’s ability to be embedded easily inside of a C application is not considered one of its strong suits… As well as its minimalism. I mean, Lua can be run and is run inside of some Linux kernels. So the portability and the size and all of these other things are really great features… As well as – Neovim I guess pinned in a way to Lua 5.1, which… The language is complete; there’s no changes, there’s no new things being added to the language, there’s no things being removed, which is really nice for writing a plugin now and having it work in 15 years, as opposed to – not throwing shade at anything JavaScript, but I feel like it is a common problem that I see people talk about on the internet, that “Yesterday my npm build worked, and tomorrow it does not.” Not to mention changes within the language itself. So there’s a lot of things about Lua that provide an incredible match with Neovim. Like I said, embedability, size, portability, and the fact that it’s sort of static are really great things for us in terms of shipping a small binary that can work in a lot of places.

Adam Stacoviak: It’s not minimalism… So it’s not minimizing. It’s focusing on only the essential. The vital few, versus the trivial many. And that’s kind of what your story is, JD, in this example where you got this investment, and you had this uptick, you had this intense focus… You focused on the vital few, versus the trivial many.

Mat Ryer: Yeah, I feel like Go helps there because of its minimalism. And then what about comments? I once worked on a codebase that was developed originally in France, and so all the comments were in French. Now, the code - I could read; I was basically using the code to figure out what the comments meant. So what do you think? What language would you write comments in?

Mat Ryer: [44:15] Yeah, that’s especially true in JavaScript, or dynamic languages, because I did find myself a lot of the time type-checking, making sure that it behaved when you passed incorrect things in. It’s asking for a string, but I’m gonna pass it the entire window. Totally, you can do that in JavaScript. Just give it the window.

So yeah, when I wanted really robust code, I did exactly that - I’ve found myself using testing so that I could make sure it would misbehave properly, or it would gracefully handle those weird things. So yeah, again, I think the minimalism and the simplicity in Go, strong types - its design helps with all that.

Adam Stacoviak: …but I do plan. Now, before we go into Analog, I do wanna mention Gather. So you’ve launched shirts, you’ve launched new things, you’ve got other people’s products in the Ugmonk store, you’ve got coffee - different interests; we’re both fans of Fellow, I love Fellow brand stuff. You’ve got a couple coffee things that are way out of my price range, so I’m not gonna buy those… But we at least appreciate the design and style of things.

Now, you’ve launched other things before. Gather, in particular, was one of your most recent larger, singular products, that was sort of tangentially, mostly in the design space, not so much laser-fit into Ugmonk… But you sell things that are useful, to people who care about aesthetics, simplicity, minimalism, essentialism, whatever it might be, however you frame it. How would you compare the launches, the state currently? I know we’re still in the launch, but the inertia of them. There’s some sort of velocity you can at least recognize.

Mat Ryer: So I remember Svelte’s minimalism, and they sort of made the point that it doesn’t do all the things that other frameworks will do. It sort of sticks to the basics. And that resonated with us, especially with Go, because Go has that same kind of attitude; it tries not to offer every possible language feature. In fact, the language features are relatively small in Go. But what it does, it does really well, and it’s easy to pick up and get running with. So that was important for us, since we had to do all the work.

Adam Stacoviak: Yeah, every day. I mean, every day. You’re constantly hitting and scrutinizing the flow of an application, and you’re constantly thinking, “How could it be better? What could we take out to make it more minimal? Are we asking for the absolute necessary things?”

So minimalism, essentialism, all that ties into that role for me, in particular, and it was– that was always on the table, I was always questioning those things. How can we make it less? How can we make it easier? How can we make it more fun? How can we make it more successful in terms of getting through whatever the workflow was?

Adam Stacoviak: The book I wanna add to it is Essentialism, by Greg McKeown. There’s a chapter in that book that I don’t get right, but it reminds me of its importance. I don’t recall the chapter number, but the chapter name is “Protect the asset.” It’s essentially about protecting your sleep, protecting your health… Because you can’t be you unless you’re you; and you’re not you unless you’ve got your mind, you’re not you unless you have your mental health, your body… And essentialism kind of reminds you – I think even this pandemic has been a resurgence of finding out what’s essential to you. What’s essential to you? And that’s what it is; it’s not minimalism, it’s not a tribe, it’s not some sort of religion… It’s “What is essential in your life?” The vital few, versus the trivial many. What do you need to work on right now? What really matters to you?

That chapter, “Protect the asset” to me was mind-blowing. It seems so simple, “Protect the asset”, protect your sleep, protect your health, but so often do we trade our health, our mental freedoms for other things, for whatever reason.

Sean DuBois: That’s my biggest fear with Go ten years down the line, that it’s so easy to add things, but it’s impossible to remove things. So I hope that Go keeps that minimalism. I think above the Go… I love that the Go community – you write codebases, you throw them away, you rewrite, you do new things, but the line where Go starts… You can’t change that forever. It’s like an unbreakable contract. So I hope we keep that minimalism in the language and then allow the explosion of crazy ideas outside of it.

Suz Hinton: [44:09] This reminds me of a section from Cal Newport’s book where he was talking about – he has this really dorky verbalization when he’s done for the day, and I thought it was really cute. I’m trying to remember what it was, but I don’t… The book was about focus; I’m also trying to remember the title, but I’m sure one of you would be able to remember it. It’s not his minimalism one.

Mat Ryer: Yeah, so it’s sort of taking that minimalism a little bit further as well into the choices that you make about stuff. It’s interesting, because that kind of thing is at risk of becoming one of those headlines, like “Don’t use channels.” That could easily fall into that same trap. And the thing is - I’ll admit - I have over-indulged on channels in the past… And I actually end up tying myself in such knots. But that learning process I’ve found to be probably quite valuable, so I wouldn’t necessarily want to deprive anyone of that. You’re dead right - on a real team, in a real job, in a real situation, of course, there’s limits. There’s only so much you can do. And I like that idea of having a “Don’t over-indulge on something.” Having a healthy kind of use of these things. It’s kind of a nice idea.

Mat Ryer: For dependencies, absolutely. Yeah. I think that’s also a nice way to talk about the kinds of dependencies that you need. It’s an opportunity to say, for example if there’s a big struct in some package, but you’re only gonna use one or two of the methods, you can take it as a storytelling opportunity to just have the interface that describes those two methods. And obviously, the fewer methods your interface has, the easier it is to implement, and therefore the more likely the chance of it being implemented is.

And I think Go’s philosophy of minimalism, and having fewer language features helps… Because you don’t have this big, bloated toolkit from which to pull things. Of course, you can still write bad Go code, and you can still get into a mess, but I think the minimalist approach and the philosophy for Go helps there. It helps us a lot. In fact, especially if you pay attention to it and start to apply those principles yourself, I think all that really does help.

I think Go code – we talk a lot about it. I know that people who do training on Go, and if you spend time in the Go community, it’s a recurring thing that you hear, this minimalism; shrinking things down and trying to focus. I think that as a philosophy really helps us in lots of ways.

Jerod Santo: A real minimalism pitch here, and definitely setting apart from the big corporate social networks that we’re all using on a day-to-day basis.