Creator of Node.js: “For servers, I can’t imagine another language other than Go”
Translation of an excerpt from an interview with Node.js creator Ryan Dahl (Ryan Dahl) which discusses the programming model and the Go language.
- Tell us, how did the initial Node design go? This was already quite a long time ago, you created Node in 2009.
Ryan : - I think for myself that there is no better moment in life when, as they say, you are “in the flow” 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 not for me, someone else would have done it. But it so happened that I was then fairly free from work and had time, and 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, great. Node is built on the idea of a “fully asynchronous” programming model. Was she successful for Node?
Ryan : - Yes, this is a very interesting question. For several years now, as I have not been working on Node, well, somewhere around 2012 or 2013. And Node, of course, is a big project today. So yes, I think ... when she first came out, I drove around and spoke at conferences, trying to convince people that they should ... that maybe we were doing the I / O subsystem incorrectly and that maybe if we started to do everything in non-blocking style, we could solve a huge amount of difficulties in programming on Node. Well, for example, we could forget about threads completely and use only process abstractions 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 the time, but after a couple of years, I realized that it was not the best idea that solved all the problems in programming. In particular, when the Go language came out ... more precisely, Go came out quite a long time ago, but when I first started hearing about it, it was somewhere around 2012, they actually had a very pleasant 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 quotes - because again, everything is in“ green streams ”... between Go and the operating system, so which in fact, I think, is non-blocking I / O.
But the interface that they provide to the user is still blocking, and it seems to me that it actually gives a much more convenient programming model. And when it is blocking, in many situations, it allows you to understand much more clearly what you are actually doing. Well, sort of, you know, if you have several actions, well, if you can think like that right: do this thing. And wait for an answer, maybe fall with an error. Then make a piece B, wait for an answer, check the error. And in Node it is much more difficult, because you have to jump to the challenge of another function for this.
- Yes, I also like the Go programming model. Using gorutin is much easier and fun. We, by the way, also use Go at work for distributed systems.
Ryan : - Yes, I think that for a certain class of applications, such as servers, if you are writing a server, I can’t imagine another language other than Go. In general, the non-blocking paradigm in Node worked very well for javascript, where you don't have threads. And I think that many of those 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, however, new versions of Javascript make life a little easier. Considering 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 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 actually 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-side processing of client Javastipt-code. And then, you know, there may be a small server, purely for development, here and there, and then a real production server, which will receive real traffic. A node can be useful, or it can be just your choice. But if you are writing a distributed DNS server, I would not choose Node.
- Tell us, how did the initial Node design go? This was already quite a long time ago, you created Node in 2009.Ryan : - I think for myself that there is no better moment in life when, as they say, you are “in the flow” 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 not for me, someone else would have done it. But it so happened that I was then fairly free from work and had time, and 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, great. Node is built on the idea of a “fully asynchronous” programming model. Was she successful for Node?
Ryan : - Yes, this is a very interesting question. For several years now, as I have not been working on Node, well, somewhere around 2012 or 2013. And Node, of course, is a big project today. So yes, I think ... when she first came out, I drove around and spoke at conferences, trying to convince people that they should ... that maybe we were doing the I / O subsystem incorrectly and that maybe if we started to do everything in non-blocking style, we could solve a huge amount of difficulties in programming on Node. Well, for example, we could forget about threads completely and use only process abstractions 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 the time, but after a couple of years, I realized that it was not the best idea that solved all the problems in programming. In particular, when the Go language came out ... more precisely, Go came out quite a long time ago, but when I first started hearing about it, it was somewhere around 2012, they actually had a very pleasant 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 quotes - because again, everything is in“ green streams ”... between Go and the operating system, so which in fact, I think, is non-blocking I / O.
But the interface that they provide to the user is still blocking, and it seems to me that it actually gives a much more convenient programming model. And when it is blocking, in many situations, it allows you to understand much more clearly what you are actually doing. Well, sort of, you know, if you have several actions, well, if you can think like that right: do this thing. And wait for an answer, maybe fall with an error. Then make a piece B, wait for an answer, check the error. And in Node it is much more difficult, because you have to jump to the challenge of another function for this.
- Yes, I also like the Go programming model. Using gorutin is much easier and fun. We, by the way, also use Go at work for distributed systems.
Ryan : - Yes, I think that for a certain class of applications, such as servers, if you are writing a server, I can’t imagine another language other than Go. In general, the non-blocking paradigm in Node worked very well for javascript, where you don't have threads. And I think that many of those 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, however, new versions of Javascript make life a little easier. Considering 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 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 actually 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-side processing of client Javastipt-code. And then, you know, there may be a small server, purely for development, here and there, and then a real production server, which will receive real traffic. A node can be useful, or it can be just your choice. But if you are writing a distributed DNS server, I would not choose Node.
Source: https://habr.com/ru/post/337098/
All Articles