Joseph Jacks: Yeah. Some disease. I’m just going to say tweet. I came up with one phrase – because people ask me this question all the time, “What is the thesis?” It’s so strange. And the phrase - I want to say probably late 2019, maybe even early 2020 - is “Open source is eating software faster than software is eating the world.” So that’s been the phrase. And that’s kind of been the slogan, and the whole mantra or whatever. And I think it does really well tightly kind of articulate what the fund is about, which is like, it’s easy to explain things to people when you can kind of build on an existing, well-understood dynamic or concept or whatever… It’s sort of like reasoning from analogy, which I think often is not that helpful, because you’re not really deeply understanding something if you reason by analogy. But Mark Andreessen is very famous for saying software is eating the world, and this is kind of the Andreessen Horowitz thesis, right? And they’re very known for that, so people have a strong understanding… So I was just kind of like trying to build on that to say “Well, actually, we think instead of software eating the world, which is kind of true, we think something more important and more kind of disruptive is actually happening, which is that open source”, which really means something very specific… It’s like a really like kind of specific phenomenon, and important… “Open source is eating software itself at a rate that is faster than software is eating the world.”

[20:23] So I’m beating the drum on this for - probably another year or two years go by… And then as I was raising our second fund, which was sort of like 2022, 2023, I started to visualize this. I started to kind of like write down… I think I was like having breakfast one day or something, and I was just trying to write down two waves. There’s a really big wave, which is like the software eating the world wave, and then there’s a smaller wave, which is the open source eating software wave. They overlap. They’re sort of super-imposed on each other.

So the big wave is like this huge wave. And then if you look at the horizontal axis, it’s time. So a number of years, a number of decades, or whatever… And then the vertical axis, kind of up and down is the size of the market, and how much money, how much industry size kind of has been to sort of like eaten; how much of software has eaten the world.

So it’s like tens of trillions of dollars or whatever on the vertical axis. And then on the horizontal axis, it starts around 1970, maybe 1960 or something… And then sort of the wave kind of goes – Oracle, Microsoft were founded, and then what other software companies and software industry were sort of created… So it’s like this line that develops, and you sort of put logos on it… And then the bottom wave is open source eating software. So how do you visualize that? But again, it’s in the context of companies.

And so obviously, I put Red Hat in there, and I put JBoss, and whatever. A bunch of other companies. And then as time goes on, you’ve got like MongoDB, and Talend, and MuleSoft, and GitLab, and HashiCorp… All these other companies. Databricks… And there’s more and more. Odoo, Grafana… There’s a lot of these companies now.

And my thesis in visualizing this extremely oversimplified image of the slogan, the visualization of this slogan, was that the rate of growth of the small wave, that small curve - the rate of growth is faster and expanding at a faster rate than the rate of growth of the large wave. Because the rate of growth of the large wave has sort of hit this kind of like asymptote or sort of like scale in which you can continue to digitize more industries, and like software is eating more and more things… But it’s almost pervasive at this point. Yes, there’s software for so many parts of the world… And now if you really look at the fundamentals of software and sort of like what it really means, there’s two ways of building and sort of releasing software to the world. You can build something that’s proprietary, where the person who created the technology or the software is solely in control of the ability to make the software better, and improve it, and dictate can you trust it or not… The other way is open source.

And if you look at open source in the context of Linux, there’s so many reasons why Linux succeeded in basically becoming the dominant server-side operating system. By the same token, there’s so many reasons the Android smartphone platform succeeded on smartphones just in terms of the number of smartphones. There’s many reasons why languages and databases are increasingly becoming dominant as open source open platforms.

Now we see things like LLaMA, which is actually not technically open source, but I think there’s some forgiveness that we have to kind of offer there, because neural networks are not source code. They’re a different artifact. And we’ve blogged about this and stuff last year, actually.

[24:04] So the idea, the principles of open source have remained unchanged. There’s a lot of resistance to that in the world of capitalism, and the world of business, particularly by financier types and VCs. I don’t consider myself a VC. I consider myself something a little different, but technically my job is as a VC. But we have a philosophy, we have a view that the world across all technology categories, starting with software - but it’ll eventually sort of like permeate across other things, too - is moving more towards transparency and systems that you can actually trust and verify that you can trust them, and systems that are user-empowered, user-owned, user-controlled, and permissionless. And those things are totally orthogonal to any particular type of technology. You don’t need to be a blockchain, you don’t need to be crypto to have those properties. You do need to adhere to a certain set of principles though.

And so that’s kind of structurally what the fund is about. How we’ve been sort of prosecuting these views has kind of been relegated to software company startups, and open source companies, largely, with a handful of exceptions… But I plan on doing this for the rest of my life, and it’s extremely fulfilling and comforting to see more and more evidence of the thesis actually playing out to be more and more correct. I mean, I can certainly imagine a world where I wake up every day for years on end, and the world is just more and more proprietary, and more locked down, and more centralized, and there’s less hope of any of these ideas having any long-lasting potential. That would be really depressing. [laughter] But so far, I see a lot of evidence on the other side, so it’s kind of cool.

Break: [25:55]

Jacob DePriest: Well, you know, it turns out that threat actors also have figured that out. And when they hear things like free compute, they go right after it for – pick your abuse vector. We see campaigns that will try and escalate the number of stars that a particular repo has to increase its popularity. We see people trying to mine crypto using free compute. I mean, we see a lot. Hosting files on github.com that we’ll just say don’t have anything to do with software development. And so it’s a challenge. And it’s something that we have a fantastic team working on, we have been employing machine learning and AI for a while in this space, we’ll continue to do that… But it’s a really complex, challenging problem. And the balance we have to strike here is because we serve so much of the world’s software development ecosystem, we can’t turn the dials too strict, because then we start locking out hundreds, thousands of users that have legitimate use cases [unintelligible 01:08:03.10] And certainly, those things happen. You can’t fine-tune every filter to be perfect. But we really try and strike that balance of how we do that.

[01:08:12.15] So this is where we’re also working with our product counterparts to understand what are things we can make changes to in the actual product, or maybe a signup flow or things like that, that will decrease the likelihood of abuse, or impose costs a bit higher to actors who want to do that… And so that’s certainly something – there’s new campaigns every day that come out in this space that our teams are firefighting, and they’re doing a great job at it, and it’s something that’s just top of mind, because it’s something we don’t see getting less of, we’re definitely seeing an increase.

Sameer Ajmani: So I’ll ground this in just what are the opportunities for the existing house, versus the other opportunities. Let’s look at cloud, for example. Go is a fantastic language for building cloud applications, multi-threaded servers, doing a lot of communication. All the estimates I hear of point at the majority of workloads that could be on the cloud still aren’t. So there’s a huge still future for building scalable software and infrastructure that needs to be reliable and production ready and efficient, and all the things that Go is. So I think our existing sort of base for Go is still really important, and it still requires a lot of investment to do really well.

At the same time, as Cameron pointed out, software engineering and software development is transforming. And we need to pay attention to how that is changing. So I don’t think we know – I remember seeing in your notes, you were asking like “Well, what about ML? What about frontends?” We even looked at Go mobile years ago… We try not to chase next new opportunities just based on what’s hot. We try to be selective. For example, when it was all the crypto and mining stuff, some of the crypto people adopted Go, and people at Google asked “Oh, we see [unintelligible 00:54:56.19] and we basically said “No, we’re good. We don’t need to chase that ball.” But with supply chain security we saw the opportunity to do something that was truly differentiated and was well-aligned with what our existing users would want.

And so with AI - again, we’re not trying to chase the data scientists and the Python users who are iterating on model development. What we’re looking at are people who build in production at scale - they’re going to have to deal with AI, and deal with incorporating AI into their existing systems, and they’re going to deal with models and security and observability. So how do we serve them? So there’s a way to take our existing user base, with their existing concerns, and also think “Well, how are their needs expanding? How is the Go user’s job going to change?” And so it’s both building systems that use models, and also using AI themselves to generate Go code, or understand their Go programs. So I guess that’s the way I think about how our jobs change, is if you are an average Go user, how is your world changing, and how can we, the Go team, facilitate that change?

Jerod Santo: So this reminds me of this post from Gabe Kangas, who listened to our OpenTF interview last week… And he said “Just listened about OpenTF. A bunch of people band together, forked a major project, and found enough people who were interested in it existing and wanted to be involved. I wish this could happen with a browser. Sure, there’s a ton of small indie browsers that are using forks of Gecko and Chromium, but I’m talking about a real organization. A real, open source-first nonprofit, whose job it is to build a browser for the people. No Google slipping in advertising features, no Mozilla taking money from Google, no Brave adding crypto… A browser from the people, for the people, without corporate ownership and direct control. It’s a pipe dream, but it’s a hell of a dream. I’m sure it’d be hard, but I don’t think it would be impossible. Everybody needs a browser. Why can’t it be treated as a public good?” Nice sentiment there, Gabe. That’s what we need… So who’s coming with me?! [laughter]

Gergely Orosz: Because there was a fast-forward for a while, where the whole world was locked down, and digital became a lot more important… But I think a good example that I think of, and I have a bit of insight into, is this company Hopin. Hopin is this video events company; so they do digital events. And they were founded in 2019, so a year before the pandemic. They raised I think like a few million dollars of funding, and then the pandemic started, and right as the pandemic started, they raised a bigger funding, to scale the scene, because it seemed okay; like, digital events will now be a thing, because there’s a lockdown… And they saw huge demand in both 2020 and 2021 for their solution.

I actually organized – you could organize online conferences with their tool. And I actually helped organize a digital conference, I think it was the fall of 2020, or something like that… Because it was lockdown, I didn’t have anything to do, and I was like “Let me do this.” And we looked at vendors, and we chose Hopin in the end; I think we paid like a couple thousand for their license, or whatnot… They had this licensing. And we ran the event, and it was a success, and people liked it… But what I noticed is – and then the company kept raising more money, and at some point they were valued at 7.8 billion, or something; I think that was the peak, as I recall. And this was like two years into the founding of the company.

And then what happened is – well, first of all, just from my personal perspective… I’m not gonna represent all their users, but I just really got burned of digital events. Like, I went to a couple of these digital-only conferences, and after a while I just started hating it. I was doing Zooms all day, every day… So I just didn’t want to go there. And as soon as the world started to open up, I’ve just been to my first proper conference. I love the normal conference format, and I would not – okay, maybe I would jump on to watch a video online, but I don’t think it’s really important.

And then with this company, Hopin, they saw their growth just first stall… And the thing that might save the company is they actually bought a bunch of different companies. They bought StreamYard, which is a streaming company, and they bought a few other video streaming companies… And what I’ve heard from people who work there is their events revenue, their flagship thing is just going down, because it’s really hard to sell right now. People just don’t need a digital-only solution anymore.

And my point is, they’re a bit of an outlier, but they’re a typical pandemic company, where it seemed the whole world would change, a lot of money went into there, and if the whole world would have changed and we would now be doing a digital-only conference, it would make sense, because they would probably be market leaders… But the world has gone back, and I think we’re seeing this backswing a lot of times.

I’ve seen a chart about e commerce adoption, where it spiked, and it did look like it’s jumping up ahead by 5 years or 10 years, but then it came back, and now we’re just on that normal growth. So this growth is back to where it was before, which means that everyone who expected that in 2022 or 2023 you’re gonna have similar growth as 2021 just over-hired, and now they’re all correcting, because – well, because also, don’t forget, there’s a second part here, which is not just the COVID is shrinking, but the interest rates are up, which means it’s a lot more expensive to borrow any sort of money, which a lot of tech companies had been doing… So they can’t borrow money, so they need to rein in their costs if they’re not profitable.

[14:29] And those are just a few things. We’re not going to be able to figure out exactly what’s happening, but the pandemic was – it’s just so strange, because for the rest of the world… Take an industry like hotels, or hospitality, right? You’re kind of working in a hotel, or managing a hotel… The pandemic was terrible, right? You got shut down, you had no revenue, you were trying to survive. For tech, it was the opposite. It was amazing, and it was great that time, because we had more jobs, more money… There were people quitting, because they – people had a lot of options, and it was a great time to be in tech. Now it’s the opposite. If you work in hospitality, things are great. More and more people are traveling; it’s going up. You’re gonna get more – hopefully, you’re gonna be earning more, getting more tips, whatnot. And now in tech it’s the opposite. It’s just not great if you’re in tech.

I mean, it’s not great to see the news… This is impacting people. There’s a question of how many people are really impacted in the sense of not just being laid off, but not finding a job. And I think that’s where we’re gonna see a long tail effect, or like a double down. People who are software engineers, experienced engineers who are being laid off at well-known companies - I think it’s hard. I don’t want to trivialize this. But they will have options to work somewhere. It might not be as great though as their current company in terms of maybe culture, or compensation, or both. But they will have options.

The problem is that all of this will trickle down. We’re now seeing thousands of really competent software engineers being on the market, so startups are really happy, these banks are really happy… I have some friends at Uber, former friends, who… I used to work – one of my first jobs was at JP Morgan, in London, an investment bank… And at the time, I really liked that job, because it was one of my early jobs, and it was a great place to be… But when I got my next job at Skype, I just realized JPMorgan was totally not a tech company. And I was so happy to finally work at a tech company, and I said i would never go back to a place like JPMorgan.

Uber also had a really good engineering culture, in the sense that it was one of the best places I worked at… And now I have some friends and colleagues who work at JPMorgan; and I talk with them and I say, “Dude, why did you kind of take a step down?” And he told me “So here’s the thing… Two things. First of all, it’s just really, really stable. They have super-profits. I get all my compensation in cash. None of that stock going up and down, and mostly down. Second of all, they actually want to create a tech culture, and finally, they can hire the people into this; they have a lot of these greenfield projects where it’s full of – they have ex-Facebook, ex-Google, ex-whatever people, and it’s actually pretty good.”

So I think the world is changing a little bit, and people are realizing that pre-IPO companies, or even any form of companies that give you stock - it has a massive risk. So traditional wisdom the past 10 years was if you are a publicly-traded company, you get like half of your compensation, if you’re a senior engineer or staff engineer, half of your composition in base salary, and the other half in equity, and that’s great, because equity will always go up. Well, equity for some companies has collapsed by let’s say 70% or 80%. And I talked with people who on paper they were earning $500,000 in Silicon Valley, and now it just went down to like 350k or 300k. And they’re saying “What should I do? Should I interview somewhere else? But now there’s fewer jobs… Or should I just stick it out?” There’s no good answer. But the point is, now you’re really seeing those banks - one of the reasons that people are going to these banks is they might pay, let’s say, for a similar skill, maybe they pay 350k or 400k, or less, or more; it doesn’t really matter. But it’s fixed. It just doesn’t move. And the people who I know who have families, and they just want stability, they’re like “You know what - it’s a good trade-off. It’s a rocky time, I’m gonna sit it out here.”

[18:09] And you know what - it’s kind of nice, because now those companies can hire people who would have never considered working there. So we might see the industry transform a little bit from the unsexy companies becoming a bit more sexy, and the sexy companies… Let’s give an example - Coinbase. Coinbase was such a hot company to go on and work for a year ago. They’re doing crypto, and if you’re into that - I’m not that much into it, but again, they’re doing something really interesting in that space, trying to give new financial instruments… And they were paying really, really good. Like, they were giving ridiculous stock packages to people who were accepting it. And now the company is not doing that great, the space is kind of – it’s unclear what the future will be, and their stock is not doing that great… So that company, or some of these hot startups have just gone from being one of the best places to work at, to “Oh, it’s a risky place.” We’ll see if they’ll be able to grow. And I’m not just talking about Coinbase, I’m just talking about the hot companies in 2021.

Matias Pan: No worries, no worries. Yeah, so technically, those two things are actually coupled. Because the static infrastructure is something that you know you will want once you realize, “Okay, this is the architecture that we’re going to have.” When you have that intent, then you already want it in production, in a way. So you want provision, and you want to be deploying it, and changing it… So you want both things, the static and the dynamic. They are coupled, in a way; or at least the intent of doing that are coupled. So dynamic comes after the static is done.

So the way that this usually works is a team has a product that they have to develop… For example, I’m not gonna mention it, because it’s still private, but there’s a new product coming on the crypto domain that has somewhat of a social aspect. They realized that they want to tackle that. In a good scenario, you have the PR FAQ of the product itself, that tells the story, and you work on that, you build a design document… And usually, the idea is that you present that design document as a pre-read on a meeting, and then someone from infrastructure is going to be on that meeting. So you will get the chance to challenge some decisions, or help in some areas… To say – I don’t know, for example, somebody decided Dynamo, and maybe they didn’t realize that “Yeah, but Dynamo charges you per write, and size of write, so make sure that you don’t go over 4 kilobytes” or whatever that may be.

[34:08] So after that part, then it’s all – and that’s our main goal. It’s all up to the developers. They just have to install the CLI, run a command, push to Git, and that’s it. Their job is done. Unless they have a special use case that requires additional work, then they have to do something else, and we can talk about it a bit. But yeah, in the traditional case, after that design doc is good to go, you simply run a command.

So that’s really the idea that I have in mind… I started with Rails, and for me Heroku was mind-blowing. I was used to deploying like the – I already forgot the name; the LAMPstack for PHP. And when I got to Rails and Heroku I was like “Just a Git push? Really, that’s it? That’s all I have to do? Nice!”

Ali Spittel: I’m not sure. I think that one that we’ve seen already is eCommerce get hit really bad, and growth tech more generally… Just watching my portfolio of stocks, seeing Shopify going way down, and other companies in that kind of same realm; I’ve seen a lot of that.

And then I think the other really big one is crypto. We’ve seen that that was just soaring this winter, and everybody’s like “You’ve gotta get in, you’ve gotta work for it while you can. You’ve gotta get in on this. It’s gonna be worth 85x in a year” or whatever. And then it’s really crashed.

[48:10] I’m not sure what the job situation looks like in that realm right now, but I think that that’s another industry that’s probably really struggling right now.

Adam Stacoviak: Let me pull us out of the weeds a little bit then. So what you’re doing with Socket is not prevention, it’s awareness… Because I’m looking at the post you shared with us as part of your thesis for pitching this show to us, and it’s like, colors in faker, breaking thousands of apps, library hijacked to steal user passwords, crypto mining installed… So you’re not gonna prevent those things, you’re gonna make the open source users, the devs, aware of what’s happening in their repos. You’re not - at this point in time at least - preventing. That’s npm’s job.

Gergely Orosz: So I pay attention to capital markets and IPOs, because whenever companies go public, the returns on investors – whenever investors have a massive return, they reinvest it in the startup ecosystem… And I think what we’re seeing right now is we’re seeing so much money go into startups, and a lot of that money will be lost. So we’re exiting a cycle where about 5-10 years ago a lot of capital was invested in promising companies that did go IPO - Coinbase, Robinhood, all these… They worked out great, and now a lot more money is going into the likes of crypto, and electronic vehicles, and a creator economy, and all these things. My personal take is we’re not gonna see as crazy returns in ten years’ time… But you know, it’s great to start a company.

The other data point that I look at, which is just a very basic one, but it’s a great one, is the Ukraine job market… Because there is one company called Djinni, who basically owns that market. Most people get hired through that portal, and the people there actually share – they’re very honest, they actually share how much they get… And they publish it almost like every couple of months. So you can see the levels go up.

And Ukraine is a very interesting market, where it’s a little bit cutthroat… So if you wanna get a project done, you go to Ukraine, because if you pay enough, you get it done. Because people have zero – not everyone, obviously, but a lot of people don’t have strict job loyalty. If someone pays them more, they will literally stop their project and go to the next one. So it’s a super-liquid market.

They actually show it almost real-time on how the number of jobs posted on their platform - the first time there were fewer people and more jobs posted was in January 2021, at the beginning of this year, when all the budgets were approved for all the massive, big companies who decided “We’re gonna spend on tech.” So that’s an interesting data point that I track together as well. And then I just have some of the – I’m building a salary portal, and I’m getting a sense of where the offers are, but those are the main ones.

I think you need to look at some of the data points that are around you, but I wouldn’t over-emphasize on some of these… But these two data points - the stock market, obviously, and just thinking through on how that money will exit and where it will go… And job markets where we have data on, and it doesn’t have to be Ukraine, but it can be some other markets… But for example, U.S. is too big to have just one data source, and they’re kind of skewed… So yeah.

Evan Weaver: Not everybody. Obviously, a lot of Fauna’s features were inspired by things that we wanted to have at Twitter, and we’re forced to develop and forgo on our own. Fauna is really design for the modern web 2.0+ application world. With SaaS, in particular - I would say the majority of our customers are building some kind of SaaS app, with a business purpose. Or consumer-oriented applications. And then I think that the third category, which somewhat overlaps with the first, or blockchain-adjacent applications, things that use crypto for public transactional purposes, but also store additional data for application purposes.

The thing that these all have in common is that – you know, there’s a wide variety of customers and people interacting with datasets that interact with it in a soft, real-time way; they interact with it from the web, from mobile applications… You know, it’s all the apps you use today.

What we don’t do is analytics. We’re not a olap database, we’re not a data warehouse. We’re not a cache for some other database. The transactional consistency does have a cost in throughput and latency, so if all you want is a cache, you should go get memcache or something like that. We’re not an information retrieval system; we don’t replace Elasticsearch. We’re not a queue. You can go get Kafka or something else like that for those purposes. It’s really sort of the dream of MySQL, like - we wanna be to the serverless era, and JAMstack, and kind of the API infrastructure era the same way MySQL was to the web 1.0 era, where this is a general-purpose operational data platform. It’s very easy to use, it’s very easy to adopt… No startup costs, develop on your laptop. It does a very good job; I mean, we can argue about whether MySQL did a good job, but it was a better job than others at the time, because it existed. It does a very good job at that core, short request transactional user data, mission-critical data, constrained indexed use cases… And then it does a decent job at everything else you need to build a fully-featured application, so that you can get started without having to have a whole bunch of tools all mixed up in your tool chain.

We fundamentally don’t really believe in the classic polyglot persistence attitude where you pick the best tool for every single kind of query pattern you might have in your app. Databases are heavy pieces of infrastructure. It’s hard to move data around. You don’t wanna have too many of them. So the more general-purpose that it can be, the less you have to use. We do have an advantage in the cloud though, that we can connect and integrate more easily with adjacent systems in a way that takes the integration burden off the user. So that’s one of the things we’re working on going forward, making it seamless to link up to the analytics database you wanna use, the queue you wanna use, and that kind of thing.

Bill Kennedy: Now, when we talk about Go - one of Go’s language design philosophies was being able to do more with less code. It’s coming from these – I believe. I can’t speak for Robert, and all… But I believe it’s coming from these ideas that if there’s less code you need to write, there’s going to be less bugs. Now, why did they say this? Because Stroustrup says “If you’re writing more code than you need, it results in ugly, large, and slow code”, where ugly means you’re leaving places for bugs to hide, large means you’re ensuring incomplete test coverage, and slow means you now start to make shortcuts and dirty tricks away from your frameworks and your patterns, because you’re moving fast and the code gets out of control… And these things absolutely happen.

So I think we’re talking about all of this… It all works together, and I think Go is tied into that. And we complain about Go’s error handling. We love to complain about it. But do you know that there was a study done where they looked at 48 critical failures that brought down systems. Hundreds of bugs in Cassandra, HBase, MapReduce, Redis… How many systems run on Redis today? And they’ve found in this study that out of those 48 critical failures, 92% of them could have been avoided if error handling was done better. Failures from bad error handling.

So again, I think that Go designers knew this. They knew this, because they were developers themselves. They were not necessarily academics. They had to build software. They knew what the average developer needed, they knew where they were falling down. And I think Go comes in and solves these things.

[36:15] Personally, I think when somebody complains about error handling in Go, they’re complaining about – they want it easier to do, not easier to understand. [laughter] We come back again, right? So sometimes when you make things easier to understand, things have to be a little more tedious.

But here’s another design philosophy, Johnny? Two of them. One, you shouldn’t be writing code for yourself. You should be writing code for the next person that has to come along. Because if you don’t, if you’re not thinking about the next person and/or the average developer on your team, when you leave, that codebase leaves with you. It gets replaced. And the 3, 4, 5 years you spent on that ends up resulting in meaning nothing. I’ve got code that’s 20-something years old, 10-something years old in production right now. The 20-year-old code should go, because that’s way too long… But I think it’s there because I always wrote code with the understanding that somebody else has to be able to maintain this. It wasn’t about me, it was about the next person, and that allows that code to now not just have to be replaced, right? You need to have that design philosophy in your head; you need to be thinking about that, “Who’s the next person that’s gonna come along here?” And then you’re always writing code for the average developer on your team.

If you’re the average developer on your team, that means I can wake you up at 3 in the morning (God forbid) if I have to, and you can handle the bug. That’s the average developer. If I can’t wake you up at three in the morning, then you’re below average. So another question is “Why are you below average? Is it because I’m failing you, or are you just not coming up to speed?” And then for me, the next thing is the above-average developer. That’s scary, because those are the developers that tend to get bored, and instead of being able to write for the average developer, or bring the team up - that’s where the clever code comes in. That’s where we trip up.

And I tell people all the time, “When you’re hiring, evaluate who this person is for your team. Are they below, are they average, or are they above?” And consciously understand what you’re gonna need to do as an individual and a team to get this person in the right place. If they’re below average – which is great; let’s hire developers who are below average for our teams, so we can bring them up and we can create a stronger team. Those are the best developers in the world, because you can really teach and train them. And now you’ve got somebody who will stay a long time and really work hard and thank you for the opportunity.

But if you put me on a team that’s doing business APIs, I’m above average. If you put me on a team doing crypto, I’m below average. And if I wanted to learn crypto and you gave me that chance, I would be ecstatic, and I’d work hard, and we’d get there. But if you’re hiring somebody who’s above - and I’ve done it before - they can either be amazing mentors and coaches, which is why you’re hiring them, I hope, or they can create utter chaos and destruction, because everything they’re doing is not comprehensible to anybody else on the team, and you’ve gotta maintain it.

[39:40] So those are design philosophies around building teams, around the ideas of all of this stuff. And you wanna apply it back to micro-level decisions, like constructions, functions versus methods, to macro-level decisions around app layer, business layer, foundation layers of code. Policies for these. Import policies. Error handling policies. Who can shut down an application? Who can’t? Who can log? Who can’t? Who can wrap errors? Who can’t? Who can set certain import dependencies? Who can’t?

And you don’t have to have all of it day one. You have to develop it as “Suddenly, there’s a hole in the engineering decisions. Hm. We don’t’ know what to do here. Okay, that means we may not have a design philosophy here.” I get excited when that happens. I’m like, “Oh my God, we’re gonna have a design philosophy for this. Oh my God, we get to do something new! WOOOH!”

Now, you’ve always got some of your base, foundational, right? But those are exciting days. And it’s also exciting sometimes when somebody finds a hole in a design philosophy or policy, where we thought this was the right thing to do, and suddenly we’ve found an exception. And there’s exceptions to everything. There are some exceptions you just can’t take. I don’t really take exceptions between project layers. I’ll never let the foundational layer log. There’s no exception to that. If you have to log, you’re in the business. That’s it.

But then there are other exceptions… Here’s a good one, Johnny. Here’s one where you might take an exception. So baseline design philosophy - a type system is not to be shared. A type system exists to allow package, which is a unit of code in Go, a clearly compile-time unit of code. A type system is design to allow data to flow in and out of the package API, where a package has a purpose. So if the type system’s job is to allow data - if. There’s my philosophy. If you agree with this. You don’t have to agree with anything I’m saying today, by the way… It is totally fair. But if you believe that a type system’s job is to allow data to flow in and out of a package, then that type system is highly localized to that package and that package only. So now you have to make a decision about every API. When it comes to data flowing into an API, you have two choices. You could say “I want the API to accept data based on what it is.” This is what I would call concrete functions, accepting a concrete type. It can accept a user, and only a user. That’s what it is. But thanks to interfaces, we can write polymorphic functions let’s say “No, this API will accept concrete data based on what it can do.” And that’s a next level of refactoring, hopefully; I don’t wanna start there, but suddenly you realize “Not only can I work with a user, I can also work with a customer. Based on this common behavior, we make it polymorphic.” Okay. We all agree with that. You have both choices, and those are the only two choices you have. And those types should exist as types within the scope of that package.

Now, here’s where the fun begins… I have a strong rule that functions should only return concrete values. The function’s job is not to pre-decouple or wrap concrete data already in an interface; that is not the API’s responsibility. It is the caller’s responsibility to decide whether or not they need the decoupling or not. Not mine.

So minus the error interface, which is a whole another set of interesting design philosophies and things I have, I don’t wanna see a function that uses http.handler as the return type. I don’t care if you know or think they’re gonna put it into a handler already. I don’t care, it’s not my job. My job is to give them the concrete value that they can then do with what they want.

“Well, Bill, then we’re leaking a –” No, you’re not leaking a type. They already imported your package. There’s no leaking there, what are you talking about? Stop trying to abstract for the caller. Let them do it. Now, there are two exceptions to this. One is the error interface; we’re handling errors in a decoupled state. There’s lots of reasons why we wanna do that.

[44:04] And until 1.18 comes out, there are times where you might need the empty interface. It should be a little bit of a smell, but let’s be real, I’ve had to write a function or two over the last six years where I was trying to be, for whatever good reason, generic. Maybe I was just doing some data flow… And we were using the empty interface, which - now in 1.18 we’ll be able to replace with a concrete type. [laughter] I mean, what is generics at the end of the day anyway? Generics is concrete, polymorphic functions, where the polymorphism isn’t happening at runtime, the polymorphism is happening at compile time. We’re choosing the concrete type, the data – because the only data that flows is concrete data anyway. We’re just choosing that at compile time. For me, it’s concrete polymorphism, as opposed to runtime polymorphism.

But there’s a philosophy - we shouldn’t be using the interface as a return type, minus those two exceptions, when they happen. And people disagree with me there, but… There it is. So if I see a function that’s returning an interface, it’s immediately code review style, so “What are we doing? Why are we doing this? Prove to me that we need to take an exception”, but it’s gonna be hard, because if I return the concrete type, that doesn’t prevent the caller from doing whatever it is they’re doing.

Perry Mitchell: Yeah, sure. My colleague, Sallar - he’s been obviously just a fundamental part of the whole process. I couldn’t have done this without him and his motivation, his personality. I think that when you find the right people to work with, you’ll know that it’s key to getting any project off the ground.

We met when I moved to Finland. We both worked in the same ad tech job. Not super-interesting, but pretty technical. We got to know each other, and we got to know that we both enjoyed writing open source software. We spoke about the whole password manager situation, and he agreed, and… Yeah, we pretty much just got off the ground then; we started kind of throwing things around in Node.js and playing with the project there, and kind of fell in love with crypto and kind of building projects around that.

The first project to come out of that was the desktop application, with Electron and React. It was a huge amount of fun to build that. A completely new experience… Back then it was still a little bit broken, a little bit rickety; it wasn’t completely solid, it wasn’t super-friendly to build in, but it got things done and we were able to very quickly produce a cross-platform application… And yeah, it just spiraled from there. After that, we just became insatiated with that and went on to the mobile app, and then the browser extension.

Jerod Santo: Yeah, not too bad. Preethi, one thing that – you’re doing a great job, by the way, of educating Adam and I as we go here, because we’re very much crypto and blockchain laymen, as we said… But I think that speaks to what you’ve been up to for a while now, which is actually how we came across you, and how many people online who know you know you, is because as you got started in software engineering, slightly before that post in 2015, and here we are, two years later from that you’ve taught and you’re written and you’ve helped people learn along the way. Can you tell us what’s the impetus for that and about some of the things that you’re doing with Ask Preethi, and with Between the Wires, and all the good stuff you’ve been putting out for people to learn alongside you?

Mikeal Rogers: A huge of amount of growth in, the kind of growth that we see in other places. I’ve spent a lot of time actually figuring out what we could do here and what our current barriers are. One barrier which I think is a problem and it needs to get resolved, but it’s not the number one problem, but it is a problem - JavaScript standards have not given us some of the tools that we need at the language level to do some of this.
This is kind of hilarious - now that Brandon has a company that’s doing Crypto in the browser, he is shifting some of his focus… Because he does a bunch of standards work as well, and there are some new 64-bit stuff and some new math stuff coming out that Brandon is pushing forward into TC39; also, the Node Foundation in partnership with the JS Foundation - the JS Foundation is a member of TC39, the JavaScript standards body, they’ve started to send me to those meetings.

There’s one right now that obviously I couldn’t be at, but I went to the last one that they did and resolved a lot of the module stuff, a lot of the concerns that we’ve had about how do we integrate these module systems; we were able to work that out. And I’ll continue to go, to start to try to resolve some of those problems.

Another thing we have to think of is should we try to reach a system like R and Python have, or should we try to go about this in the way that has brought us a lot of other successes? If you look at the early days of Node, we weren’t able to bind to a lot of low-level C libraries, and because we weren’t able to do that, we ended up building a lot of our own competencies in those areas, and building out things that would have been a native layer, like just binding the C, for something like Redis where we got a native Node.js as a client, that’s actually in a lot of workloads faster than the C library. So there’s a lot of value there.

Mikola Lysenko, who’s here, he was a math PhD and got really involved in the Node.js community and started building different algorithms as just single modules. So you have this modular way of looking at things, which is not the way that we’ve done math and science computing before. There are these giant libraries in C or Fortran a lot of the time, that are huge and really unwieldy, and a lot of it is entirely unmaintained, but it’s the only place to get this particular algorithm.
So do we wanna enable a broader ecosystem of people building that kind of stuff out? I think we currently have the most compelling ecosystem for 3D computing, I think, all built for WebGL, obviously… But Mikola has a project called Regl, which is a phenomenal suite of toolchains for doing modularized 3D programming. He’s written a ton of different modules for all this stuff. A lot of it is built on a data structure called ndarray, which is an N-dimensional array, which is incredibly fast; it has gone through four years of optimizations now. There’s a Mincecraft in the browser called voxel.js that you can look at that’s built on a lot of this stuff. It’s actually built on earlier iterations of this stuff. So there’s a lot of good movement there.

I don’t think that we’re going to figure out a way to have a better Fortran binding layer, or cross-compile these Fortran libraries. R is mostly Fortran code. It’s a layer of bindings on top of a lot of very old Fortran code that SciPy also binds to and their libraries bind to. We’re not gonna get to a point where that is compelling. I think we’re gonna have a slower road to it, but we’re eventually gonna get to a better place where we have a more modular ecosystem of independent algorithms that can be plugged together really easily. I’m excited for the future of what this looks like, but it is gonna be a long road.

[43:58] I think lastly SciPy - R as well, but SciPy, I really look at… They did a ton of outreach and community building with the academic community to get them onto SciPy. Over the years, I’ve met a few of the people that have really pioneered that work. It’s hard community work, you’re working with a lot of older institutions, you’ve gotta have a real passion for it. But I would love to see us as an institution take on some of that. It’s one of the things that me and Tracy wanna try to get to at some point - building much deeper inroads with the academic community and building that up.

Python is not uniquely good at scientific computing; I mean, not a knock against Python, it’s just not better than any other particular language for that. They don’t have great bindings to all these old Fortran libraries, it’s relatively slow… They’ve just built a great community and a great support system for it. They’ve done a phenomenal job. They have great documentation, they have a lot of people that have written great blog posts about it, there’s a ton of knowledge about it, and there are just people out there doing the hard work, getting adoption. I think that’s the thing that we can strive for and we can actually make an impact with at an institutional level in the Node Foundation.

Filippo Valsorda: Yeah, so the approach that I’ve been working on for the last few months - quite a few months, wow - is TLS 1.3. The short version of the crypto like page is that TLS 1.3 is the new version of TLS; it’s not about getting cryptographers job security, but instead about making the protocol actually more robust against future attacks, so it’s a complete rework and it takes one less round trip to connect to things, so it’s faster, and a bunch of other things that if you’re interested in – there’s a talk at CCC 33c3 that you should watch.

But the point is we wanted to implement TLS 1.3 and participate in the standardization process with a real implementation deployed… So we wanted to take up TLS stack and add 1.3 ourselves. I essentially threatened to quit if they made me do it on OpenSSL – no, I’m joking; nobody asked me. They just asked me what to use as a base, so I just jumped straight to crypto/tls, the standard library of Go, which is a wonderful stack written originally by Adam Langley, which all of the people in the industry say that it’s where they go to to understand TLS. They read the spec, they fail to understand it, they go to crypto/tls, they read the Go code, and now they understand things. So that was the starting point… And we extended it to have TLS 1.3 support; we worked most on the server side, and it’s now deployed globally on millions of CloudFlare sites. If you just sign up for a free account, it’s on by default.

[15:56] The nice thing we don’t talk that much about, but you can definitely gather is that if our TLS 1.3 stack is in Go and you can use Go to connect to CloudFlare site it means that sometimes when you connect to CloudFlare, actually in the HTTP pipeline there is a Go HTTP reverse proxy.

Jerod Santo: The first episode I almost broke it. Yeah. But I did a much better job in the second episode. So if you want to go back and listen, skip around one of episode one… In which I darn near break the show. Okay, let’s see if I break the show this time.

Cryptarythm is an algorithm for generating cryptographic signatures. Or the subtle vibrations that occur in underground burial sites due to the crypt settling. Or the rhythm, also known as cryptorhythmic sequencing of adding and subtracting numbers in cryptographic algorithms. Or a puzzle where you are given an arithmetical expression where the digits have been replaced by letters. Or finally, a drumbeat used as a password, usually tapped out on a keypad or keyboard.

There you have it, five definitions for cryptarythm. One of those is the correct definition. Nick, you’re up first. Which one do you think it is?