The Changelog: Software Development, Open Source - Exploring Deno Land 🦕 (Interview)

Episode Date: June 8, 2021

This week we're joined by Ryan Dahl, Node.js creator, and now the creator of Deno - a simple, modern and secure runtime for JavaScript and TypeScript that uses V8 and is built in Rust. We talk with Ryan about the massive success of Node and how it impacted his life, and how he eventually created Deno and what he's doing differently this time around. We also talk about The Deno Company and what's in store for Deno Deploy.

Hey, welcome back. You are listening to The Change Log. We feature the hackers, the leaders, and the innovators in the world of software. Today, we're joined by Ryan Dahl, Node.js creator, and now the creator of Deno, a simple, modern, and secure runtime for JavaScript and TypeScript that uses V8 and is built in Rust. We talk with Ryan about the massive success of Node and how it impacted his life, how he eventually created Deno, and what he's doing differently this time around. We also talk about the Deno company and what's in store for Deno Deploy. Big thanks to our partners, Linode, Fastly, and LaunchDarkly. We love Linode. They keep it fast and simple. Check them out at linode.com slash changelog.

Our bandwidth is provided by Fastly. Learn more at fastly.com and get your feature flags powered by LaunchDarkly. Get a demo at LaunchDarkly.com. This episode is brought to you by our friends at Influx Data and their upcoming IoT application training, you'll build a fully functional sample application called IoT Center and build it on InfluxDB with functions such as the new IoT device registration and IoT device emulation. This demo app is based on Node.js and React, uses Kafka to write measurements, and requires NodeDB installation with InfluxDB Cloud. Space is limited and it's free to join, so register now at influxdata.com slash changelog to save your spot. Again, that's influxdata.com slash changelog.

Well, we're here with Ryan Dahl, creator of Node, creator of Deno. Ryan, we're big fans of you, and we're so happy to have you here on the show. Hello. Glad to be here. I think this is a first. Yes. You've never been on the Change.org before, right? Even back in the day.

Nope. Never. We've only talked about Node, not about the creator of Node. Yeah, we've talked talked about node but we haven't talked of course what a shame here we are to fix that well 10 years later or ish welcome thank you yeah i think this is only the second podcast ever i've done oh wow is that right well thank you for giving us part two of that that's right we're honored so you're not here to talk about node. You're here to talk about Deno. You've rearranged the letters. You've been hard at work for a couple of years now. And I would like to go back to your JSConf EU talk, which has become famous now in 2018.

The 10 things that you regret about Node.js, which turned out not being 10, it seems like. I don't know if you even named it that or they named it that on the YouTube file. Cause it was like seven. And then you introduced Dino and I was going through it trying to find. They named it that. Yeah. It was not 10. Yeah. That's just the way they named it on YouTube. Like, I don't even think your slides are like one, two, three, four, five, six, seven. That's close enough to 10. We'll just call it. Yeah. Round numbers and lists apparently work, you on the internet so somebody threw 10 on it yeah if you go to the titles if you like look at that talk and see the title slide it has a completely different title it's not 10 things i regret about node well good because you had seven of them and it seems like that was a talk that was put together somewhat

last minute maybe because dino wasn't quite as far along as you hoped it would be or what was the backstory on that because even in the beginning you said this wasn't quite as far along as you hoped it would be? Or what was the backstory on that? Because even in the beginning, you said, this wasn't my talk, but now it is my talk. Was that the thing is Dino wasn't quite ready to give more of a fleshed out version of it? Yeah, I was working on a different project. And I had applied to give this talk on this other project. It was something very similar to TensorFlow.js. So it was TensorFlow binding to Node so that you could train machine learning models in Node. Plus, something that's like Python's Jupyter Notebook, or in JavaScript, there's this Observable company, like a website where you could kind of insert a bit of code and plot functions and stuff. And yeah, TensorFlow.js

and Observable actually came out just before that talk. And a month before that, we decided like, actually, these projects are kind of dead end, or we should do something else. And JSConf insisted that I continue to give a talk on something else. So I put together this Deno demo. Nice. So there's a this Deno demo. Nice. So there's a bunch of stuff about Node. Anytime you make design decisions, you know, in retrospect, it's easy to look back and it's hard not to find flaws

in things that we create. But we don't always get a second shot at it. You know, and Deno seems to be to a certain degree, a second shot or at least another round of something different but similar. And I'm just curious of the seven or so things there that you listed which if you don't remember they're sticky not sticking with promises the

security system which i think you definitely are addressing with dino the build system package json node modules those are a few things just high level that you mentioned that were regrets how many of those do you feel like you've alleviated with dino how many things did you fix i mean all of those things i think you know generally dino is an effort to move the server-side javascript platform forward in kind of radical steps node has a lot of users, of course, and they try very hard to maintain backwards compatibility, which is laudable and great for all of the users of it. But that means that it's very slow in taking on new changes. And, you know, I think the major change in JavaScript over the last couple of years, maybe two major changes are async await syntax and the

ES modules syntax. These are pretty radical changes to the language. And you know, JavaScript is like this evolving system over time. The JavaScript of today is nothing like the JavaScript of 15 years ago. And yeah, it just felt like Node was not keeping pace with web browsers in terms of bringing on these new features. So now you're a few years into Deno. We've hit 1.0 last year. Lots going on, lots formalizing. I'm wondering now, since you've gotten into the weeds for a couple of years, you look back, have you made any mistakes so far? You had seven or so with Node that you regretted. Any regrets with Deno yet? Yeah, definitely. I mean, it's hard to make software and not make mistakes, of course.

Totally. I mean, this is going to be very controversial, but the TypeScript aspect of Deno, Deno has TypeScript compiled into it, is super nice, very friendly, very nice to be able to just get up and started easily. But browsers do not support TypeScript. And Dino's overarching philosophy is that is bringing server side JavaScript closer to browser JavaScript. And in this aspect of supporting TypeScript out of the box, we are kind of overstepping our goals. So, you know, we're supporting this extension to JavaScript. I mean, I don't know about you all, but I feel like TypeScript is eventually what JavaScript is going to be. I feel like it is kind of the next generation of JavaScript. And, you know, I'm very eager, and I think many people are to kind of go in that direction. But it's a big complication to our system to support TypeScript. And I think weakens our argument that Deno is web compatible.

So yeah, we're certainly not removing it now because, because Deno depends on it. Right. Go back and start over, would you? Yeah. But yeah, I think it would have been easier for us to get started had we not supported that out of the box initially. That being said, it seems like it was also a big draw and a big differentiator at first. Absolutely. Let me just say that I was around when you announced Node

back in 09 or whenever it was. I remember it was right around the iPhone time. And I remember the reaction to Node. Probably not as well as you do, because you were on the project. I was just was right around the iPhone time. And I remember the reaction to Node, probably not as well as you do, because you were on the project. I was just an innocent bystander. And maybe we remember it differently. But to me, it was like immediate. It was a hit. Everybody was excited. We had Michael Rogers just on the show a little bit back, and he was just reminiscing a little bit how like nothing existed for Node. Like when Node came out, you announced it, there was no ecosystem, there was nothing. And then everyone just piled in, people saw fertile ground. And you're looking

at me a little weird, like maybe that's not how you remember it, but it seemed like people came in droves to fill out that ecosystem. It just was like immediately a hit. And I think it filled a real need. First of all, let me stop and say, did you have that same feeling or am I seeing it through rose coloredcolored glasses? I think that's a fair characterization of what happened. Adam, you were around. Yeah. Node was huge immediately,

like maybe not immediately, but like people were very excited about Node, right? Yeah. Well, I think there was a lot of things even like with Walmart Labs and Black Friday. This wasn't back in the 2009 days particularly, but there was a lot of inertia around, you know, high traffic websites and scalability and, you know, it's enterprise ready. So a lot of different enterprise teams were happy to move on to something more modern, despite these seven flaws, as you've described in your talk, you know, because I think every step forward is a good step forward, even if it's got some flaws.

Sure. Software has flaws got some flaws. Sure. Software has flaws every single time. Yeah. So I guess my point is, is that it filled a huge void and it got a huge rush of enthusiasm and adoption because of that. And then Deno comes out and it doesn't come out into that same moment in time, right? It comes out later where you have a mature node ecosystem. You have millions of packages on NPM. You have people doing this full-time careers and consultant.

I mean, there is a thriving Node ecosystem already. And so into that milieu or that culture, Deno has to set itself apart, right? And TypeScript was one of the ways that it kind of did that to start. What were the other big ideas that Deno has that sets it apart from everything else? First important aspect is that it's written in Rust instead of C++. Node is a very large C++ project. And I'm not sure how you guys feel about this, but I'm very convinced that I will never start another C++ project. Rust really solves the C++ problem, as it were.

I think that there's many great things about Rust. But the thing that is most important to me is the ability to have a single build system. So this cargo system of linking together different Rust crates. In C++, there's no one defined way of how to take different C++ libraries and smash them together. So, you know, Chrome has this GN project. Node uses this JIP project. There's CMake. There's a lot of different tooling for kind of compiling together dependencies in C++. And this ends up being a huge, huge complexity in terms of bringing in external

third party code into a big project. And so, you know, in node days, when we want to, you know, we built a web server, and like, you know, you have to parse HTTP. And it's such a difficult problem that we ended up writing our own HTTP parser for this. It's so difficult to bring in external code that you end up often having to just write the stuff over again, because it's so difficult to link. And this is very different in Rust, right? If I need a YAML parser, if I need an HTTP server, any sort of third party stuff, I would do what people are used to doing in JavaScript or Ruby or Python, you can just kind of include dependencies and have this all compiled together really nicely. And that's an important aspect for a platform like Deno or Node, because, you know,

we provide all of these APIs to do various things, right? You want to open a web socket, you want to have an HTTP2 web server, all these various systems that it talks to need implementations. And it's very nice that we're able to just link in third party implementations of all these various systems pretty easily. So from a maintainer's perspective, rewriting it in Rust is a really killer feature that kind of allows us to iterate much, much quicker. Yeah, maybe a kind of a feature that end users don't appreciate as well as the authors and maintainers, but they will appreciate over time as you are allowed to continue at a certain pace that you know the c++ ecosystem didn't allow with node or maybe at a certain point dino will also get so many lines

of code and so much stuff in it that i mean it will slow down and any project that's mature is move slower than when it's young but maybe you'll keep a pace that's keeps your users happy sure just talking about other aspects of Deno kind of internally that are important is the binding interface, kind of the boundary between JavaScript and the native language, in this case Rust,

in Node's case in C++. Node was fairly ad hoc at adding bindings. We just kind of added them all over the place. There was no set system for calling from JavaScript into C++ and vice versa. And in Deno, there's a system for this. We call them ops. And so this kind of organizes all of the various bindings that you have to the system facilities really nicely.

And in particular, organizes all of the async calls that you might make. So ops in our system are either a synchronous function, like a function you call into Rust and it returns a value immediately, or it's an async function, which returns a promise that eventually resolves to a value. And so one of the really nice aspects in Deno

is that everything is organized as promises. It's kind of promises all the way down. There's not kind of random callbacks that happen throughout the system. This was actually a pretty big design mistake. I forget if I did discuss this or how much I discussed this in the talk, but WebSockets are on my mind right now because we're doing a lot with WebSockets. WebSockckets have this on message callback, right? And one of the problems with this is that you can't really stop the system

from giving you new messages. You can just get flooded with these callbacks. There's no way to kind of throttle this incoming stuff. And so because of the inability to stop these new messages coming in through this web socket, you can get into really bad situations where you're always handling the newest web socket message because you're getting flooded from this one socket, say. And this is not specific to web sockets. This happens in different parts of the system. That's quite bad. This actually causes pretty, this manifests itself in kind of bad tail latency situations where, you know, usually the system is fine, except under pressure when like suddenly, like, you know, one part of the system is getting flooded with these callbacks. And so you start getting really bad latencies. WebSockets in particular have, there's a new standard out called WebSocket Streams, which addresses this, allowing you to create some back pressure that is to not accept the newest message if you're not ready to handle it.

And in general, this async await paradigm syntax and the usage of promises everywhere generally kind of solves this problem. Because as long as you're always getting these promises and you're awaiting them, you're kind of solves this problem because as long as you're always getting these promises and you're awaiting them, you're kind of stopped at a certain line. You're not kind of unboundedly accepting new callbacks from the system. Anyway, that's all to say that Deno is promises all the way down. And so kind of from the fundamental layer, we've tried to deal with this back pressure problem. Another big differentiator is the package management story, right?

That's right. Tell us about how Deno sees the world of packages. So, yeah, I mean, I would bring this back to, in general, Deno is trying to use web APIs. We try not to introduce invented APIs like I had to do in 2009 when I started Node. There's just a lot of APIs that were, you know, there was no module system. And so we invented this require syntax to link to JavaScript files together. ES modules, ECMAScript modules is a standard now. This is part of the new JavaScript standard, which defines import and export. I'm sure you guys are familiar with it. And this works in web browsers these days, these imports and

exports and ways to link different files together. And the way that this works on the web is you can actually do import a URL from not just a relative URL, but a absolute URL that exists on a different server. And so you can actually pull in code, you know, if you think of like a HTML page and script tags, you know, you can script source, have a link to hdpsjquery.org slash jquery version 1.2.js. That's how we used to do it back in the day. We just have our script sources and you just have your list of sources and everything was so simple. Which is quite nice, right?

I mean, it's really nice to have a HTML file and just drop in a link to the jQuery CDN and suddenly have that available without having to do a whole thing. Yeah, totally. A whole installation procedure, right? Anyway, Deno is built around the idea that we think this is sufficient, actually, to link remote code together. I mean, the problem is really, I've got code that I'm developing locally, and I really want to include some third-party library. How do I do that in the node system, you would

download that third party code into a node modules folder. And this require system in knows how to look into this node modules folder. So when you do require Express, it looks in the local directory, node modules, and then looks for the express folder. And, you know, it has some special knowledge about looking up package JSON and looking up index.js has kind of this algorithm of how to find what module you're referring to there. And we've basically done away with all of that. We've just said, you know, if you've got code that you're working on locally, then, you know, you store that in your local folder and that's yours to deal with. And if you want to link to some third party code, you can, of course, download it into a vendor folder if you wanted to and dot slash relative include relative import that.

But you can also just import the remote URL via HTTP. So our module system is really the web browsers module system, which is exactly HTTP. So you know, we don't have, unlike NPM, which has a specific protocol for distributing packages, you have to ask the NPM server what the latest package is get the link to the tarball, download the tarball. We don't define a protocol like that. We just have HTTP and you can download JavaScript or TypeScript over HTTP. And what are the advantages of that then? If pulling a module, say for NPM, for example, the stability of being able to make those, you know, NPM install, for example, and being able to, I suppose, sit there and wait,

like some people might, you know, what are the advantages, I suppose, of that system over this older one? Obviously, it's, you know, modern in terms of the way the web browser is working, but what are the specific, you know, DevEx, you know, DevExperience kind of advantages there? I think it has the effect of feeling immediate and there's nothing to install ahead of time because the Deno system itself actually takes care of downloading that.

And so, you know, I would say the other DX effect is that you can have scripts that are single files. In Node, you generally at minimum need to have a package JSON and your JavaScript file. Your package JSON needs to define where you're linking, and your JavaScript file has some source code in it. In Deno, you can say where you're linking on line one, and the rest of the script can be your code. So you can actually define a complete program, both where to get your third-party code and your own code all in one file, run it without creating a directory. And I guess what I'm trying to say is there's less boilerplate to deal with. It's minimal. Yeah, simple.

It's very minimal. Yeah, I mean, you can have file tabbing fatigue or swapping from different files. I love that a lot in a whole different land with like Tailwind, for example, you can do a lot in the same file or in the same HTML file. You're not jumping back from CSS to HTML. So similar to how that world might work, you're not jumping back and forth. You can stay in the same file, have this sort of immediate instant gratification of just moving forward and not have to jump back and forth between different

ways to define which your application is needed to inherit from or to import, etc. When you have a large application, if you have hundreds of files, right, having one extra package JSON file is not a big deal. Like it's no big deal to have a, you know, if you have hundreds of modules and you have one extra one, it's not a big deal. So, you know, I think in kind of the tail end of larger projects, it probably doesn't feel that different. But when you get down to the very small scripts, the one-off scripts, Deno scales down to a much smaller installation, I would say, much less boilerplate, right? When you do NPM in it, it's going to ask you for, I don't know, the license of your project,

you know, the name of your project. All of that stuff is, let's say you're trying to write a script that's going to rename a bunch of files in a folder. Who cares? I don't care what the license is. Like, why am I spending any time at all thinking about that problem?

Like that is boilerplate yeah what about the potentially hidden advantage and i'm assuming this the internet essentially is your package manager right you can link to a raw file on github you can link to some random site on adamsdekovac.com or changelog.com and just inherit from that is that how dino works you can just pull in from any URL or as you'd mentioned, even a relative from somewhere locally? Yeah, that's right. So yeah, you can pull in files from any server.

And the nice side effect of this is that the node ecosystem and essentially all other programming languages are dependent on a specific server to distribute third-party packages, right? Whether that's crates.io, whether that's golang.org or npmjs.com. If that server goes down, everything breaks. We are heavily dependent on that.

But contrast that with, this is just not very webby. This is not how web browsers work. It would be a bad day if Google went down. But hopefully, hopefully web browsers work. It would be a bad day if Google went down, but hopefully, hopefully web browsers continue to operate like your website should isn't necessarily dependent on any one specific server existing. And that's nice. Like that's a distributed system. And because of this aspect that you can download code from any URL, Deno is not dependent on our website, deno.land, nor is it dependent on any other website.

You can use unpackage.org for pulling in your third-party dependencies, or you can use GitHub directly, which might be nice since that's where the code is actually stored. Right. Then if GitHub goes down, we're screwed again. But we were already screwed. Great website, by the way. I love the dinosaur brand. I love the name name dino.land is such a cool domain just wanted to give you props for that really quick what about versioning i mean if i'm a library author are

there idioms around that do i just have a new file with like the version in my file name how do we deal with things like you know lodash 3.7.1 is out. How do I go get it? Ultimately, a version is a string of characters, and so is a URL. So you can have a version in a URL to specify the version. Think back to the jQuery CDN example, right? You have perfect ability to link to any version of jQuery. Good answer. What about existing NPM? Are all the existing NPM packages then supported if I can find the exact URL of the source code?

Is that they'll just work? Or are they using some things that might not be ESM compatible and stuff like that? Yeah, so if it's not using ESM, then it's going to be probably problematic. It may be problematic even if it is using ESM. Unfortunately, we're kind of in this state right now in JavaScript where there's a lot of fragmentation between TypeScript, CommonJS, Deno, Node.

I hate to contribute to that, but I also am, you know, I feel like fighting the good fight trying to make things things simpler. All npm packages are available on for example, unpackage.org or sky pack. So you should be able to access those files through HTTP. And if they're ESM, then you're close to that to it working. I think the problematic thing is if they use node API's. So node, for example, has, you know, require FS, you can require FS and like open a file, Dino has alternative API's for that we do not have a top level FS module, we have a compatibility layer for that. So that's in our standard library, by the way, Deno has a standard library. And you can find that at deno.land slash

std slash node. And using that compatibility layer, you get pretty close, although there's definitely a lot of modules where there's going to require some work, but you can get pretty close to importing a lot of modules. There's a long tail end of things that are incompatible, though. This episode is brought to you by Retool. Retool is the low-code platform for developers to build internal tools super fast and super easy. They have a ton of integrations and templates to start with. With a click of a button in seconds, Thank you. It's too easy to get started with Retool. Head to retool.com slash changelog to learn more and try it for free. Again, that's retool.com slash changelog. So Ryan, on your website, dino.land, awesome website. It says a secure runtime for JavaScript and TypeScript. And of course,

secure by default is the top level bullet of Dino features. We haven't talked about security yet. You want to give us the skinny? Yeah. So obviously, if you're pulling in random packages over HTTP, you should be worried if you're pulling in code because, you know, maybe you've audited this code, but probably not. Like that code probably depends on some other code. And those can end up pulling in many, many dependencies. It's kind of like those installers where they're like, curl this URL, pipe it into Bash. And then a lot of people will show up in the comments like, please don't do that because Bash is going to execute arbitrary code that's in that URL. Anyways, cut you off.

But I just was reminded of that where it's like, yeah, but as long as it's safe, you know, like audit it and you'd be happy. But if you don't audit it, you probably shouldn't be piping into Bash. Unfortunately, it's really hard to audit all of your code these days. I mean, we depend on society level infrastructure, right? There's no possible way if you plan to be a productive developer to go out and actually read through all of the dependencies and the trans is running on your computer without any security sandboxing. So, you know, and beware when you are NPM installing something, you are completely and utterly open to having your computer taken over. It takes one bad actor in the ecosystem to make that happen. We have seen that. Yes. This is mitigated in web browsers. Web browsers do not allow you necessarily have access to the system. We, Deno and Node, give access to the system so that you can do things like writing a little script to rename a bunch of files. The purpose of a server-side JavaScript system is to interact

with the system. But in Node, we did this without any constraints. We just opened all sorts of holes so you can access the file system, you can access the network, you can do all sorts of stuff. There's no gating on those privileges. In Deno, we're much more aware of opening holes into the system. And I mentioned earlier these ops and how Deno has a very centralized system for calling from JavaScript into Rust. By having this centralized system, we also have kind of centralized gating for security. And so by default, when you run a Deno program, whether that's a local program on your computer

or a remote program via a HTTP URL, it's given no access to the system. All it can do is compute. So it cannot access your file system. All it can do is compute. So it cannot access your file system. It cannot open outbound connections. Can't do anything mischievous. It can calculate some numbers. It can print to standard out, but that's about it, which sometimes is all you want to allow programs to in web browsers. They have this system for kind of opting in to more privileges. So for example, websites can access your webcam, right? But not just any website can access your webcam,

it needs to like elevate its privileges. So you know, you get this little pop up that says, do you want to allow website X to access your webcam? Deno is very similar. When you try to access the file system, it's, it's going to fail if you don't have the privileges and you can give it those privileges. And you give it those privileges via command line flags, right? Via command line flags. So we have, you can do allow all if you want a node mode where there's no privileges, there's no gating.

We have allow write to write to the file system. We have allow run to run subprocesses. We have allow read to read file system. We have allow plugin to load kind of Rust plugins, which we can't assure are not going to do something nasty. We have allow net for making outbound network connections and allow end for environmental variables, which may often contain secrets. Is that something you can put in the file itself? Or does it have to be a flag to the runtime? It has to be a flag, we are considering having a configuration file. We are really conservative about adopting kind of new file formats. You know, I was just talking about how we try to keep things as boilerplate free as

possible. And so we don't want to force people to write a configuration file. We don't want, you know, kind of overhead of configuring your system before you ever get started. So for now, they are command line flags. And they're pretty obvious and annoying. And that's kind of purposeful because these are security things. They should be obvious and annoying. You should be very clear that you are allowing the system to run arbitrary sub-processes.

Yeah, so via command line flags is how you enable them. How often are those flags being used by general applications you see being built? Like all the time. All the time? All the time. Yeah, I mean, it depends on what you're doing. I mean, if you say have a,

let's say you're writing a program like ESLint, this ESLint-like program doesn't need to make outbound network connections. It doesn't need to write to the disk. All it needs to do is read from the disk. So you would only enable the allow read in that case. Yeah, so I was telling you during the break that I was writing this little script with Dino the other day, and basically it went out to the Slack API,

got some data from there about members of our community, and then looped over. was trying to like pick a random winner for a giveaway from like a certain channel from one of our slack channels and then it you know picked a random three or something just printed them out you know very simple use case and i had to use allow net and obviously because i'm hitting slack api right and then i also had to use allow end because i could because I'm hitting Slack API, right? And then I also had to use allow env, because I could have just hard-coded the token into the script, but I just used it as an environment variable.

And I could say from a script, from a person who's just trying to get stuff done, it is kind of annoying. You're just like, ah, you know, I didn't know about dash all. I would have just used that. But now I know. I'll just use that all the time, maybe. Node mode. Yeah, node mode, please.

I mean, if you're the one who's writing it, then you're pretty sure that it's going to be okay. The problem comes when you're running somebody else's code. Yeah, like I said, this is an inconvenience, but it's like a very explicitly well-considered inconvenience that's like, yes, we're doing this because the trade-off is completely worth

it, right? This is a shift left kind of moment where you're taking typical, maybe security concerns that, you know, you might rather just say Deno run or whatever the command is to run a Deno application. But you're kind of shifting left saying these are security concerns that Deno resolves and has control over and putting them more front and center rather than, you know, as you said, in a configuration file, which is less minimal, requires more potentially different file format or other concerns like this is a shift left kind of moment. Would you say that?

Sure. I haven't heard the term shift left before. Shift left is whenever you take the security concerns, which if you take a, you know, a product lifecycle left to right, left being dev iteration, right going to production. I see. Shift left is you sometimes think about security further to the right once it's shipped, potentially. Shift left is a term used in security mines to take that security concern and shift it more left into dev land. Yeah, I should mention that there is a new feature dash dash prompt, you know, run dash dash prompt. So if you don't want to allow all the current behavior is if you hit one of these ops that's trying to access the file system, and you don't have the correct allow flags, you get an exception, the process drops out errors out. There is a new feature that's kind of has an interactive prompt that will be like, hey, I'm trying to read this environmental variable. Do you want to allow this? Yes or no?

And so you can kind of yes or no through the exact accesses that the system is doing. And we think that we're going to enable this by default, actually, and not require this dash dash prompt flag. And so this is kind of going more in the direction of, as always, in the direction of web browsers. We'd like this programming model where you opt into additional privileges no i like that sounds like a good a

good compromise right you're kind of shifting a little bit further right but you're following the web browser's lead where it's like are you sure you want to give this person access to your webcam you know and if you say yes and it's on you so security front and center we've talked about packages and how that all stuff works importing other people's code we've talked about typescript what are some other aspects of dino that are cool and exciting there's some tooling things there's a formatter there's some of these kind of developer experience things that help you stay productive right yeah so there's a bunch of sub commands in Deno. So Deno run being the most obvious one to run a script, but we're kind of taking this go approach where we're just going to build in all the tooling

for you so that you don't need to bring in all this other third party tooling. So for example, we have a code formatter built into the system. So you can Deno format your code. We have a linter built into the system, you can Deno lint, we have a test runner, Deno test to run tests, we actually have all sorts of stuff in there, we have test coverage, and we have a documentation generator. And we have a dependency analyzer, Deno info, it will show you your dependency tree. Generally, Deno knows all about your source code, it knows all about your dependencies and what it's doing. And, you know, why not, we're distributing this executable, all of this stuff is written in Rust. And so compiles down really tightly. And so you know,

our formatter that you run is not prettier, it's something called d print. And it's written in Rust. And it's like 100 times faster. And our linter is not ES lint. It's Dino lint. And Dino lint is written in Rust and is very, very fast. We have Dino LSP, which allows VS code to talk to Dino and get kind of tab completion, really nice editor interaction. So Deno can basically tell your editor, you know, documentation, all sorts of interesting interactions that Deno can help provide VS Code. That's all really cool stuff. Yeah. How much of that stuff is informed or inspired by other languages?

Are you a language aficionado? Do you watch what the Go folks are doing, what the Elixir folks are doing, what the Haskell folks are? Are you watching these different ecosystems and saying, oh, there's a good idea? Because I think, you know, GoFundMe kind of made this format a popular thing to do at the language level, not at like a third party level. And it seems like you're pulling in lots of good ideas. Absolutely. I mean, this heavily inspired by Go, not just in these various toolings,

but all throughout the system. It's important to continually improve and take good ideas where you can get them. So the standard library is pretty fleshed out as well. I'm just wondering like, where are the holes? Because Deno still, it's a 1.0, but it's newer. It's not as mature. Is the ecosystem still waiting for large holes to be filled?

I know you're working on, or you recently shipped HTTP2 web server backend. So things that you expect to be there are kind of there, but at a certain point, do you get to where you're looking for a package and it's only in Node, it's not in Deno? Is that still the situation? Yes, that is still the situation you know things take time i expect this will be worked out over time i remember back

in like 2010 people would be like how do i connect to my sequel with node and i would you know turn red face you write a driver and apologize that I did not have a MySQL library yet. And they're like, but how is that going to happen? And I said, I don't know how that's going to happen. I just hope that that is solved at some point. And like, it's embarrassing to even think that that was a concern, because that was totally not a concern. Like all those problems got worked out, like, essentially without my interaction. You know, Deno and Node are very similar systems. They're both built on V8. They're both JavaScript. They're pretty similar. The differences are relatively superficial. I mentioned this Deno LAN slash standard library, the Node compatibility layer. This is a work in progress. If you go check it out, there's something, I think we're

maybe at 40% compatibility now. So we're still filling these things out. And I think over time, it will be less and less of a problem to take existing code and run it in Deno. But you know, there's still a lot of work to do. So you mentioned this HTTP2 web server. So up until recently, Deno was using a web server written in TypeScript that was a loose port of Go's web server. So it's built on top of TCP sockets and TLS sockets. And, you know, it was a nice HTTP 1.1 server, but had some problems in that it didn't support HTTP 2. And because we just made this port ourselves and are not particularly interested in writing web servers, we're kind of dead ended with that code base. Like we're forced to then write an HTTP 2 web server, HTTP2 being a much more complicated protocol than HTTP 1.1.

What we'd really like to do, I mentioned this earlier about linking in native code libraries using Rust. Rust obviously has a web server already implemented. In fact, Deno already has that web server in its binary somewhere deep inside of it. What we really want to do is just allow people to call from JavaScript into this hyper web server binary somewhere deep inside of it. What we really want to do is just allow people to

call from JavaScript into this hyper web server in Rust and start up a nice, fast HTTP2 web server. This work is still unstable. It's shipped in Deno 1.9. So people can use it if they use the dash dash unstable flag. But yeah, now we're working on this native web server, which I think is serving websites is quite important to server-side JavaScript tasks. And it's quite fast. It has very good latency, very good throughput. So, you know, we have some preliminary analysis

of its performance on the 1.9 release notes. We hope to stabilize this in the next couple of months and people will have a very fast web server available right out of the box. This episode is brought to you by CloudZero. They help teams monitor, control, and predict their cloud spend. And I talk with Ben Johnson, co-founder and CTO at Obsidian Security. They get tremendous value from using CloudZero.

Ben shared with me the challenges they face driving innovation and customer value while also trying to control and understand their Amazon Web Services spend. We want our engineers to move fast, to innovate, and to really focus on driving customer value. Yet at the same time, reality is we have to pay for cloud compute and storage. And the challenge around AWS is often that you have multiple accounts, you have lots of different services, you have some people who only have lots of different services, you have some people who only have access to development environments, not necessarily production. A lot of these different challenges across services, across accounts that make it hard

to understand the positive or negative impact to the costs that the new feature, the scale, you know, maybe the change in architecture are having. And so giving our team more insight into the ramifications, again, positive or negative of their changes in order to, maybe we need to really move fast. Let's have less worry about cost right now, or maybe now we're in a more stable place. Let's, let's drive down the cost so we can give, give those cost savings onto our customers or improve our own margin. So a product like Cloud Zero can really help your team get a handle on costs, get alerted to those spikes, feel good when you actually see the costs drop, and do all that without a whole lot of investment of your own time. All right. If your organization shares similar struggles as BAN and Obsidian Security, check out Cloud Zero today.

Learn more and get a demo at cloudzero.com slash changelog. Again, cloudzero.com slash changelog. Again, cloudzero.com slash changelog. So Ryan, back March 29th, you announced the Dino Company. And obviously, you got a great new start to what you began with Node. A lot of new beginnings here, a lot of wrongs made right. And to put behind that, a company. So why are you on this path? I suppose more than 10 years, Node 2009, now it's 2021. What's the path? What's Deno Company? What are you doing? Programming languages are important.

You know, the world is built on software. And of the programming languages, dynamic programming languages are, I would say, what most people are interacting with day to day. You know, but most business needs are best expressed in, you know, Ruby on Rails or, you know, Node JavaScript or Python. Because, you know, to be honest, most problems are not compute bound, they are engineering bound, right? All of our time spent as programmers is kind of what we're trying to optimize for. And scripting languages, dynamic programming languages are the best way to get going fast. You know, I work on this problem because I think it's very empowering

to be able to take a system like Node or Deno or Perl or Ruby and just start programming really fast. I got started with Perl myself and I don't know if you guys feel this way, but there's that feeling of power when you first like really grok the language and you kind of get over, you know, you have to climb some mountains before you feel powerful and pearl. But, you know, once you get there, like suddenly like the world is your oyster and you can just solve all sorts of problems very quickly. Yeah, I just don't think there's enough effort being, obviously, you know, I'm talking a lot about Rust, Go, these programming languages are very important, but they're targeted at kind of different use cases. You know, I love Rust,

I would never start a new C++ project, as I said, but I'm not going to use that to rename a bunch of files on my folder. I'm just going to smash my keyboard for a while and write some JavaScript. Of the dynamic programming languages, JavaScript is the biggest. V8 is the fastest VM in JavaScript. It's the fastest dynamic language VM, period. And JavaScript has this standardization, this industrial standardization process with it. It's tied to the web. So, you know, if you believe that the web is going to be here in a couple of years, JavaScript will certainly be here in a couple of years. It is as tied to the web as HTML is. So it's certainly not going anywhere. So, you know, if you're going to choose one of these languages to invest and build on, I think it's pretty clear

that JavaScript is the language ultimately that we're going to be using. I think, you know, once you play around with this stuff a bit, and you learn Python, and you learn Ruby, and you learn JavaScript and Perl, you get the feeling that they're pretty much the same thing. Like there's different syntax here, there's different ways to do different things. But they are very similar systems, essentially with, you know, different function names, different syntax. And yeah, I think those surface level features are fairly unimportant. And so, you know, I think JavaScript is really the one that we should be pushing to be using to push forward kind of the needs of the world to create fast software. Create software quickly,

I should say. Bet on JavaScript, basically. Bet on JavaScript. One of the things you say in your mail, too, and you kind of alluded to this a little bit, was in the philosophy section of the introduction, you say, among other things,

Deno is a great replacement for utility scripts that may have been historically written in Bash or python i didn't really consider this but that's pretty interesting too because most often i'll reach for things like bash to do different things and on a file system or not too often python because i'm not a pythonista but i've definitely used bash before and i've used things in ruby like Make and other things like that. Rake. Rake. Isn't Make and Rake fairly the same?

Isn't Rake built on Make? Well, Rake is based off of Make, but Make is not Ruby. You just misspoke. Rake was what you meant. My bad. Rake slash Make then. Thank you for correcting me. Being able to do that kind of thing where you're betting on JavaScript,

not too often we do those kinds of things like scripts like that with JavaScript, maybe for its lack of ability to have secure access to the runtime or the system and file system and whatnot. Yeah, I mean, Bash is another dynamic language, you know, one that starts a sub process for every statement in your program. But generally, you would use Bash because it's widely available on all of the different systems that you're running on. It's very portable. It's not a great programming. I don't think anybody loves Bash as a programming language. It's pretty hard, yeah. I regularly access documentation to confirm my syntax is correct or just caracold.

Just caracold. Because that's sometimes easier. Copy and paste, you know. There's lots of it out there too, so it makes it easy. There's probably a subreddit somewhere where there's lots of it out there too so makes it easy there's probably a subreddit somewhere where there's you know people who just love bash and it's like their thing but they're a you know they're a rare bunch for sure now like you said if you take all of the scripting languages together i agree with you i've done python pearl ruby javascript the more you learn

the more you start to realize they have their own idiosyncrasies they have their own view of the world but they're all kind of in the same ilk and i would tend to agree even though ruby is my first love that javascript is the one to bet on because it's already ubiquitous it's in the browser it's used pervasively server-side now, thanks to Node. And it is definitely not going anywhere. So you've picked that as your place to build and to create. And you want to do this into the future. This is an ambitious, big project, right? So you've started a company around it, which is different than what you did with Node.

That was a long time ago. Why don't you tell a little bit of what went down the first time when you created Node? What happened with you? I know you had a full-time job, etc. Things are different with your life. There's a company now that is different than Node. Can you just compare and contrast the two situations for us?

Yeah, I was much younger, obviously, when I started Node. Shortly after starting it, I took a job at Joyent, where they said, come work for us. You can continue working on this project, which seemed like a great deal. And I moved from Germany to San Francisco and continued building Node. And kind of throughout 2009 to 2010, first part of 2012, when it became more and more clear that Node was really a thing, Joyent sat down and made a business deal with me. And I ended up selling Node to Joyent, whatever that means when it's a MIT licensed open source project. But I gave them control of the project and gave them the website and whatnot.

That worked out very well for myself personally. And I'm not sure how well it worked out for Joyent actually. For myself, it was great. I've seen some comments online that kind of paint a different picture of the situation. It was like exploited by Joyent or something like that. You didn't feel that at all? Not at all the case. Well, that's good.

So after you left Joyent, what did you do next? I know you're doing research and development at some point, but did you have a job after that? Did you take some time off? I took some time off. I worked on some other projects that were unsuccessful. I worked for a while at Google doing machine learning stuff. It was, I think, 2018 that my collaborator in Node, Bert Belder, who founded the company Strongloop, was...

So Bert's journey is also interesting. He was an early contributor to Node and did one of the most important refactors in Node early on. Early on, Node only worked on Mac and Linux, and we wanted to port it to Windows. And Node is doing all this asynchronous IO, and so it uses EPOL and KQ, these non-blocking sockets. These are fairly intricate, not well understood operating system APIs that differ from operating system to operating system. And in particular on Windows, it's completely different. Their non-blocking IO system is called IO completion ports. And we wanted to do a very proper port to Windows.

We wanted to use IO completion port so that Node would work as a native proper program on Windows. And this was a massive undertaking. And BERT led this effort. We collaborated with Microsoft on it. It took probably a year. But at the end of the day, Node works on Windows. In fact, Node is very well supported on Windows. And it's very fast. I don't think people run servers on Windows too much, so maybe it doesn't matter how fast it is on Windows. That was a very successful, massive undertaking. As I said, Bert went on to found this company, Strongloop, that did Node-y sort of things, built some products on top of Node. They sold that to IBM, I think in 2015 or so. And around 2018, I left Google and Bert wanted to leave Strongloop and our IBM. Yeah, we teamed up and started working on projects. I already mentioned this TensorFlow in Node project that we were originally working on. But we just had the idea to kind of poke around for a while and see what we could do.

So after you conceived the idea of Deno and maybe you had a prototype or you had maybe even you had announced the project, was the Deno company right there in your guys' minds kind of like, okay, here's a path forward from then? Or is that a newer conception that you came up with later? So early on in Node, as I mentioned, I was young and naive about how software is developed. You know, I was very much of the idea that, oh, you know, you just throw some code out there on

the internet, you collaborate with people, this is how software gets built. But, you know, Node grew bigger and bigger and bigger, and there's more and more people involved. And it becomes clear at some point that organization really matters. It matters very much to have full-time professional engineers working on it. And, you know, people can contribute code, you know, kind of on a one off basis. But if you really want to get things done, like port nodes to Windows and use IO completion ports, you need full time engineers, these people need to get paid, and they need to, they need to be able to focus on a problem for a long period of time. And so you realize that, you know, at a certain scale, software becomes a lot more about kind of managing budget and trying to manage an organization and kind of the meta problems around getting funding for people. go down this route and build this programming system that is going to be very much like Node, that if it's going to ever scale, it needs to have some funding model. There's no way that this can

work where people are just going to randomly work on stuff on kind of a one-off basis for free. There needs to be some way of paying people to work on the problem. And, you know, Node is not a piece of software that is unused, that is not attached to revenue streams. There's all sorts of companies using this. If I could have one cent for every Node installation, oh, how great that would be. You know, this is open source software, of course, and it's very liberally open source. And I believe in that. And I think that's important for a programming system like this. But yeah, we see that these systems have commercial applications to them. And these can provide connections to reality for the software itself that is making sure that we're actually solving a useful problem, but also provide funding to develop the software. Yeah, I guess we've known very early that we did not know if this project would go forward or fail, but we always knew that

if it's going to grow, that it would need to turn into a company eventually. At what point did the company become the company that I know you had the announcement in March, late March, you mentioned a sizable round of seed capital. You can name names if you'd like to. But at what point was that when the company began in the team of, you know, full time expert engineers working to prove Dino happened? When did that was a chicken and egg? You know, which came first? No, Bert and I, you know, first of all, worked on this ourselves for, I think, a year. So that was kind of our first investment. And I think we hired our first engineer in 2019 or so. And yeah, we've grown from there. I think we're eight people now. Gotcha. So if there's a video game called

build an open source business, and at the first step is, you know, pick your license, you guys chose MIT, that would be like, you know, pick your license. You guys chose MIT. That would be like, you know, setting that video game on hard mode, wouldn't it? It's like, well, I want the biggest challenge. I'm going to let my software

as free as you could possibly let it free. There's a lot of startups, a lot of businesses switching over to things like SSPL, AGPL. Any concern about, you know, AWS offering, you know,

competing with you or the big dogs coming in and eating your lunch? Everybody's trying to kind of figure out open source companies and how to do this properly. And one model of doing this is the open core model, where your open source software would be free, but then you kind of have an enterprise edition that you add on some extra nice features and you would charge for that. You can also kind of get into some licensing trickery where maybe you make your software AGPL license and, you know, kind of allow people to run this locally or kind of in non-commercial applications for free. But once you kind of get into the commercial realm of things, you are then asked to pay a fee.

I think for Deno, this is a programming system that we're asking people to program against. We're asking a lot of our users, right? We're asking them to invest a lot in the system. And I personally would be very, very uncomfortable with programming using as the base layer of my, you know, this Deno sits below all of your other software. I would feel very uncomfortable if there was some weird payment hook at that layer of the system. It would prevent me from ever even trying out the software, in fact. And I think that's the case with Deno. If we tried to

make Deno itself commercial, and people are looking at Python and Node and Ruby as alternatives, I think many would choose the solutions to this problem that do not have a payment hook in it. We are pursuing a different funding model or revenue model. As I said, we think the software is pretty useful. And we think it's useful in different commercial applications. I haven't mentioned it yet. But you know, you know, you download it as this one executable. But it's actually a collection of software. And we've been pretty careful in breaking up this into different bits that we can recombine in different ways. And so we have a product that we've been working on for the last six months or so, that is a different runtime. It is called Deno Deploy. And it has the same, a very similar API to Deno, a very web browser API. It's a JavaScript runtime, but it doesn't run on your computer. It runs in the cloud.

You can think of it as a dynamic CDN if you want to. So we have processes running in 22 locations around the world, and we have an Anycast IP, and you can provision a domain name on our system. And when you go to access your domain name, it resolves to this Anycast IP, and that gets routed to the nearest data center. So, you know, if you're in Tokyo, it gets served locally in Tokyo. And rather than a CDN, which responds with static content, this invokes a JavaScript hook. So, you know, it is a serverless system. So, you know, think AWS Lambda or Cloudflare workers. So it's a system for responding to requests dynamically. The best way to describe it is

it's a web server, a multi-tenant web server with V8 built into it. It is completely a separate system. And this thing, AWS cannot, this is not open source. This is proprietary code. But it's still Deno in terms of the API. So I'm using Deno to develop. I can use it locally. I can deploy it on my VPS, fine. But if I want to run it in this capacity

where my users are in Tokyo, so my Deno process is running in Tokyo, then Deno deploy is just like a push away or a sign up away. It's a pretty cool idea. That's right. Of course you can take Deno, the executable that you download that's free,

and you can wrap that up in a Docker and you can send that out to AWS Lambda and kind of have a very similar experience. But that is not what we are doing internally. We are not running Deno in some Docker container. We actually are kind of using the VA isolate. We were talking about how this is a secure sandbox before. So instead of having multiple Linux VMs running for all of the different tenants on this web server, we actually have all of these little VA isolates running. And these, as we mentioned, are secure sandboxes. So we don't have to worry too much about hackers being able to see other people's requests and whatnot.

And the nice thing about these is they're super lightweight. This is essentially like opening a tab in a web browser. So think of a web server with a bunch of tabs in it. And each of the tabs is for a different tenant on the system. And so we can respond to requests very, very fast. We have cold start times in sub, I think, less than 10 milliseconds, not sure the exact number. And we do all sorts of nice optimizations. Obviously, it only runs JavaScript, right? This is not a Linux VM. So you cannot run your Python process in this.

But because we've kind of taken this, because we've built explicitly on top of V8, we can make all sorts of very nice optimizations like Cloudflare has done to speed the response time. I think Amazon would have to be really motivated to do an Amazon deploy with a Deno repackaged. I'm not sure that's part of their business model to serve customers, but I could be wrong. You never know what they're going to do next. I mean, you just never know. You just never know. The liberal license, the permissive license, MIT, you know, open source, single binary,

a collection. Sure, maybe they would do that, but I don't think that's their model. So I think your goal, though, is to provide Deno as it is to, I guess, to maybe solve some of the problems you didn't do well enough with Node and sort of live on those dreams you had with Deno, but then still have this commercially applicable ability on top of Deno. And you mentioned in your announcement for the company, we've been hinting at commercial applications. And so, correct me if I'm wrong, deploy is just one application. So applications of this infrastructure for years.

What are some other ideas that you have that you can share? Is there anything you could tease or mention or early announce? Right. We're working on this deploy product and that's the only thing we're going to be working on for the foreseeable future. But other applications would be,

say, Electron. We think we could do a much better kind of GUI application framework than Electron has, given that we have Rust and that Deno is kind of broken up into these building blocks. Generally, there's all sorts of systems that kind of want little one-off JavaScript,

little bits to be scriptable. And we think that there may be all sorts of kind of hidden use cases where people might want to have a Deno API. That is, and by the way, I should be explicit, like Deno is trying not to have an API. Deno is trying to be the web browser API. Deno is trying to not have a specific Deno API, but just if you want to encode a string into a UN8 array, you use Text Encoder. We don't have a special Deno API for that. But yeah, I think there's databases that may want to do, say, MapReduce with JavaScript. Potentially there's some commercial application there.

But yeah, I think for the moment, we're focused on this Deno deploy. The idea is that if you're writing a website, you write some JavaScript, you might run this locally with Deno on your computer, maybe spin up a little local server to serve that front-end JavaScript, that kind of server side code to assist you in writing this front end stuff, or maybe any backend code that you write is also very web browsery, uses the same WebSocket APIs, for example. And so, you know, there's basically three different deployments, the web browser, front end JavaScript, your local computer, where you're going to be writing some kind of server-side JavaScript, say.

And then maybe you want to deploy that server and run it globally. So then you send out that code to DenoDeploy. And by the way, you can take that executable and you can deploy it yourself. So you're in no ways like locked into using our DenoDeploy system. But, you know, we're going to have the best way for you to deploy your Deno scripts. What's the state of Deno deploy system. But we're going to have the best way for you to deploy your Deno scripts. What's the state of Deno deploy currently? Is it in beta?

I know people can use it. It's in beta. What is the state of it as a commercial product? It's not collecting funds currently. People aren't paying for it currently. It's sort of available to use. How do you plan to convert that into commercial? What's the current state?

Yeah, it's in open beta right now. I would consider it a technology demo at this point. We're working on cool features that will be announced soon. Yeah, we will have a general availability announcement. We don't have a deadline for that yet, but we hope that it will be later this year. So, you know, we're kind of thinking in the six-month timeline or so, but yeah, it's usable. People should try it out. It hooks up with your production. Ready then production stable. Uh, I would not know, consider it that he said usable. He didn't

say production. Okay. Yeah. So it's something that, you know, if you're interested, you should try it out, but I would not use it for production problems at this point. So if there's a future then for Deno, a place of competition might be with Deploy. Because if you claim here now that you intend for Deno Deploy to be the best way to run a Deno application, then that might be the way. If Deno wins, like Node has has won and we haven't asked you if you plan for, I assume so but if you plan for Deno to take over what Node is, to replace Node

particularly, but if it becomes as big as Node has become and as usable as Node has become then that's the place to compete with you, would be on the deploy I guess I'm not sure what you're asking actually well to deploy you know similar maybe for you know there's some

examples from wordpress for example like there's particular hosts that are like amazing at hosting wordpress if dino wins it becomes very popular to gain market share to have a commercially viable application or a company or a sas product you might want to compete with you all to host dino applications yeah i mean would encourage anybody who wants to compete to compete also be running a dino service yeah sure ultimately that's good for the ecosystem anyways and youeno, the company, probably pretty good competitor when it comes to running Deno in these different contexts, right? So I think I would assume you're welcoming competition. Yeah. And, you know, by the way, we're investing a lot in kind of this Rust JavaScript infrastructure. And so, you know, when you go out and see products that are kind of

serverless, serverless products that execute JavaScript and don't look like extremely nodey. So, you know, a lot of this stuff is actually node, but kind of newer server-side JavaScript APIs. Yeah, look carefully. It may actually be Deno or one of its kind of lower layers of crates. Yeah. We expect that and we encourage that.

Yeah, this helps the ecosystem. Take me back to dino deploy for a second just like as a thinking through it as an end user and it seems like a lot of these serverless solutions don't have like the database story when it comes to my back end if i'm going to run all my code my dynamic website at the edge but my database isn't co-located with those edge nodes. It's like in New York City running on a Postgres server or whatever. It kind of defeats a lot of the advantages of having that locality of that runtime because most backends aren't just doing mere math.

You know, they're like, yeah, there's some data stored in some place and they're going to go hit the database and they're going to figure it out and they're going to put stuff in, take stuff out. Is there anything with DenoDeploy that like co-locates a database or makes it so that my Deno backend has all the things it needs right there with it? Not yet.

You certainly see CloudFlare going in this direction with durable objects. So, you know, right now DenoDeploy is kind of this, I would consider kind of the minimal viable product, which is that it responds to requests. So you can send back a response, you can make outbound requests. So, you know, let's say you have a Firebase database hosted by Google somewhere, you can make outbound requests to that data store for any persistent needs. We've basically pushed the persistence problem out of our problem space at the moment. And, you know, there are problems. Sometimes you just want a little redirect server and there's no need to have persistence in some applications. Obviously many applications need persistence. And this is one of several features that we're looking at in kind of the coming months. Cool. So what happened with Node last time around, I referred to it

earlier with Michael Rogers reference was that there was a lot of opportunity in the early days. And a lot of people jumped in and became influential, impactful JavaScript people because they helped out with the early days of Node. And this is potentially a new opportunity with this new round with Deno, where it's early days. You have core team, you have people doing stuff. There's a standard library. There's a lot more stuff that Deno has, I think,

than that Node had when it first began. But the question is, if I'm a developer, I'm an open source person, and I'm thinking, you know what, I'm going to take a bet on Deno as an ecosystem. And I would love to be impactful. I would love to help out in ways that are big. What's like the best way? What's the easy stuff, low hanging fruit, or the real fertile ground for getting involved and being impactful with your code in the Deno ecosystem?

I think the standard library is, we haven't talked about this that much, but in Node, there is no standard library. There's a lot of utilities built into Node itself. But, you know, part of the Node dependency problem is that when you just want a small little utility, when you want to left pad your string or whatever, you have to end up pulling in a third party dependency. And in Deno, what we're doing is collecting all of, you know, the main useful things and, you know, bit ambiguous, which things should be considered part of the standard library and which things shouldn't be. But, you know, in general, if a lot of people need those utilities, we put them in there. That's a very nice way to contribute. We have a style guide.

We have tests. You know, it's something that affects the entire community. So if people contribute modules to the standard library, and obviously people should ask first before randomly contributing things, it would be unfortunate if you did a bunch of work and then we have to reject it for some reason. Where do you ask? This is a very useful way to be very useful in the Deno community. Where do those questions go?

Is it issues on repos? Is it mailing lists? Yeah, there's a deno underscore std repo on GitHub. And yeah, just open an issue and discuss it. But yeah, generally we're very open to adding new libraries in the std.

Is the std in Rust also Or is that in TypeScript or JavaScript? That's in TypeScript. Yeah, these are utilities built on top of Deno. Obviously, they're, you know, if people know Rust and want to kind of get into the internal system of Deno, there's a whole world there to explore. But that's, that's a bit deeper. We have a Discord, you know, it's very active active and there's a lot of channels where people are discussing new ideas. And so I would encourage anybody to jump on there and hit me up with any ideas. Are there any particular applications out there currently leveraging Deno that you want to call out or that you've been impressed by?

No, actually. Still early days? Still early days. I mean, people are playing around with stuff. And, you know, generally, this is the same, very similar system to Node. And so if you make a chat server, I wouldn't call that out as particularly interesting, necessarily. I think the interesting bits are kind of around the tooling and how we can make these workflows much faster for people and simpler. But the actual applications built on top are very similar in the end. Let's say I'm sitting on an existing Node app, which is medium sized, and it's running a business, but it's not like a 50 million lines of code. What would a port take or what would a port look like? Relatively straightforward or are there serious dragons there?

If it's already using ES modules and TypeScript, it should be relatively straightforward. If it's common JS and kind of old school style node stuff, it'll be a bigger undertaking. Thanks for sharing so much, man. This has been very enlightening. Yeah. I really enjoyed it and I appreciate you coming on.

Yeah. I appreciate you making time in your schedule to finally do the podcast with us after so many years. And I guess we've never really invited you either, but sorry. No wonder you ever came on. You're hard to get a hold of for the last 11 years, but I'm glad you made time to show up here at the ChangeLog. We appreciate that. So thank you, Ryan. Yeah. Thanks for having me. All right. That's it for this episode of The Change Log. Thank you for tuning in.

We have a bunch of podcasts for you at changelog.com. You should check out. Subscribe to the master feed. Get them all at changelog.com slash master. Get everything we ship in a single feed. And I want to personally invite you to join the community at changelog.com slash community. It's free to join. Come hang with us in Slack.

There are no imposters and everyone is welcome. Huge thanks again to our partners, Linode, Fastly, and LaunchDarkly. Also, thanks to Breakmaster Cylinder for making all of our awesome beats. That's it for this week. We'll see you next week. Thank you. Game on.