September 4, 2017 at 14:19Creator of Node.js: “For servers, I can’t imagine a language other than Go”
- Transfer
Translation of an excerpt from an interview with Node.js creator Ryan Dahl discussing the programming model and Go language.
- Tell us how the initial development of Node went. It's been a while since you created Node in 2009.
Ryan: - I personally think that there is no better moment in life when, as they say, you’re in a stream and you have an idea that you strongly believe in. And while there is time to sit down and actually work on it. And I think Node was just such an idea that was waiting for someone to grab it, and if it weren’t for me, someone else would have done it. But it so happened that I was then quite free from work and had the time, and I could work non-stop for several months, which were just needed to roll out the initial version. So yes, it was a great period.
- Great, super. Node is built on the idea of a “completely asynchronous” programming model. Was it successful for Node?
Ryan: - Yes, this is a very interesting question. For several years now, I’m not working on Node, well, somewhere around 2012 or 2013. And Node, of course, is a big project today. So yes, I think ... when she just got out, I drove around and spoke at conferences trying to convince people that they should ... that maybe we are doing the I / O subsystem completely wrong and that, maybe, if everything started to be done in a non-blocking style, we could solve a huge number of difficulties in programming on Node. Well, as, for example, we could forget about threads completely and use only abstractions of processes and serialized communication between them. But in one process, we could process many requests at once, being completely asynchronous. I was an ardent supporter of this idea at that time, but after a couple of years, I realized that this was not the best idea, solving all programming problems. In particular, when the Go language came out ... more precisely, Go came out a long time ago, but when I first started hearing about it, it was somewhere around 2012, they actually had a very nice runtime in which there were normal “ green streams ”and they really built abstractions around them, and I started thinking about blocking I / O again - well,“ blocking ”in quotation marks — because it's again all in“ green streams ”... between Go and the operating system, so which in essence, I think, is still non-blocking I / O.
But the interface that they provide to the user is still blocking, and it seems to me that it actually provides a much more convenient programming model. And when it is blocking, it, in many situations, allows you to understand much more clearly what you are actually doing. Well, it’s kind of like, you know, if you have several actions, it’s good if you can just think so: do this thing A, wait for an answer, it may be a mistake. Then do thing B, wait for the answer, check the error. And in Node, it’s a lot more complicated because you have to jump into the call of another function for this.
- Yes, I also like the programming model in Go. Using goroutine is much easier and fun. By the way, we also use Go at work for distributed systems.
Ryan: - Yes, I think that for a certain class of applications, such as servers, if you write a server, I can’t imagine a language other than Go. In general, the non-blocking paradigm in Node worked really well for JavaScript, where you don't have threads. And I think that many of the problems with callback hell when you need to jump into a bunch of different functions to finish what you are doing are pretty well resolved these days using async, for example, which is now in JavaScript. That is, as it were, the new versions of Javascript make life a little easier. Given all this, I would say Node is not the best system for massive web servers, I would use Go for this. And, honestly, this is just the reason why I left Node. It was an awareness: oh, well, really, this is far from the best system for server software.
Yes, I think that Node actually really showed itself, oddly enough, on the client side. Like scripting for building websites, or browserify, or bundles for client-side Javascript code. Well, or what can you do all this server part of the processing of client Javastipt code. And then, you know, there can be a small server, purely for development, here and there, and then there can be a real server in production that will receive real traffic. Node may be useful, or it may just be your choice. But if you are writing a distributed DNS server, I would not choose Node.
- Tell us how the initial development of Node went. It's been a while since you created Node in 2009. Ryan: - I personally think that there is no better moment in life when, as they say, you’re in a stream and you have an idea that you strongly believe in. And while there is time to sit down and actually work on it. And I think Node was just such an idea that was waiting for someone to grab it, and if it weren’t for me, someone else would have done it. But it so happened that I was then quite free from work and had the time, and I could work non-stop for several months, which were just needed to roll out the initial version. So yes, it was a great period.
- Great, super. Node is built on the idea of a “completely asynchronous” programming model. Was it successful for Node?
Ryan: - Yes, this is a very interesting question. For several years now, I’m not working on Node, well, somewhere around 2012 or 2013. And Node, of course, is a big project today. So yes, I think ... when she just got out, I drove around and spoke at conferences trying to convince people that they should ... that maybe we are doing the I / O subsystem completely wrong and that, maybe, if everything started to be done in a non-blocking style, we could solve a huge number of difficulties in programming on Node. Well, as, for example, we could forget about threads completely and use only abstractions of processes and serialized communication between them. But in one process, we could process many requests at once, being completely asynchronous. I was an ardent supporter of this idea at that time, but after a couple of years, I realized that this was not the best idea, solving all programming problems. In particular, when the Go language came out ... more precisely, Go came out a long time ago, but when I first started hearing about it, it was somewhere around 2012, they actually had a very nice runtime in which there were normal “ green streams ”and they really built abstractions around them, and I started thinking about blocking I / O again - well,“ blocking ”in quotation marks — because it's again all in“ green streams ”... between Go and the operating system, so which in essence, I think, is still non-blocking I / O.
But the interface that they provide to the user is still blocking, and it seems to me that it actually provides a much more convenient programming model. And when it is blocking, it, in many situations, allows you to understand much more clearly what you are actually doing. Well, it’s kind of like, you know, if you have several actions, it’s good if you can just think so: do this thing A, wait for an answer, it may be a mistake. Then do thing B, wait for the answer, check the error. And in Node, it’s a lot more complicated because you have to jump into the call of another function for this.
- Yes, I also like the programming model in Go. Using goroutine is much easier and fun. By the way, we also use Go at work for distributed systems.
Ryan: - Yes, I think that for a certain class of applications, such as servers, if you write a server, I can’t imagine a language other than Go. In general, the non-blocking paradigm in Node worked really well for JavaScript, where you don't have threads. And I think that many of the problems with callback hell when you need to jump into a bunch of different functions to finish what you are doing are pretty well resolved these days using async, for example, which is now in JavaScript. That is, as it were, the new versions of Javascript make life a little easier. Given all this, I would say Node is not the best system for massive web servers, I would use Go for this. And, honestly, this is just the reason why I left Node. It was an awareness: oh, well, really, this is far from the best system for server software.
Yes, I think that Node actually really showed itself, oddly enough, on the client side. Like scripting for building websites, or browserify, or bundles for client-side Javascript code. Well, or what can you do all this server part of the processing of client Javastipt code. And then, you know, there can be a small server, purely for development, here and there, and then there can be a real server in production that will receive real traffic. Node may be useful, or it may just be your choice. But if you are writing a distributed DNS server, I would not choose Node.