First of all, this is a article translated from TJ's Farewell Node.js. I have indeed suffered some impact after reading this article, but I do not agree with some of the author's views. For example, I think Node.js' package register is one of its many advantages, but Go is slightly lacking in this regard. Due to personal level, I don’t understand many things when translating. I also went to the author’s blog and stackoverflow to ask some questions to get answers. There are still many things that are not in place in the translation, and I hope to get a point of view.
PS. As a Node.js beginner, thanks to TJ for his efforts and go all the way.
text:
Say goodbye to Node.js
Leaving the Node.js realm
I've been fighting Node.js in production for long enough and unfortunately since I no longer enjoyed working on this job, at least at this moment, it's my official farewell. More importantly, I need a maintainer.
Node is really great in some ways, but it is not a suitable tool after all for the type of software I've been interested in lately. I still plan to use Node as a website, but if you are interested in maintaining any project, just leave a message to write down your Github username, npm username, and project name to let me know. Usually all I ask is that you do not completely change your existing API. If you really want to do this, it is better to start a new project.
Koa is a project 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 it is valuable but prone to errors. It is difficult to prove the choice of language in daily work, as it is not exactly the fastest job. Simplicity is also the reason why it has always been praised, but you won’t go very far without a lot of templates.
As more people participate in the development of distributed systems, the development trend of Node performance over usability and robustness has made me more frustrated. Over the past week, I've rewrite a relatively large distributed system in Go, which is robust, performs better, and is easy to maintain, and has better testable coverage due to the general beauty and easier to develop synchronous code.
I'm not saying Go is a holy grail, it's not perfect, but Go is an excellent answer to me for many languages that exist today. As more and more of these "next generation" languages like Rust and Julia find their own place and mature, I'm sure we'll have more great solutions.
Personally, I'm very excited about Go because of its iteration speed, I'm very excited to see that they are eager to reach version 2.0, and according to the news I've heard, they are not afraid of breaking the original great things. If it is true, I am happy, more because I believe that if it is really beneficial to this language, I should quickly break down what is already there. But I am not a software giant running a lot of systems either. :D
Edited by: I must have misinterpreted some submission mailing lists, and they are 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 great 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 it within a few hours of initially using Go to build the product.
Again, I'm not there to say Go is definitely the best language and you have to go with it. But for its age, it is very mature and robust. (At about the same age as Node). Type reconstruction is fun and simple, the homework and debugging tools provided by Go are great, and the community has very strong regulations on documentation, formats, benchmarks, and API design.
While being so accustomed to the extremely modular Node and having experienced Ruby's rotting standard library, when I first heard about Go, I thought its standard library was awful. After I dived into this language, I realized that most of the standard libraries are necessary at this stage, such as compression, json, IO, buffered IO, string operations, etc. Most of these APIs are well defined and powerful. It's easy to write the entire program just by using these standard libraries.
Third-party Go packages
Most Go libraries look similar, most of the third-party code I've used so far is of high quality, and it's hard to find these in Node because JavaScript attracts developers in different skill levels.
There is no registry for Go packages, so you will usually see 5 or 6 same packages at the same time. At some point, this can cause some confusion, but it has an interesting side effect, and you have to decide which one is the best option by carefully reviewing each package. Through Node, there are usually specification packages such as "redis", "mongodb-native" or "zeromq", so you'll stop there and infer that they're the best one.
If you are doing some distributed work, you will find Go's impressive concurrent underlying data types to be very helpful. We can get something similar by generators in Node, but in my opinion generators are only half done. Without independent error handling, reporting stack is still ordinary even if it is best. When these solutions work well, I don’t want to wait for the community to reorganize for three years.
In my opinion, Go's error handling is outstanding. Node is great in terms of what you have to think about every mistake and decide how to do it. However, Node fails in:
You might repeat the callback
You may not make a callback at all and get lost in an unstable state (for example, forget to pass an error to handle the callback. When an error occurs, Node will swallow the error without any feedback)
You might get the takeaway error
emitters may get multiple wrong events
Forgot the wrong event to deal with it will ruin everything
Often not sure what is needed to handle errors
The error handling is very redundant
The callback is terrible
In Go, when my code ends, it ends and you can't re-execute it in a statement. This is uncertain in Node. You'll think that a program is fully executed until a library unexpectedly calls a callback multiple times, or does not clear handlers correctly and then causes the code to be executed again. It is quite difficult to find these reasons in actual production code, why bother with these? Other languages won't let you experience these pains.
The Node of the Future
I still hope Node does a good job, many people invest hugely in him, and it does have that 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.
In 4-5 years we will still have this vague error "Error: getaddrinfo EADDRINFO", and this fact tells us where the development priorities of Node are. Understandably, when you focus on building the core of the system, it is easy to miss these things. I think users have expressed their opinions on such things again and again but have not seen any results. We usually get a few responses for claiming 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, tools are not easy to use, community regulations exist, but they seem lacking compared to Go. Despite this, I may continue to use Node for some specific tasks, such as creating web pages, or some fragmented APIs or prototypes. If Node can fix some of its fundamental problems, then it has a chance to remain relevant, but when there is another solution that performs higher than availability when higher performance and higher availability arguments don't go too far.
If the Node community decides to embrace generators and implement them in a very core Node and pass errors appropriately, there is a chance to make this referenceable. This will completely improve the usability and robustness of Node.
The good news is that I talked to a great and talented guy who contributed core code in StrongLoop not long ago. They are explicitly adopting the right way to fix these issues to make future Nodes easier to work by listening to developers’ responses to the platform and planning to find the right way to fix these issues. I'm not sure how the conflict between multiple companies on the simultaneous development of the core part will end, but I hope the developer driver will win.
This doesn't mean it's an attack on individuals, a lot of really talented people are working with or on Node, but this is no longer something I'm interested in. I've had a great time in the Node community and met some really interesting people.
The meaning of the story is that you should not be restricted by your own circle! See what elsewhere and you might enjoy programming again. There are many amazing solutions outside of this, and the mistake I made is that I waited too long to play with them!