TJ Holowaychuk: Goodbye Node.js

Note from the translator:

I decided to translate this article mainly because of the identity of the author. TJ has 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 at npm . There is also a theory that under this name is a group of people .

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

Leaving country Node.js

I fought with Node.js long enough to stop getting pleasure from it, this is my official farewell! And, more importantly, I am looking for people who can support my projects!

Node does an excellent job with some things, but, unfortunately, it is not the most suitable tool for what I'm interested in right now. I still plan on using it for sites, but if you would like to support 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 major changes to 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 enjoyable, it is prone to errors. It is now quite difficult to substantiate the choice of this language as a tool for every day, since the speed of working with it is small. I have always admired simplicity, but in this case it is difficult to go far without a huge amount of sample code.

The more time I devote to working with distributed systems, the more I am upset by the direction in which Node is moving, preferring performance over ease of use 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 do not say that Go is the “Holy Grail”, it is not perfect, but for me, among the existing languages, Go is an excellent choice. Over time, when next-generation languages ​​such as Rust and Julia will find their application and mature, I am sure that the number of excellent solutions will increase.

Personally, I was most impressed with the speed of language development. It's quite 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 for the near future.

It would be cool if that were the case, I believe that the rejection of backward compatibility helps the language to develop, although I’m 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 lazy to look around and see what else is there - I got hooked on Go in the first few hours of using it in production.

Once again, I'm not saying that Go is the best language in the world, and you definitely need to start using it, but it is quite mature and reliable for its age (it is about the same as Node.js ), refactoring with types is simple and pleasant, the tools that Go provides for profiling and debugging work fine, and the community has well-established ideas about documentation, formatting, speed measurement, and API design

At the time of my first acquaintance with Go , the standard library seemed to me just awful, mainly because I was used to ultra-modularity in Node , and saw how the standard library in Ruby was rotting. 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, mainly 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 worked with until now is of fairly good quality, which is not often the case with Node , because JavaScript attracts people with very different 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 it also has a useful side: you need to carefully check each to select the best solution. In Node, there are generally accepted modules, like “redis”, “mongodb-native”, or “zeromq”, so we can assume that this is the best option and stop the search.

Go or Node?

If you work a lot on distributed projects, the primitives for parallelization in Go will seem expressive and useful to you. We could do similar things in Node with the help of generators, but in my opinion, generators will allow us to go only half the way. If we don’t have separate processing and reporting for stack errors, we’ll get very average results. I also do not want to wait three years until the community gives birth to something, when there are ready-made solutions that work well

Error handling, in my opinion, is implemented in Go much better. Node allows us to make decisions for each individual error taken, but there are a few things where Node is bad:

• You may have duplicate callbacks
• A callback call may be lost along the way.
• You may have errors in general from other threads.
• Several error events can come to the emitter handler.
• If you do not catch the error, then everything will fly to hell
• Often it is not clear how errors are handled.
• Error handlers are too verbose
• Callback and sucks

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

Node in the future

I also hope that Node will be all right, a lot of people have invested their work in him and he 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 declare, and now everything is perfect, but, in fact, everything is different.

Streams are broken, inconvenient to work with callbacks, error messages are vague and incomprehensible, tools do not cause delight, community agreements seem to be there, but they are still far from what is in Go. Considering all of the above, there is a set of tasks for which I will continue to use Node : sites, maybe some kind of prototype or API. If Node can fix its main problems, then it has good chances to remain useful, however, the argument about the preference of performance for ease of use 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 more interest to me. I had a great time in this community and met quite a few cool people.

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

Note from the translator:

Just before the translation of the article, a Will Yager note with the opposite opinion was published: 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