Evrone: Your new Deno project is quite an impact among developers. What are you doing right now most of the time?
Ryan: I'm working on Deno most of the time!
Deno is actually a moderately large collection of software that comes together in the executable that we ship. We are improving the Deno runtime but we are also working on applying the underlying infrastructure in commercial projects too.
Ryan: I have the most fun writing Rust these days. It has a steep learning curve and is not appropriate for many problems; but for the stuff I'm working on now it's perfect. It's a much better C++. I'm convinced that I will never start a new C++ project. Rust is beautiful in its ability to express low-level machinery with such simplicity.
Evrone: As a respectable VIM user, what do you think of modern programmer editors like Visual Studio Code? Are they good enough for the old guard?
Ryan: Everyone I work with uses vscode and they love it. Probably most people should use that.
I continue to use VIM for two reasons:
1) I'm just very familiar and fast with it, I like being able to work over ssh and tmux and I enjoy the serenity of a full screen terminal.
2) It's important for software infrastructure to be text-based and accessible with simple tools.
In the Java world they made the mistake of tying the IDEs too much into the worldflows of the language, creating a situation where practically one was forced to use an IDE to program Java. By using simple tooling myself, I ensure that the software I develop does not become unnecessarily reliant on IDEs.
If you use grep instead of jump-to-definition too much indirection becomes intolerable. For what I do, I think this results in better software.
Evrone: The Deno runtime showcased the possible ways to fix long-standing issues with dependency management, security, and more. Do you want it to be like Haskell, a place for experiments, or do you have any usage in mind where it can be the best practical choice?
Ryan: Don't mistake newness for experimental. Deno is absolutely meant to be practical and it is built on many years of prior experience in server-side JS.
My colleagues and I are committed to building a practical dynamic language runtime. The design choices we've made around dependency management and security are quite conservative. We could have easily introduced yet another centralized NPM-like system, but instead have opted for a web standard URL based linking system. We could have more easily opened all sorts of security holes into the file system and network; instead we chose to carefully manage access, like in the browser.
Deno is new software - that makes it inherently inappropriate for many use cases. But Deno is also a large Rust code base with strong velocity, a solid always-green CI, and regular scheduled releases. It is not an experiment.
Evrone: In 2020 most software developer conferences became "online" and "virtual". Have you tried the new format and what do you think about it?
Ryan: I have attended some; but I am avoiding them for now. For me the best part of conferences are the "hallway tracks". This is a critical missing aspect of online conferences.
I prefer to watch talks on youtube, in my own time, at 2x speed. Hopefully I will be able to attend some non-virtual conferences later in 2021.
Evrone: The idea to decentralize the dependency graph from one file into individual source code files was championed by Webpack and praised by many developers. But dependency management is challenging, it took Node.js years to move from Common.js to ESM. What are the main dependency management challenges you want to solve with Deno?
Thus I want Deno to not be reliant on any centralized code database.
For certain domains there are more Python libraries available, particularly in scientific computing. Depending on what a new programmer is trying to do, Python might be appropriate.
Evrone: The asynchronous concurrency paradigm with one main thread and small "handler" callables was one of the Node.js cornerstones. Now, this idea is elevated even more with a new "async/await" syntax and "coroutines" concept. As a platform author, what do you think about them and their available alternatives like Go "goroutines" or Ruby thread-based concurrency?
Ryan: OS threads do not scale well to high concurrency applications. Don't use Ruby if you will have many concurrent connections.
Goroutines are wonderfully simple to use and achieve peak performance. Node and Deno are, like Go, built on non-blocking I/O and OS event notification systems (epoll, kqueue).
Ryan: Dynamic (or 'Scripting') languages are useful. Very often the problem a programmer is addressing is not CPU bound. More often the problem is engineering-time bound. It's more important to be able to develop and deploy quickly.
With Deno we are working towards removing the obstacles in applying JS in places where it is currently infrequently used, like in ML. For example, we are likely going to add WebGPU support to Deno, allowing easy out-of-the-box GPU programming that will eventually allow systems like TensorFlow.js to run on Deno.
As I mentioned before, dynamic languages have their limitations and are not appropriate for all problem domains. If you are programming a database, it makes sense to write in a language that gives you the most control over the computer - like Rust or C++. If you're writing a high concurrency API server, it is hard to imagine a better choice than Go.
Evrone: Modern operating systems and your new Deno runtime introduce granular permissions to offset the security risks of third-party software and dependencies. But is it possible for end users and developers who use dependencies to make good decisions while "allowing" and "declining" application security requests? What do you think about the risk that within a few years we will auto-click on "allow everything" like most of us do with website cookie "security confirmations" right now?
Ryan: Website cookie popups are not the best analogy - they're a fairly useless legal byproduct.
Better is the built-in dialog that says "Allow this website to access your camera" or "Allow desktop notifications" or "Allow this website to see your location". These are not useless - these are fairly important security features.
Programmers run many random automations on their computer. No one has the time to audit all the code they're about to run, nor is it sufficient to run everything in a Docker container: When you run lint, is that isolated? No, the answer is you must trust that the lint script will not hack your system. I think it's very appropriate to allow users to see and potentially reject unnecessary system access.
Evrone: The new "full-stack" idea promotes developers to write both frontend and backend code, which is now surprisingly easy with the same language and shared technology stack like TypeScript. Do you think it's a good idea for lots of developers to put so many different things into their everyday work scope?
Ryan: Reducing complexity is always beneficial. The fewer languages, VMs, frameworks, concepts a programmer has to interact with, the better.
Ryan: The TypeScript language is very nearly feature complete. Users depending on cutting edge language features may experience instability - don't do that.
Evrone: How do you see good education for a software developer? Do we need a "science" like "computer science" with all math, algorithms, and data structures or do we need something else?
Ryan: People who want a career in programming should go to university and study computer science. One can, of course, get by with a degree in a related fields (like electrical engineering, physics, mathematics); there are many very capable engineers who have no degree at all.
But there is really something to be gained by spending some years learning the fundamentals and doing a lot of very difficult labs.
Evrone: With the introduction of social platforms like GitHub, it's now easy for both individual developers and big companies to use open source and contribute back. Is it a "golden age of open source" right now or are there issues that are not visible at first sight?
Ryan: Certainly open source is now standard, the licensing situation is widely understood and generally settled. There are still open questions about the incentive model for maintenance, maybe Github Sponsors is helping in that direction.
It's better than it was, but I expect we'll figure out a way for people who maintain important bits of software to be independently paid for their effort.
Evrone: Deno is already a few years old. What are the main technical challenges for the project right now?
Ryan: There's a lot going on: We're building bindings to the Hyper web server, which will provide HTTP/2, and likely be much faster than the current web server. We're building "deno lsp", which provides the Language Server Protocol so that VSCode (and other IDEs) can talk directly to Deno to get syntax highlighting, type checking, formatting, etc - expect the editing experience to improve dramatically over the next couple months.
We're working to pass as much of the Web Platform Tests as possible - so Deno is becoming much more web compatible over time. Check out the Q1 roadmap for more details.
Evrone: Our signature time-travel question: if you could travel back in time and give only one piece of advice to your younger self when you just started to develop Node.js, what advice would it be?
Ryan: Early on in Node I was quite unsure if asynchronous I/O was tractably usable in large projects by novice programmers. I went around giving talks making this claim, but I was rather unsure how it would work out.
If I could go back in time, I would reassure myself that it will work. I'd then tell myself that Node is going to become a pivotal piece of software, and that large software projects require different concerns than small projects: budget, communication, organization. I would tell myself to spend more time on these meta problems.
Evrone: Any advice for developers who want to support Deno with their npm packages?
Ryan: Use ES modules and have a look at our Node compatibility layer.
We were glad to speak with Ryan and learn more about his life, thoughts and projects. At Evrone, we frequently use Node.js to develop custom solutions for our clients. If you love it as much as we do — just send us a message via the form below, and let's have a chat!