Express author TJ farewell Node.js toward Go_node.js

First of all this is a translation from TJ's farewell Node.js, I myself after reading this article is indeed some impact, but I do not agree with some of the author's views, such as I think Node.js's package register is one of its many advantages, but go on this side There is a slight lack of noodles. Because the personal level is limited, in the translation time has many does not understand the place, I also went to the author blog, StackOverflow asked some questions, obtained the solution. There are still a lot of places that are not in place and hope to be given advice.

PS. As a node.js beginner, thanks to TJ's dedication, all the way.

Body:

Farewell to Node.js

Leave the Node.js field

I have been fighting with node.js in production for long enough, and unfortunately, since I no longer enjoy the job, at least for now, this is my formal farewell. More importantly, I need defenders.

Node is really great in some ways, but it's not the right tool for the type of software I'm interested in lately. I still plan to do site with node, but if you are interested in maintaining any project, just leave a message and write down your github username, NPM username, and project name to let me know. Usually all I ask is that you not completely change the existing API, and if you do, it's better to reopen 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 been in love with C, but every person engaged in C development work knows it is valuable but error prone. It is difficult to prove the choice of language in daily work, because it is not exactly the fastest job. Simplicity is also a reason to compliment it, but without a lot of templates you won't go far.

As more and more participate in the development of distributed systems, the high availability and robustness of node performance has made me more frustrated. Over the last one weeks, I've rewritten a relatively large distributed system with go, which is more robust, better, and easier to maintain, and has better testable coverage because of the generally more graceful and easy to develop synchronization code.

I'm not saying go is a holy grail, it's not perfect, but for the many languages that exist today, go to me is an excellent answer. As more and more of these "generational" languages like Rust and Julia find their place and mature, I'm sure we'll have more great solutions.

Personally I'm excited about the go language because of his iterative speed, excited to see that they are eager to reach the 2.0 version, and as far as I hear, they are not afraid to break the great things. If it is true, I would be happy to, more because I believe that if it is really beneficial to the language, it should quickly break the existing things. But I'm also not a software giant running a lot of systems. :D

Editor: I must have misinterpreted some of the submitted mailing lists, and they were not eager to make some destructive changes at any time. @enneff

Why go?

If node works for you and you have nothing to worry about, it is still a good tool. But if something bothers you, don't forget to jump out of your box and see what else is outside the box-I've been attracted to the first few hours of using go to build a product.

Again, I'm not saying go is definitely the best language and you have to use it. But for its age, it is very mature and robust. (roughly the same age as node). The refactoring of types is fun and simple, and the jobs and debugging tools offered by Go are great, and the community has a very powerful set of regulations for documents, formats, benchmarks, and API design.

While I was so used to the extremely modular node and the standard library that experienced Ruby decay, when I first heard go, I thought its standard library was bad. After I got into the language, I realized that the great part of the standard library at this stage was necessary, such as compression, JSON, IO, buffered io, string manipulation, and so on. Most of these APIs are well defined and powerful. It is easy to write the entire program simply by using these standard libraries.

Third party Go Packages

Most of the go libraries look alike, and most of the Third-party code I've used so far is high quality, and it's hard to find them in node because JavaScript attracts developers at different levels of skill.

There is no registration center for GO packages, so you'll usually see 5 or 6 of the same package. In some cases, this can create some confusion, but it has an interesting side effect, you have to carefully review each package to determine which is the best solution. Node usually has canonical packages such as "Redis", "mongodb-native" or "zeromq", so you will stop there and infer that they are the best.

If you are doing some distributed work, you will find that the impressive concurrent underlying data types of go are very helpful. We can get something similar by generators in node, but in my opinion, generators is only half done. There is no independent error handling, report stack even the best is still trivial. I don't want to wait for the community to regroup for three years when these programs are working well.

In my opinion, Go's error handling is outstanding. Node is great when you have to think about every mistake and decide what to do. Node failed however in:

You may be repeating the callback.

You may not even be able to get a callback lost in a state of instability (such as forgetting to pass the error-handling callback, and when the error occurs, Node will swallow the error without any feedback)

You might get a mistake with the takeout.

Emitters may get multiple error events

The process of forgetting the wrong thing can ruin everything.

Often unsure what to do with the wrong handling

Error handling is very redundant

The callback sucks.
In the go language, when my code ends, it's over, and you can't do it again in the statement. This is not certain in node. You would think that a program was completely executed until a library accidentally invoked a callback multiple times, or did not properly clear the handlers and then cause the code to execute again. It is quite difficult to find these reasons in the actual production code, why bother with these? Other languages will not let you experience the pain.

The future node

I still want node to do well and a lot of people are investing heavily in him, and it does have the potential. I think joyent and the team need to focus on usability-if your application is fragile and difficult to debug, refactor, and develop, performance is meaningless.

The fact that we will still have this vague error of "Error:getaddrinfo Eaddrinfo" in 4-5 years tells us where node's development priorities are. Understandably, when you focus on building the core of your system, it's easy to miss out on these things. I think that the user has once again expressed their views on such things without seeing any results. For those who claim that what we have is perfect, we usually get a few responses. In practice, this is not the case.

The streams are interrupted, the callbacks are not easy to use, the errors are ambiguous, the tools are not working, the Community regulations are there, and they are scarce relative to go. Still, I might continue to use node for certain tasks, such as creating Web pages, or some fragmented APIs or prototypes. If node can fix some of its basic problems, it has the opportunity to remain relevant, but the argument that performance is higher than usability when another scenario is higher performance and higher availability won't go too far.

If the node community decides to embrace generators and implement them at the very core of the node, to properly pass the error, there is a chance that this is to be referenced. This will drastically improve node availability and robustness.

The good news is that I've been talking to some of the great and talented guys in Strongloop's core code a few moments ago. They are explicitly using the right way to make future node easier to work by listening to the developer's response to the platform and planning to find the correct ways to fix the problems. I'm not sure how a number of companies will end up conflicting with the core, but I hope the developer driver will win.

This does not mean that this is an attack on individuals, that many really gifted people are working with node or on node, but this is no longer my area of interest. I've had a great time in the node community and I've met some really interesting people.

The moral of the story is not to be limited by your own circle! Look elsewhere for what you might be able to enjoy programming again. There are a lot of great solutions out there, and my mistake is to wait too long to play with them!