Express author TJ bids farewell to Node.js and heads to Go_node.js

First of all, this is an article translated from TJ's Farewell Node.js. I was really shocked after reading this article, but I don't agree with some of the author's views. For example, I think Node. js's package register is one of its many advantages, but Go is slightly lacking in this aspect. Due to my personal limitations, there were many things I didn’t understand when translating. I also went to the author’s blog and stackoverflow to ask some questions and got answers. There are still many imperfections in the translation, and I hope you can get some pointers.

PS. As a newbie in Node.js, I would like to thank TJ for his hard work and have a good journey.

Text:

Farewell Node.js

Leave Node.js realm

I've been fighting with Node.js in production for long enough, and unfortunately now that I no longer enjoy doing the job, at least for the moment, this is my official farewell. More importantly, I need maintainers.

Node is great in some ways, but it’s not the right tool for the type of software I’m interested in these days. I still plan to use Node for the website, but if you are interested in maintaining any projects, just leave a comment with your Github username, npm username, and project name to let me know. Usually all I ask is that you don't completely change the existing API. If you really want to do this, it's better to start a new project.

Koa is a project that I will continue to maintain. (With Co and friends)

The Story of the Holy Grail

I have always loved C, but everyone who works in C development knows that it is valuable but error-prone. It's hard to justify language choice in day-to-day work because it's not exactly the fastest for the job. Simplicity is also why it's always praised, but you won't get very far without a ton of templates.

As I get more involved in the development of distributed systems, the trend of Node performance being higher than availability and robustness makes me more and more frustrated. Over the past week, I have rewritten a relatively large distributed system in Go to make it more robust, performant, and easier to maintain, and because synchronous code is generally more elegant and easier to develop, it has more Good testable coverage.

I’m not saying Go is the Holy Grail, it’s not perfect, but for many languages ​​that exist today, Go is an excellent answer to me. As more of these "next generation" languages ​​like Rust and Julia find their niche and mature, I'm sure we'll have more great solutions.

Personally, I am very excited about GO language because of his iterative speed. I was very excited to see them eager to reach version 2.0, and according to the news I heard, they were not afraid and broke the original Great things. I'd love it if it were true, mostly because I believe that if it's really good for the language, it should break existing things quickly. But I'm also not a software giant running a lot of systems. :D

Editor: I must have misinterpreted some of the submissions to the mailing list; they were not eager to make breaking changes at any time. @enneff

Why Go?

If Node works for you and you have nothing to worry about, it's still a great tool. But if something bothers you, don't forget to step outside your box and see what's outside the box - within the first few hours of building a product with Go, I was already hooked.

Again, I'm not saying that Go is the absolute best language and you have to use it. But it is very mature and strong for its age. (Roughly when I was the same age as Node). Type refactoring is fun and simple, the job and debugging tools provided by Go are great, and the community has very strong regulations on documentation, formats, benchmarks, and API design.

Being so used to the extreme modularity of Node and having experienced Ruby’s rotten standard library, when I first heard about Go, I thought its standard library was terrible. After I got deeper into this language, I realized that most of the standard libraries at this stage are very necessary, such as compression, json, IO, buffered IO, string operations, etc. Most of these APIS are well defined and powerful. It is easy to write entire programs just by using these standard libraries.

Third-party Go packages

Most of the Go libraries look similar, and most of the third-party code I've used so far is of high quality, which is hard to find in Node because JavaScript attracts different skill levels developers within scope.

For Go packages, there is no registration center, so you usually see 5 or 6 of the same packages at the same time. This can cause some confusion at times, but it has the interesting side effect that you have to carefully review each package to decide which one is the best solution. By Node there are usually canonical packages like "redis", "mongodb-native" or "zeromq", so you'll stop there and just deduce that they are the best one.

If you’re doing some distributed work, you’ll find Go’s impressive concurrency base data types to be very helpful. We can achieve something similar with generators in Node, but in my opinion, generators are only half the job. Without independent error handling, the reporting stack is still mundane at its best. When these solutions are working well, I don't want to wait for three years for the community to reorganize.

In my opinion, Go’s error handling is outstanding. Node is great in the sense that you have to consider every error and decide what to do. However, Node fails at:

You may perform callbacks repeatedly

You may not make callbacks at all and get lost in an unstable state (for example, if you forget to pass an error handling callback, when an error occurs, Node will swallow the error without any feedback)

You may get out-of-box errors

emitters may get multiple wrong events

Forgetting the wrong event handling will ruin everything

Often unsure of what needs to be done incorrectly

Error handling is very redundant

Callbacks suck
In Go, when my code ends, it ends and you can't re-execute within the statement. In Node this is undefined. You would think that a program is completely executed until a library accidentally calls a callback multiple times, or fails to clear handlers properly and causes the code to be executed again. It's quite difficult to find these reasons in actual production code, so why bother? Other languages ​​don't put you through this pain.

Node of the future

I still hope Node does well and many people invest heavily in it, it does have such potential. I think Joyent and the team need to focus on usability - performance is meaningless if your application is brittle and difficult to debug, refactor, and develop.

The fact that we will still have this vague error "Error: getaddrinfo EADDRINFO" in 4-5 years tells us where Node's development priorities are. Understandably, it's easy to miss these things when you focus on building the core of the system. I think users have voiced their opinions on this type of thing time and time again without seeing any results. We usually get a handful of responses to claims that what we have is already perfect. In practice, this is not the case.

Streams are interrupted, callbacks are not easy to use, errors are unclear, and tools are not easy to use. There are community regulations, but they are lacking compared to Go. Despite this, I may continue to use Node for some specific tasks, such as creating web pages, or some scattered APIs or prototypes. If Node can fix some of its fundamental problems, it has a chance of staying relevant, but the argument for performance over availability doesn't go very far when there's an alternative that is both higher performance and higher availability.

If the Node community decides to embrace generators and implement them in a very core part of Node, and properly propagate errors, there is a chance that this can be referenced. This will drastically improve Node's availability and robustness.

The good news is that a while ago I spoke with the amazing and talented guys who contribute the core code to StrongLoop. They are taking a clear approach by listening to developer responses to the platform, and plan to find the right way to fix these issues to make Node easier to work with in the future. I'm not sure how the conflict over simultaneous development of core parts by multiple companies will end, but I hope the developer-driven side will win out.

This isn’t meant to be a personal attack, there are a lot of really talented people working with or on top of Node, but that’s not where I’m interested anymore. I've had a great time in the Node community and met some really interesting people.

The moral of the story is, don’t be limited by your own circle! See what's available elsewhere and you might enjoy programming again. There are so many great solutions out there, I made the mistake of waiting too long to play with them!