Belitsoft > Node.js vs Go

Node.js vs Go

Ryan Dahl, 36-years old brilliant programmer, is the creator of Node.js, JavaScript runtime built on Chrome’s V8 JavaScript engine. He showed us how to do I/O right way and also taught us how to build software using pure async programming model. Currently, he is a software engineer at Google Brain working on deep learBrowserifyning research projects. His focus is mostly on image-to-image transformations like colorization and super-resolution. He has contributed to several open source projects including HTTP Parser, libuv. In his recent interview (2017), Ryan Dahl has told when it's better to use Node.js and why he uses Go for custom software development.


"My programming career started when I was working on the Ruby on Rails website for a snowboard company. I guess I liked how Ruby made development so much more, I guess, you could express your ideas more clearly in Ruby. And that was interesting at the time. And I think Rails was impressive in that. It gave this new structure, and probably, it wasn’t new, but I think Rails popularized the structure of model view controller. I started going to Ruby conferences in Germany, where people were talking about this new paradigm of model view controller. And one of the guys there was Chris Neukirchen if I’m pronouncing that correctly. And he developed this project called Rack, which was a simplified abstraction of a web server. So, it turned a web server into a single-function interface, where you get a request, and then you return a response."

That, combined with some freelance work that I was doing on Nginx Module, for Engineyard, got me thinking about how… let me step back a second. In Nginx, everything is asynchronous. So, when you build a module for it, you have to be very careful to be non-blocking. And yeah, I think the combination of Chris Neukirchen’s rack plus how Nginx structured its web server with non-blocking IO, led me to start thinking about how those two things could be combined.

So, those two pieces that kind of simplified web server interface, which was Rack, and the asynchronous part, which was Nginx, I had been thinking about. And then Chrome was released in December 2008. And along with that was the V8 Javascript interpreter. I shouldn’t say, interpreter. It’s a jitted run-time. So, when V8 came out, I started poking around with it, and it looked fascinating and clean, and fast, and suddenly, I clicked that: oh! Javascript is single-threaded, and everybody is already doing non-blocking.

I’m using my fingers to do air quotes, but like in the web browser, people are already making non-blocking requests when they make AJAX request and stuff.

‘And I thought: oh, wow! I think JavaScript plus asynchronous IO plus some HTTP server stuff would be a cool thing. And I was so excited about that idea that I just worked on it non-stop for the next four years.’

I think Node was an idea waiting to happen and had I not done it; somebody else would have. 

I haven’t worked on Node myself since like, 2012, or 2013. And Node, of course, is a big project at this point. When it first came out, I went around and gave a bunch of talks, trying to convince people that they should. That maybe we were doing I/O wrong and that maybe if we did everything in a non-blocking way, that we would solve a lot of the difficulties with programming. Like, perhaps we could forget about threads entirely and only use process abstractions and serialized communications. But within a single process, we could handle many, many requests by being completely asynchronous.

‘I believe strongly in this idea at the time, but over the past couple of years, I think that’s probably not the end-all and be-all idea for programming. In particular, when Go came out.’

Well, I think Go came out a long time ago, but when I first started hearing about Go, which was around 2012. They had a very nice runtime that had proper green threads and easy to use abstractions around that. That I think makes blocking I/O – again, blocking I/O in quotes, because it’s all in green threads at the interface of… between Go and the operating system, I think it is all non-blocking I/O.

But the interface that they present to the user is blocking, and I think that that’s a nicer programming model. And you can think through what you’re doing in many situations more easily if it’s blocking. You know, if you have a bunch of following actions, it’s nice to be able to say: do thing A, wait for a response, maybe error out. Do thing B, wait for a response, error out. And in Node, that’s harder, because you have to jump into another function call.

I believe strongly in this idea at the time, but over the past couple of years, I think that’s probably not the end-all and be-all idea for programming. In particular, when Go came out.

‘Yeah, I think it’s… for a particular class of application, which is like, if you’re building a server, I can’t imagine using anything other than Go.’

That said, I think Node’s non-blocking paradigm worked out well for JavaScript, where you don’t have threads. And I think that a lot of the problems with kind of the call-back soup problem, where you have to jump into many anonymous functions to complete what you’re doing has been alleviated these days, with the async keyword, the async feature that’s in Javascript now.

So, kind of the newer versions of Javascript has made this easier. That said, I think Node is not the best system to build a massive server web. I would use Go for that. And honestly, that’s the reason why I left Node. It was the realization that: oh, actually, this is not the best server-side system ever.

‘I think where Node has shined, weirdly, on the client side. So, doing kind of scripting around building websites. So, Browserify, for example. Kind of bundles up client-side Javascript. So, you can have all this server-side processing of client-side Javascript. And then, you know, maybe small servers to… maybe little development servers, and here and there, maybe some real servers serving live traffic. Node can be useful, or it can be the right choice for it. But if you’re building a massively distributed DNS server, I would not choose Node.

So, there were several people, that were trying to get the server side JavaScript thing going. 

The thing is that they were all doing blocking I/O, and that didn’t jive with how Javascript is structured because you don’t have threads. And so, if you’re doing blocking I/O, you literally can’t serve requests. Like, you’re doing one at a time, and that’s just never going to work. That, plus the fact that I like, sat down and made the HTTP server work well. So, I had a demo where you could… I had an HTTP server, and then a raw TCP server. And I made those things work well so that people could sit down and build a website without going through too much hassle.

And honestly, building a web server is not the easiest thing, and I think a lot of these systems kind of left to their community to make that, and thus, nobody did. Because there is nothing to use the system with. I think it’s important that when you release a software framework, or maybe any software, that you have a demo that people can sit down and use immediately. And that was one of the things that went right with Node; it was that people could download it and use the web server directly.

I think we take for granted how easy it is to switch between languages. I mean, even if you know another language, making that context, which is pretty difficult. And there’s a lot of people who are very familiar with Javascript. And giving them these tools to be able to use it in other contexts excites people. You suddenly can do it a lot more than you were able to do before.

I had been working on Node for four years. And I had gotten to the point where I wanted it. I never wanted Node to be a massive API. I wanted it to be this kind of small, compact, core that people could build modules on top of.

And there was a couple of the main things that… key features that I wanted to support. So, extension modules were added early on; we got all the networking libraries worked out, HTTP, UDP, TCP, we could access all the file systems.

And then, kind of a big chunk, which was maybe a year of work with like, five people, was putting it to Windows and doing that properly. And that we wanted to use Windows abstractions for asynchronous IO, which is their IO completion ports. And so, that required rewriting the core library, which, the result of that was the libuv library.

We had released on Windows. And you know, it was kind of at the point where it’s like: ok. I mean, this is what I had intended to create, and I’m pleased I got the chance to follow through with it. And of course, there’s going to be, you know, an infinite amount of bugs to fix for the rest of my life, but… you see, there are enough people involved to that. I don’t need to do that necessarily, and I would like to do other things. So, that plus the fact that Go came out, and I didn’t see Node as being the ultimate solution to servers. 

Node is used by hundreds of thousands, if not millions of people at this point, and I think it’s certainly exceeded any expectation of what I thought would happen with it. Yeah, it’s cool."

Never miss a post! Share it!

Written by
Partner / Department Head
"I've been leading projects and managing teams with core expertise in ERP development, CRM development, SaaS development in HealthTech, FinTech and other domains for 15 years."
0 reviews

Rate this article

Our Clients' Feedback

Let's Talk Business
Do you have a software development project to implement? We have people to work on it. We will be glad to answer all your questions as well as estimate any project of yours. Use the form below to describe the project and we will get in touch with you within 1 business day.
Contact form
We will process your personal data as described in the privacy notice
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply
Call us

USA +1 (917) 410-57-57

UK +44 (20) 3318-18-53

Email us

[email protected]


13-103 Elektoralnaya st,
00-137 Warsaw, Poland

to top