Joe Percoco: [04:07] Yes, we’re a new-guard investment management platform. So to speak very simply, people will give us their hard-earned savings or capital for us to manage in our investment products. We have four or five… We have a large-cap growth one, focused on identifying blue chip compounders, we have an opportunities one, focused on rising stars. We have a crypto product we just launched, focused on identifying the best crypto assets ripe to outperform, and so we’re going to keep launching new products in different asset classes. Ultimately, what the mutual fund was for the baby boomer generation, we aim to be that for ours.

Aaron Hnatiw: I think the point that you bring up about having the basics covered is really important. It is intimidating to think about all of the things you need to think about to be an expert in security, to know what different kind of vulnerabilities there are out there… And I’m gonna let you know a little secret - no matter how much you catch, there’s always gonna be something there. I don’t think it’s possible to have code that is completely secure, unless it’s maybe one line, developed in isolation, and has no callouts and no inputs. It’s almost impossible. I don’t think you can necessarily lose sleep over that. You have to look at it from the basics perspective, and then from there, I think what a good security person will do is understand – because the way to make something the most secure is to make it not functional at all. You have to have a tradeoff.

A good security person will look at something and understand the business risks and understand really what it’s trying to do, and find the best way to put the most security measures in place. But some of the basics – I mean, I can go over some of the basics you should probably know, as a reference, to cover the basics.

I think three main things stand out that you can easily do and keep in mind when you’re developing something, and then you’re covering a substantial amount of vulnerabilities. The first one is the patch. Just make sure your libraries are up to date as much as possible, especially if there’s a security vulnerability. So just be aware that the latest one is probably going to be the best for that. It’s not always possible to keep things up to date, I understand that. In an environment where you have so many dependencies, sometimes upgrading is not an option. From there, there’s other mitigations you can put in place - put something in front of it, or try to learn what the exact vulnerabilities are and find out the ways of mitigating it. So patching and keeping things up to date is probably one of the most important things and one of the easiest wins you can have. That applies to operating systems as well, and applications and libraries.

The second thing - and probably the most important thing - is input validation. Understanding that the input that you’re getting from a user is what you think it is, and checking that on the server, rather than on the client. Because client-side control can be bypassed very easily.

[28:01] In a browser, if you use a proxy like Burp or ZAP you can intercept the request, change the data after it’s left the browser, and then send it on and it completely by-passes any kind of client-side input validation. So checking that the information that you’re getting is what you think it is, and not some malformed input like a super long string to get a buffer overflow, or negative numbers when you don’t expect negative numbers, or special characters that you don’t expect… The best way to do that is to use a whitelist over a blacklist.

The difference between a whitelist and a blacklist means – a whitelist is looking for a set number of things that are allowed, whereas a blacklist is looking for a set number of things that are not allowed. The number of inputs that can be allowed through is significantly less when you use a whitelist, so you are much more aware and you’re much more in control about the data that comes through, as opposed to with the blacklist… Where there may be a ton of things that you haven’t even thought of that could come through and could get around your validation.

So input validation is probably the most important, because really any vulnerability, any exploit comes from user input. If you can control that, if you can find some way of mitigating that, you could probably reduce at least 50% of the vulnerabilities that you may have in place, which is huge.

The third one is output encoding, and this is more of a preventative measure. When you’re outputting data onto a web application, for example, if you encode it with HTML encoding, for example, by doing that you will then reduce the likelihood of something like cross-site scripting, which is essentially when an attacker can get JavaScript to run in a client browser through input they provided. So if you can encode those characters, then it won’t look like JavaScript and it won’t execute like JavaScript, it will just look like a string of gibberish, almost.

So doing patching, input validation and output encoding are three of the biggest things. There’s a few other things that I can just briefly mention, in case you’re taking notes and you want some more depth… One is hardcoded credentials in API keys. I think probably like four months ago it showed up on Hacker News that you could just do a search for password in Git pushes - you search that and you find thousands and thousands of Git commits that had a password in it, or had someone mentioning a password, or taking a password out of their application. So having those hardcoded credentials, especially in open source software, is trivial to find, and then someone could take that easily; they don’t have to have any skills, and they could just access your machine. So making sure you have a safe way of passing up strings and secure information and secrets to an application is important.

Then two other key things is authentication and authorization, so making sure that people are doing the things that they should be doing, and they’re allowed to do that and they’re gated from doing things they shouldn’t be doing. Then the last key point is encrypting data arrested in transit; making sure that you’re using a TLS over the web, you’re implementing a security certificate. Letsencrypt makes it super easy to do that now. And then encrypting it at REST, so using proven crypto, like AES or Bcrypt for hashing - just some examples.

I know that was a lot to take in, and I’m sure that a lot of people are probably gonna go back and review over that… But if you can just cover those things, just keep those in mind as you’re developing, I guarantee you’ll reduce at least 90% of the vulnerabilities that can be introduced in your application just from those things alone.

Mat Ryer: Yeah. So a similar kind of idea, really. And yeah, passing things in, making it deterministic… As I was saying, Roberto Klapis told me… Because I used to it with rand, random numbers. Same thing. So you’d just have a function that’s going to return a random number. In production you use the real crypto random thing; in your test code, you pass a new function in and you can just return the deterministic numbers.

And Roberto made the point, “Well, if in production your code is dealing with random stuff, maybe in your test code it should be as well.” And then I started experimenting with using actual real random numbers… Which you can sometimes do. And it depends on the case, again, as usual.

Kelsey Hightower: So one thing I have to realize is that I think a lot of times when people get money, they believe that they’re smarter than other people that don’t have money. So they think that their ideas should rise at the top. They’re obviously right about something, because their bank account reflects just how right they are. That’s the mistake. To me, I know that I’m lucky, and a lot of things could have went in multiple directions, and it doesn’t end up with this particular number. And so one thing I’ve challenged myself for the last maybe 20 years, “Who am I, and why do I believe what I believe?” That’s it. Sometimes I believe things because I didn’t have time to research them, so I had to just take them at face value, they were taught to me, I didn’t have time to challenge them, so I took them.

So these days, when I look at it, I try to humble myself, and be like “Kelsey, do not fall into the lifestyle inflation. Do not over-index on showing people what you have. It is okay if people don’t think you’re in the top X percentage of anything.” Remind myself that “Yes, you could buy it, but you don’t need to. What’s caused you to want to do that kind of thing?” And that helps me avoid the conspiracy. For example, if you say “I need more money”, you will be really mad that you pay taxes, because people are taking away the very thing you want. I don’t mind paying for the bridges, the highways, the medical stuff…

[01:02:05.01] Do I like the waste? Absolutely not. I’ve seen waste in enterprise, so I’m not surprised that there’s waste in government. So I don’t over-index in that, because I also know that people are hard to be very good 24 hours a day forever. It’s not happening, folks. So I’m a pragmatist when it comes to that stuff.

But the conspiracy theories - whenever one pops into my mind, I say “Kelsey, it’s time to do some research here. Before you start running your mouth, before you go on Twitter just saying random stuff…” For example, when I wanted to understand inflation, I had to go read The Monster on Jekyll Island, how the Federal Reserve was formed… Buy some, Treasuries actually buy Treasuries from Treasury Direct, look at the interest rates, look at the curve… Why do people start feeling a certain way when it goes up, start feeling a certain way when it goes down? Who buys them, who doesn’t? How big is the Treasury market versus the stock market? Treasury market’s dramatically bigger. Why is that?

So these are the types of things that I go into to just try to resolve the conspiracy components with actual facts. And then I just talk to people. “Hey, explain to me how this works, please, because I don’t know.” And then people give me insight, give me something I don’t know, they close the knowledge gap. And then I’ll test. So if I’m really afraid of something, I’ll test it. When the whole crypto movement was going, I was so afraid, because I saw [unintelligible 01:03:25.25] It doesn’t matter if things are logically correct or not. It don’t matter. If the world decides that we should all jump off our roofs, with no helmets, then just people start doing it. It’s like “Oh, what are we doing?”

V Körbes: Yeah, I mean, all the AI stuff, like the GPU stuff… Do we have that out of the box in Go? You’re gonna have to go hunt down your favorite library and waste a week trying to figure out which one’s the best. If we’re talking about, for example – you need some distributed stuff, like maybe an application running on a billion different places at once, then you’re going to need all the access control, you’re going to need all the encryption stuff… Let’s say you’re in the government, you’re going to need your crypto libraries to be compliant with for example FIPS, and a bunch of regulations like that… You don’t have none of that stuff out of the box. So I mean, I think honestly Go is just a really bad language in general, but especially for prototyping.

David Chase: [40:09] People don’t want it. It would be slower, and people don’t like slower. There have been people in the world of crypto who have asked for things like that - if I ever wrote an important thing anywhere in memory, how quickly could I get that zeroed after I’m done with it? So they kind of asked about that. And it’s been proposed. We don’t know what’s the best way.

Jerod Santo: Now, Chris and I teamed up for what was probably the best call of last year, if I do say so… Which is that Christopher Hiller, b0neskull, said he has a wishlist item. He says, “I kind of don’t want to mention it… It involves the something-chain, and I don’t want to mention the third version of the thing.” You know, the third version of the thing he doesn’t want to mention. But he really just wishes it would go away. And I followed that up to say, “I think we’re gonna see our next bubble burst, specifically around NFTs.”

December of last year was pretty much the top. I think November – you know, global markets, but I can’t remember when the crypto markets themselves went… But if we track the highs of the US stock market, November was the top. That podcast was recorded in December, and I think January was when things started to kind of show their weakness; crypto markets ever since then, February… I mean, it just keeps getting worse now. FTX, of course, causing another rash of value just gone… And I don’t think we’re done. There’s talks of Binance being the next potentially dangerous place to hold your cryptos… It’s bad out there, y’all.

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.

Amal Hussein: Yeah, this one’s a really hot topic, and coincidentally, I was having a conversation with some friends last night about this topic of like monetization on the internet, and how we really need to figure out a way to do this cleanly, through standards, because we cannot leave our content creators in the hands of companies like Google, that are just very – they have a very different, specific set of incentives, right? So this story is from Brave, it’s from the Brave Browser team. For those of you who are like “Brave, the browser?”, let me just give you a quick summary. So Brave is a browser that’s been around for a few years now. It’s been my primary browser on my personal machine, on my phone… It means some of my experiences on the web are not great as a result of it, because Brave is intentionally very privacy-focused, and they aggressively block trackers, and all that jazz.

One of the founders of Brave is Brendan Eich, who is the person who also created JavaScript, ECMAScript. And love Brendan, hate Brendan, it doesn’t matter. I’m just stating he’s one of the people involved with this project. He’s been a little controversial in our community lately… And Brendan – I was excited about this project, I still am, but there’s a crypto elements to this, which I have just always ignored… But there is something called the BAT, Basic Attention Token, and so the idea is your attention is time, and we could potentially show you ads in a private way, and you can earn and get BAT credits, and whatever else. I don’t really do anything with that personally, so I can’t speak to that… But for me, it’s just the best browser in terms of limiting your tracking footprint.

[13:53] And so what Brave came out with is this a bit like – they’re letting you now, just through the browser, opt out of those annoying cookie banners, right? …which are getting like infinitely more complex, right? Because it just went from Accept or Not Accept, to now it’s Accept or See the Options, that will bring a confusing menu that’s worded –

Matias Pan: I think it’s interesting, because it’s a context that probably a lot of people are finding themselves in. A lot of companies went through really crazy hyper-growth, and then all of a sudden the bear market hit, and they were left with this application that grew very rapidly, with a team that probably didn’t know much or at all about infrastructure, and a really big team, but not really all that amount of money that they can use to continue growing. And when you get to that point and you want to continue making your product better - because you’re not reaching hyper-growth, you’re reaching for the classical breakeven, or in a way making your product profitable - you will have to make a lot of decisions regarding your architecture and your infrastructure, that they all have to keep in mind that what you want to do is reach that breakeven. You want to actually be able to continue to deliver value to users, and hopefully, that value gives money back to you, and you can keep the company running.

So when I joined Lemon - Lemon Cash is the full name of the company - that was the exact context in which the company was in. There was a really, really big, monolithic codebase, that had so much code, from so many different domains. We’re talking about a bank/crypto, so it has a lot of things related to a bank, but it also breaches you into the crypto world. And not just like tokens, not just like currencies, but also like NF Ts, and the entire gamification that the crypto industry is trying to bring.

[05:53] So this was a big up. A lot of very clear, separated domains in this single place, and the entire infrastructure in which this was laid on was not something that happened on purpose. So it wasn’t far off. It was “Hey, we have to get this to production now. What do we know about it?” “Not much.” “Okay, there’s this thing called ECS, that they’re saying it’s serverless, and they’re saying it’s super-easy, and there’s this blog post that a big company wrote. Let’s just use that.”

And then when I joined, the company grew from 5 developers to 300 people, which brings a lot of really different problems where you’re working on that monolithic codebase… And the idea of going to a service-oriented architecture was kind of natural, in a way. And when I say natural, I don’t mean that it’s the obvious choice. It’s going to depend on what context you’re in. But we’re talking about a bank that has the most critical thing at hand, which is money. And you always want that bank to work perfectly. So for a bank, the idea of services allows you to separate the failure domains in a very clear way, and make sure that the product is the best thing that you can do.

So yeah, the decision itself had already been taken, and when I joined, they were already discussing about going into a service-oriented architecture. But there were no discussions around the infrastructure side of going to that architecture. And for me, at least, that’s the biggest problem you have to at least think about and solve in part, before actually committing to that. It’s perfectly fine to start separating the code, understanding the domains and doing that exercise, but when you want to actually execute that, solving the infrastructure part, the observability part, the monitoring, how you get things to production, how you operate on those services, how do you have on-call policies - everything related to having a service in production also needs to be discussed.

So that’s where this proposal that you mentioned came to be. It tries to tackle how you should be deploying services, at Lemon specifically - that’s why it’s in the title - and it puts that in the context of all these other things that we also have to solve in order for the company to operate services gracefully, I would say, in production.

Tammer Saleh: [11:48] Yeah. We have a couple of clients who are attacking on-premise installations for their product. They have a product that they run, but they want to deliver it to other companies, on-premise, in the other companies, AWS accounts, or even bare metal, or whatever. And the interesting thing about Kubernetes is that it is becoming that ubiquitous platform. It is becoming that assumption that you can make, that if I’m going to go on-premise, I want to target Kubernetes, because that’s going to hit 80% of my potential customers. That’s easily becoming the case. And going on-premise is very difficult, even with a substrate like Kubernetes to lean on, because often you get zero telemetry, right? You get no metrics, no logs, no hands on the keyboard, you can’t kubectl exec into something and fix it. Usually, with these engagements, or usually for our clients, their customers are highly regulated, highly secure companies, that have very strong security postures.

And so what our clients need is not only to believe that what they are going to be deploying into their customers’ Kubernetes environments are well-engineered and using all of the best practices from Kubernetes’ point of view, but often, they also need a lot of custom code developed in order to do health checks. For one customer, we actually built a dashboard that their customers can go to and see the health of their application, but also the health of the underlying cluster, basically, so that their customers can self-select into, “Should I file a ticket? Or is it actually a problem with our own cluster, and we need to go to our own operations team?” That kind of thing is fundamentally important.

When we were at Cloud Foundry, we have so much experience with the headaches of trying to ship on-premise that we just naturally – that’s why we ended up with all these customers doing it, because we just had that experience already.

Another fun example is we had a crypto client who wanted to integrate AWS Nitro secure Enclaves with EKS. And the Nitro Enclave thing is a really interesting technology where you can run verified code in a highly secure hardware-based environment that has to be built into the chips on the actual machines that AWS gives you. And even AWS engineers cannot access the memory for that code, but using it is a huge pain. I mean, using it is incredibly difficult. And the code that runs inside this secure Enclave cannot do things like network, or anything. You can only communicate with it through this weird VSOC that happens at the kernel level. And so integrating that with EKS turned out to be very challenging, and so they brought us on board to help out with that. And as it turns out, we were, I think, maybe still the only people who have done that integration, the only people who have tied EKS and Nitro together so that you could launch a secure Enclave from a pod, and communicate with it directly from that pod. And we know that because we actually had to work with the AWS engineering team to get it done. And it was a lot of fun, and we blogged about it, and the engineers loved that work. It’s part of the reason why we can attract such senior talent, is because we get to work on the more interesting projects like that.

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.

Feross Aboukhadijeh: Thanks. Yeah, I mean - the only thing is I really wish that we could show people the code so they could have even more assurances that it’s doing what we say it is. That’s the part that I think we’re gonna try to solve by doing an audit; we’re gonna hire an actual team of people who know what they’re doing, who do security audits for a living, to take a look at the code.

This is also what 1Password does, because they’re also closed source, and they’re security software, so people need to know that the design – well, they did open source their design docs, which we’ve also done, to some extent. We have information on our website about the design of the crypto. All the things I just talked about are all on the website. So the design is there, but the actual implementation itself - the best we can do for now is just to audit it, just like 1Password does.

Patrick Ecker: [48:07] Yeah, yeah, sure. And companies like TinyMCE - they are building a rich-text editor platform with ReScript, and for that it’s also fantastic. These really complex domains - this is where ReScript shines.

On the team, we’ve got, as I said, Hongbo Zhang, who is now also working for Facebook, Cristiano Calcagno, who is one of the cleverest scientists I know. He has been working on the Infer project, if you know that, for code analysis and static analysis of all kinds of languages. He has huge knowledge about analyzing code, which is great for us, because we have a lot of dead code elimination analysis going on right now for ReScript, because it’s fully typed. Super-nice to analyze.

We’ve got Cheng Lou, who has a huge vision on products, and designs, and lean, clean interfaces. I love that as well. Maxim Valcke, who is our master brain on the syntax level. He has been investing so much time into writing a syntax parser that is efficient and small. It’s super-fantastic work. And myself, of course, for working on the documentation; I’ve been doing this within the ReScript Association, as you already mentioned. The ReScript Association was founded with the goal to support the community and support a language with financial infrastructure, so people can send donations to it who are relying on the technology. So if you are a company who wants the language to succeed, the best way to invest money is to invest it in the association. They’re reallocating the money for developing the documentation, growing the editor tooling, working on core essential libraries, finding other projects, organizing conferences… We had like two conferences already - ReasonConf 2018 and 2019, and also a Reason conference in the U.S, which will most likely of course be rebranded to ReScriptConf.

So in the past 2,5 years we also collaborated with research institutes and companies, we collaborated with Ahrefs, which I already mentioned, with the Tezos cryptocurrency - they’re also really invested in this, because they want their crypto wallet apps to be stable, and they chose ReScript for their web frontends, and stuff like that. Or subsidiaries of Tezos, of course. Tezos is a huge project.

So this is how we try to set a foundation for the language on the community side, on the open source side, but also we have a strong commitment on the business side with the core team, who is working at Facebook, and all other companies that depend on it.

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, so we were using the built-in crypto stuff in Objective-C that Apple provides, and the same in Java, that Android provides… And we’ve just recently actually moved across to Rust; so we’ve removed all of that, and now the crypto library is built into Rust, and it’s the same one which is deployed to both Android and iOS. But that is using Rust’s core crypto library, so again, nothing that we’ve rolled our own; it comes with the base system. We’re very confident that we’re using the best and the safest there, but now we’re back to having one build for multiple devices, so it’s a little bit nicer to work with.

James Snell: There’s two things there. With HTTP/1 in Core right now, a number of design decisions were made early on to favor performance over spec compliance. It turns out that there are a number of compliance things in the spec that says “Don’t allow white space in headers”, right? And there’s very good reasons for that, because you get into request smuggling and response splitting, and there’s a lot of real specific security issues that come if you allow invalid characters into an HTTP/1 request. Node was like, “We want things to go fast, so we’re not gonna check this, we’re not gonna check that”, and it was a very deliberate decision not to fully support that HTTP/1 spec. And what we found is that that caused a number of security issues that we have been dealing with over the past year or two years.

With HTTP/2, we’re gonna be taking an approach where we’re gonna be very spec-compliant. We’re not favoring performance over that. We’re not sacrificing one over the other. It is going to be absolutely compliant to the specification, without taking those performance shortcuts. And that is something that I am emphasizing in my own development as I’m going through this, that making sure that we’re hitting all of those “You must do this” or “You must not do this” that are found in that specification. By adhering to the spec as closely as we possibly can, we mitigate a lot of those potential security issues.

[11:47] The other important thing is that even though HTTP/2 does not require TLS - per the spec you can do plain text if you want - the browser implementation’s the primary client of HTTP/2 right now… Chrome, Firefox, Safari and some of the others, they require that they will only talk to HTTP/2 server over TLS. It’s just mandated. They won’t even connect to a plaintext server, so automatically out of the gate you’re using secured connections, and that alone is going to be a significant improvement to security.

The one limiting factor there is Node hasn’t really had a great reputation as a TLS terminator. A lot of people, just as the best practice, put a proxy in front of it, and then they’ll reverse proxy back over a plaintext connection back to Node just to ensure the performance. A lot of that has to do with the way the crypto works with the event loop and OpenSSL and that kind of thing. So I think a lot of work is gonna need to go into trying to improve that if we want to improve the performance of Node as a TLS endpoint and improve on that story.

James Snell: There’s two things there. With HTTP/1 in Core right now, a number of design decisions were made early on to favor performance over spec compliance. It turns out that there are a number of compliance things in the spec that says “Don’t allow white space in headers”, right? And there’s very good reasons for that, because you get into request smuggling and response splitting, and there’s a lot of real specific security issues that come if you allow invalid characters into an HTTP/1 request. Node was like, “We want things to go fast, so we’re not gonna check this, we’re not gonna check that”, and it was a very deliberate decision not to fully support that HTTP/1 spec. And what we found is that that caused a number of security issues that we have been dealing with over the past year or two years.

[11:46] With HTTP/2, we’re gonna be taking an approach where we’re gonna be very spec-compliant. We’re not favoring performance over that. We’re not sacrificing one over the other. It is going to be absolutely compliant to the specification, without taking those performance shortcuts. And that is something that I am emphasizing in my own development as I’m going through this, that making sure that we’re hitting all of those “You must do this” or “You must not do this” that are found in that specification. By adhering to the spec as closely as we possibly can, we mitigate a lot of those potential security issues.

The other important thing is that even though HTTP/2 does not require TLS - per the spec you can do plain text if you want - the browser implementation’s the primary client of HTTP/2 right now… Chrome, Firefox, Safari and some of the others, they require that they will only talk to HTTP/2 server over TLS. It’s just mandated. They won’t even connect to a plaintext server, so automatically out of the gate you’re using secured connections, and that alone is going to be a significant improvement to security.

The one limiting factor there is Node hasn’t really had a great reputation as a TLS terminator. A lot of people, just as the best practice, put a proxy in front of it, and then they’ll reverse proxy back over a plaintext connection back to Node just to ensure the performance. A lot of that has to do with the way the crypto works with the event loop and OpenSSL and that kind of thing. So I think a lot of work is gonna need to go into trying to improve that if we want to improve the performance of Node as a TLS endpoint and improve on that story.

Cory Doctorow: Sure. As I mentioned, I’ve got an eight-year-old and she was born in London in our flat in a pool in the living room. She likes to hear the story of her birth, right? So we would tell her the story of her birth… My wife told her she came and yanked on my arm and shouted, “Story arm”, that I would tell her a story. So she runs up whenever she is bored and she yanks at my arm and yells “Story arm!” And being a writer, I like to iterate when I tell stories, so I’d tell them a little differently every time. I’d start a little further back or go a little bit further forward.

What I realized was that the interesting part of her birth story was the stuff that led up to her birth, and not like the stork stuff, but the stuff about how my wife and I met and became best friends and lovers and a couple, and got married and decided to have a baby. You know, all of that stuff is unique; the stork stuff is the same for everybody. What your parents did to make you is almost certainly something I can guess at with a pretty high degree of accuracy, right? But how your parents came to make the decision to do that and make you - everyone has a different version of that.

[20:08] The open source version of how we got here, we talk about the licenses and we talk about the packages and milestones, but there’s like this really strong social component to how we got here, because around the same time that the open source movement was starting, it was also around the same time that the open web movement was starting, that we were sun setting these proprietary network architectures - whether those were the ones the phone companies ran… You know, AT&T circuit-switched services-centric network or the big commercial services like Compuserve in AOL… They both kick-off around the same time, and yet the open web has collapsed, the open web is almost dead.

We are in a desperate and dire moment for the open web, and the free and open source software movement has soared; everything, including the things that are closing down the open web is built on free and open source software. So that is an amazing thing, and the speech kind of interrogates what the difference is, and how one soared and the other sank, and what we can learn from the free and open source movement to keep the web open as we try to open it up again.

I think the thing that the free and open source software movement had going for it is this thing called the Ulysses Pact. The story of Ulysses goes that Ulysses was gonna sail into siren-infested waters and anyone who heard the song of the sirens would be tempted irresistibly to jump into the sea and the sirens would drown them. So normally, when sailors sailed into the siren sea, they would fill their ears with wax. But Ulysses was a hacker and he wanted to hear what the sirens’ song sounded like, so he had his men lash him to the mast so that he could hear it, but he couldn’t get loose. So what he used was his strong self, the moment at which he was strong, to predict that in a future moment he would be weak and to take countermeasures to prevent himself from giving into that weakness. We use Ulysses pacts all the time - if you go on a diet, you should throw away your Oreos away on night one; not because you’re like incapable of resisting temptation, but because everyone sometimes has moments of weakness, and the strongest thing you can do is to recognize that you will have a moment of weakness in the future and take a countermeasure against it.

In the free and open source world, our Ulysses pact is the irrevocable license, because the failure mode of free and open source software, having founded a free and open source software company, I can tell you is that there are moments in which it feels like your survival turns on being able to close the code that you had opened when you were idealistic. There are moments of desperation when that happens.

Of course, it’s ridiculous, because if you’re making anything substantial under free and open source software, you’re building it on other things that other people have opened and can’t close, and if they were to close off their code your project will collapse. So every one of us wants to be the only one who can revoke a free and open source software license, while all the plumbing that we built on top of stays open. Because the licenses are irrevocable, because you can’t close it once you opened it, you generally don’t even get the pressure from your investors or from potential acquisition suitors or from other parties who can otherwise lean on you and put a gun to your head - they don’t even bother, because there’s no point in shouting at you to close the code, if they know that it’s not course of action that’s even open to you.

[23:44] So even though the same desperation that led us to close the web is present for everyone who’s ever made an open source project that succeeded, that desperation can’t express itself in the same failure mode that the web has had. So my talk is about how we can build a Ulysses pact for a newly opened web around two principles that will keep the web open even in the desperation of its founders, even when the pirates who founded it become admirals.

The first principle is that any time a technology or computer gets an order from its owner that conflicts an order that’s been given to it by a remote party, the owner should 100% of the time without exception win. The owner always gets to overwrite remote policy.

The second one is that any true fact about the security of a system that you rely on should always be legal to disclose, under every circumstance. My pitch is that these two principles should the principles that we become zealots for; that if they’re not calling you an unrealistic idealist about your adherence to these principles, then you’re probably not trying hard enough. So my pitch is that the people who care about building an open web to be the nervous system of the 21st century, to have an Internet of Things that’s not an Internet of things on fire that spy on you and ruin your life, is that we need to like take these principles and cherish them as much as we cherish the core principles of free and open source software, and weave them into our licenses, into our professional codes of conduct, into our membership agreements, into every single piece of what we do, so that there’s never any question that this will come about.

There have been lots of times when the governments have tried to pass laws that say “In order to make software, it has to be closed” and the fact that there’s all of this critical, open software has meant that those laws died every time. Because you’re going back to them and saying, “Well okay, but what you’re talking about is throwing away all the infrastructure on which the digital world is built. What are you planning to replace it with when you pass your dumb law?” You know, reality asserts itself, and so if we can create a reality on the ground to assert itself when governments contemplate stupid laws that say that remote parties can override local parties, whether those are crypto backdoors, or DRM, or lawful interception overrides, or any of the other things that have been the parade of horribles of the 21st-century, then we can make a difference.

Max Howell: Well, you’re totally right that a lot of developers are very anti-crypto, and so it’s been a battle from the start. Hacker News hate me even more than usual. But inside the cryptosphere, it’s very popular. Like, 1.7 million signups is pretty unheard of. And what it turns out to be the case, to my surprise… I’ve spoken to over 300 open source devs over the last three years, just for market research reasons. A lot of them don’t care if it’s crypto or not. They like crypto in the respect that they like technology. Open source devs aren’t as anti-crypto as the others, the rest of the devs. And yeah, I think we have a reasonable chance of showing that crypto is just a technology. We’re not a scam. There’s nothing scammy about what’s going on with us at all. They’ll see that once we’ve gone live and no one’s rugging the token, or anything like that. And it’s all open. That’s one of the beautiful things about Web3. All those smart contracts are transparent, readable. You can see what’s going on.

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]

Nicola Murino: [00:52:17.22] People are often worried about not real vulnerability. For example, I remember some people asking us to update net HTTP in x/crypto repository. But it was basically unused. So even if that package was vulnerable, that vulnerability is not exploitable in the crypto SSH. It was used only marginally in the package. This is very hard to explain to people, because they run an automatic scanner, and the automatic scanner triggers a vulnerability, and they are alarmed. They want all the vulnerabilities fixed very quickly. But by doing so, there is the risk that we introduce untested features, because we are always on the bleeding edge, or we always use a new package that people haven’t enough time to test, and about regression, and such things.

Filippo Valsorda: Anyway, bringing it back to Go. What are we doing with QUIC in Go? So at the bottom of this cake of layers there’s TLS, because they very correctly did not reinvent cryptography, and they just said “So we need some keys… So what we’re going to do is run the TLS handshake over QUIC, and then we’ll take keys out of TLS and then we’ll reinvent cryptography and do our own cryptography for transport.” But they had good enough reasons for that, and the hard part is the handshake. Once you’ve negotiated keys, the rest - you need to make little wrapper packets and put a bow on it… But it’s easy enough.

So they run the TLS handshake over QUIC, and then they extract some stuff. Now, the problem is that our crypto TLS package was made to run TLS handshakes over TLS and over TCP. And we didn’t want to have a fork in the QUIC implementation, because that’s bad, but we also didn’t want to add a million options to crypto TLS. So Damien Neil and Marten from Protocol Labs –

Shawn Wang: That is a short-term business model, yeah. I bet they have much more up their sleeves… I don’t actually know. But they did just hire their first developer advocate, which is interesting, because I think you’ll start to hear a lot more from them.

[58:12] Well, there’s two things I will offer for you. One, it’s a very common view or perception that AI is a centralizing force, right? Which is, Adam, what you’re talking about, which is, “Does this just mean that the big always get bigger?” Because the big have the scale and size and data advantage. And one of the more interesting blog posts - sorry, I can’t remember who I read this from - was that actually one of the lessons from this year is that it’s not necessarily true, because AI might be a more decentralized force, because it’s more amenable to open source… And crypto, instead of being decentralized, turned out to be more centralized than people thought.

So the two directions of centralized versus decentralized - the common perception is that AI is very centralized, and crypto very decentralized. The reality was that it’s actually the opposite, which is fascinating to me as a thesis. Like, is that the end game, that AI eventually gets more decentralized, because people want this so badly that there are enough researchers who go to NeurIPS to present their research papers and tweet out all this stuff, that diffuses these techniques all over the place? And we’re seeing that happen, helped in large probably by Stability AI. The proof that Stability as an independent, outsider company, like not a ton of connections in the AI field, did this humongous achievement I think is just a remarkable encouragement that anyone could do it… And that’s a really encouraging thing for those people who are not FAANG and trying to make some extra headroom in this world. So that’s one way to think about the future.

The second way to think about who monetizes and who makes the billion dollars on this… There’s a very influential post that I was introduced to recently from Union Square Ventures, called “The myth of the infrastructure phase”, which is directly tackling this concept that everyone says “When you have a gold rush, sell picks and shovels”, right? And it’s a very common thing, and presumably AI being the gold rush right now, you should sell picks and shovels, which is you should build AI infrastructure companies. But really, there are tons of AI infrastructure companies right now, they’re a dime a dozen; really, they’re all looking for use cases, and basically, the argument, the myth of the infrastructure phase is that technology swings back and forth between app constraint and infra constraint. And right now, we’re not infrastructure-constrained, we’re app-constrained. And really, it’s the builders of AI-enabled products like TikTok that know what to do with the AI infrastructure that can win.

So I’ll introduce those concepts to you… I don’t know what specifically that means. I’m looking out for opportunities like that myself. But I think it’s apps; I think it may not be infra, because it’s going to trend very, very hard towards commodity infrastructure provisioning, and I don’t really care where I get my A100s from… A100 being the predominant NVIDIA chip that is being used to train all these models… Which, by the way, costs $200,000 per chip, which is insane. Imagine a GPU costing that much.

Tim Stiles: I really love them. Oh, by the way, anyone listening out there, if you haven’t been to Gitpod’s Discord, go. They’re super-friendly. Just show them your work, with whatever you’re doing. They’re super-excited, supportive and ask a lot of questions. They’re really, really nice.

But when I got started, Go is like test-first; all the things you need… Like example tests are actually a great thing, where Python or a lot of other languages – like, maybe there’s a library for it, but in Go it’s just standard. Whenever I write an example test, it runs every time I’ve run my tests, and it’s an example that never does doc rot. The problem with doc rot, with a lot of scientific software is big, because people will write these huge things, the documentation, then they’ll change the API like two versions down, and then they won’t change the documentation.

And so I think the fact that Go has all these opinions, which if you’re like a – I guess you would call it like a gray beard or white beard software engineer… Like, maybe you have different opinions, but if you’re just starting out and you don’t really know where you’re going DevOps-wise, Go’s defaults are beautiful; they work. And yeah, you may struggle with generics, which Go has obviously been working on, which I think scientists will have a little bit hard time going into typed languages… They don’t have that much of a hard time. But the thing that when I was originally considering writing Poly, I was looking at what could be compiled to a binary, because I thought it was gonna be more of a command line tool. Eventually, I was like “Wait, this doesn’t make any sense as a command line tool.” But originally, I thought it was gonna be more of a command line tool… So I was like “What compiles to a binary, what’s easy to learn, what’s fast, and what has like a good DevOps ecosystem?” And it pretty much came down to like Rust was a little faster, but Go won on everything else. And that’s kind of what I needed.

I don’t know if you’ve ever done like string manipulation in Rust, but it’s hard. It’s not something you want to teach the people coming from Python. And maybe there’s a good reason for that, but I did not personally enjoy it. So when I was testing those two, it came down to Go winning on almost everything. And I think it’s also just a great step from what would be considered these scripting languages, where the syntax is easy enough, the concepts are still there. I mean, yeah, you can get into concurrency and all this other stuff, but coming from R and Python, you have to learn that anyways. You’re not learning multi-threaded stuff, and what most scientists use for languages, which are – usually, most scientists are using Python, R, MATLAB and Giulia, which - actually, Giulia does have multi-threading, a lot of modern features. But Go just has a bigger breadth, and a bigger DevOps community, and a better community of people that use it, which actually makes it really easy to find odd functions that I need.

One of my contributors convinced me that we need to use [unintelligible 00:37:33.08] is the default, and so Go’s crypto library doesn’t have that yet, so some guy wrote a working implementation and we just used that. Lua didn’t have that, so my friend who wanted to implement it in Lua had to go and write BLAKE3 three by hand. He’s like, “I don’t understand this. It’s all a bunch of math and single-little letter variables.” I was like, “So now do you realize why I make you write all your variables as whole words?” He’s like –

Asim Aslam: He’s right, there’s no new idea. It’s just about the timing. Usually, things show up a decade too early, and then they get tried again, and then something works. To me it’s sort of desktop, web, mobile, cloud, and then there’s some next piece, which is like edge, or networks, or something like that… And it keeps going, where we get to this ambient computing model where technology is everywhere and you actually no longer even carry around devices. It’s just like always on, it’s everywhere, it’s embedded in the world.

But networks - networks is a thing for me that exist beyond cloud. Some of that infrastructure is being done in this kind of blockchain, peer-to-peer cryptocurrency stuff… But you’re right, it’s like early internet, where they were defining the protocols, they were figuring out the use cases, there was no clear – once we started to develop the browser, that’s where the web really took off, and then the use case took off for the internet. But crypto doesn’t have that thing yet. I mean, people think it’s money, like banking and infrastructure, but… Right now, I’m more focused on this kind of cloud thing, which - a lot of it has been driven around centralized platforms, which is fair enough…

I just think GitHub really works for source code at rest, and you know, all these companies – and what you find is these things that exist inside of companies come out of the companies and become a social platform. Not just in terms of public social networks, but developer tools. So you’re looking at it as like “Okay, we have a public Git server that everyone can share code on.” The next - it’s quite possibly gonna be some sort of platform on which you host that code, that’s an entirely public and shared experience. Right now we look at cloud providers as that, but that’s not really that. That’s not social. Cloud providers is a personal [unintelligible 01:27:42.25]