TJ Holowaychuk: Goodbye Node.js

Note from the translator:

I decided to translate this article mainly because of the personality of the author. TJ put a lot of effort into the development of Node.js and its infrastructure, he is the author of such projects as express , jade , mocha , stylus , the author of 550 repositories on npm . There is also a theory that a group of people is hidden under this name .

Be that as it may, the JavaScript and Go communities are expecting changes in the near future.

Leaving the country Node.js

I fought Node.js long enough to stop enjoying it, this is my official farewell! And, more importantly, I'm looking for people who can support my projects!

Node does a great job with a few things, but unfortunately this is not the right tool for what I'm interested in right now. I still plan to use it for sites, but if you would like to get involved in supporting one of my projects, let me know. Just leave a comment with your name on Github, a link to npm and the name of the project. As usual, I ask you not to make big changes to the existing APIs: it will be easier to create a new project.

I will also continue to support Koa .

Holy grail

I always liked C, but everyone who worked with C knows that even though this language can be fun, it is error prone. Now it’s quite difficult to justify the choice of this language as a tool for every day, since the speed of working with it is low. I always admired the simplicity, but in this case it is difficult to go far without a huge amount of boilerplate code.

The more time I devote to working with distributed systems, the more frustrating I am the direction in which Node is moving, preferring performance over usability and reliability. Last week, I rewrote a fairly large distributed system on Go. It is more reliable and faster, it is easier to maintain, and it has more test coverage: it is easier and more pleasant to work with synchronous code.

I'm not saying that Go is the “Holy Grail”, it is not perfect, but for me, among the languages ​​that currently exist, Go is a great choice. Over time, when next-generation languages ​​such as Rust and Julia find use and mature, I’m sure that the number of great solutions will increase.

Personally, Go was most impressed with the speed of language development. It is very impressive to see how developers strive for 2.0 and, as I heard, are not afraid to break backward compatibility, which is great.

AMENDMENT: I ​​apparently read the newsletter incorrectly, no critical changes are planned in the near future.

It would be cool if that were the case, I believe that the rejection of backward compatibility helps the language develop, although I am not a software corporation supporting giant systems

Why go?

Node is still a great tool and if you like everything, then there is no reason to worry. But if you have any doubts, do not be too lazy to look around and see what else is around - I got hooked on Go in the very first few hours of using it in production.

Once again, I do not claim that Go is the best language in the world, and you definitely need to start using it, but it is very mature and reliable for its age (it is about the same as Node.js), refactoring with types is simple and nice, the tools that Go provides for profiling and debugging work fine, and the community has an established understanding of documentation, formatting, speed measurement, and API design

At the time I first got to know Go, the standard library seemed just awful, mainly because I got used to ultra-modularity in Node and saw the standard library rot in Ruby. When I started working more with the language, I realized that most of stdlib Go plays an important role in software development: compression, JSON, buffered I / O, string operations and more. Most of these APIs are well thought out and powerful. You can write entire programs, mostly using only the standard library.

Third-party Go libraries

Many Go libraries look and feel the same, most of the third-party code that I have worked with so far is of fairly good quality, which is not often the case with Node, because JavaScript attracts people with the most diverse levels of knowledge and skills.

There is no single repository for Go libraries, so you can often find 5 or 6 different packages with the same name, which can sometimes cause confusion, but this also has a useful side: you need to carefully check each one to choose the best solution. Node has common modules like redis, mongodb-native, or zeromq, so you can assume that this is the best option and stop the search.

Go or Node?

If you work a lot on distributed projects, then Go's primitives for parallelization will seem to you expressive and useful. We could do similar things in Node using generators, but in my opinion, generators will only allow us to go halfway. If we do not have separate processing and reports for stack errors, we will get very average results. I also do not want to wait three years for the community to give birth to something, when there are ready-made solutions that work fine.

Error handling, in my opinion, is much better implemented in Go. Node allows us to make decisions for every single mistake we take, but there are a few things where Node is doing poorly:

• You may have duplicate callbacks
• Callback call may get lost along the way
• You may have errors in general from other threads
• Several events of the "error" type may come to the emitter handler
• If you don’t catch the mistake, then everything will go to hell
• It is often unclear how errors are handled.
• Error handlers are too verbose
• Callbacks sucks

In Go, if my code is executed, it is executed, you cannot execute the statement again. In Node, this is not so. It may seem to you that the code has finished executing, exactly until the moment when the library accidentally launches callback several times, or incorrectly clears the handlers, which will cause the code to execute again. It’s not easy to deal with this, especially when the code is already in production, and why? Other languages ​​will not make you suffer so much

Node in the future

I still hope that Node will be all right, a lot of people have put their work into it and it has potential. I believe that Joyent and the team should focus on usability: performance means nothing if your application is difficult to debug, refactor, and develop.

The presence of errors, like “Error: getaddrinfo EADDRINFO”, after 4-5 years, shows the prioritization. It is clear that you can skip such trifles if you concentrate your efforts on developing the core of the system, but users repeatedly remind about it and the results are still not visible. We usually get answers from people from the "elite" who claim, and now everything is perfect, but, in fact, everything is different.

Streams are broken, it is inconvenient to work with callbacks, error messages are vague and incomprehensible, tools are not enthusiastic, there are community agreements, but they are still far from what Go has. Given all of the above, there is a set of tasks for which I will continue to use Node: sites, maybe some prototype or API. If Node can fix its main problems, then it has a good chance of remaining useful, but the argument about preference for performance over usability does not work very well, given that there are solutions that are faster and more convenient.

I'm not trying to hurt someone personally, a lot of really talented people work with / on Node, but this is of no interest to me anymore. I had a great time in this community and met quite a few cool people.

The moral of this story is this: do not live in a bubble, look around and see what else is around, maybe you will love programming again. There are many great solutions around and my mistake was that I waited too long to go and try them.

Note from the translator:

Shortly before the appearance of the translated article, a note from Will Yager was published with the opposite opinion: Why Go is bad (eng.) , It would be great if someone familiar with Go would take up the translation to complete the picture.
UPD: And here is the translation