TJ Holowaychuk leaves NodeJS for Go

TJ Holowaychuk built out some of the most important nmp modules for NodeJS, but now he is leaving for Go.

Go versus Node

If you’re doing distributed work then you’ll find Go’s expressive concurrency primitives very helpful. We could achieve similar things in Node with generators, but in my opinion generators will only ever get us half way there. Without separate stacks error handling & reporting will be mediocre at best. I also don’t want to wait 3 years for the community to defragment, when we have solutions that work now, and work well.

Error-handling in Go is superior in my opinion. Node is great in the sense that you have to think about every error, and decide what to do. Node fails however because:

you may get duplicate callbacks

you may not get a callback at all (lost in limbo)

you may get out-of-band errors

emitters may get multiple “error” events

missing “error” events sends everything to hell

often unsure what requires “error” handlers

“error” handlers are very verbose

callbacks suck

In Go when my code is done, it’s done, you can’t get re-execute the statement. This is not true in Node, you could think a routine is completely finished, until a library accidentally invokes a callback multiple times, or doesn’t properly clear handlers, and cause code to re-execute. This is incredibly difficult to reason about in live production code, why bother? Other languages don’t make you go through this pain.

…..Future Node

I still hope Node does well, lots of people have heavily invested in it, and it does have potential. I think Joyent and team need to focus on usability — performance means nothing if your application is frail, difficult to debug, refactor and develop.

The fact that 4-5 years in we still have vague errors such as “Error: getaddrinfo EADDRINFO” is telling of where the priorities are at. Understandably it’s easy to miss things like that when you’re so focused on building out the core of a system, but I think users have expressed this sort of thing over and over, and we’re not seeing results. We usually get poor responses advocating that what we have is perfect, when in practice it’s anything but.

Streams are broken, callbacks are not great to work with, errors are vague, tooling is not great, community convention is sort of there, but lacking compared to Go. That being said there are certain tasks which I would probably still use Node for, building web sites, maybe the odd API or prototype. If Node can fix some of its fundamental problems then it has good chance at remaining relevant, but the performance over usability argument doesn’t fly when another solution is both more performant and more user-friendly.

If the Node community decides to embrace generators and can implement them to the very core of node, to propagate errors properly then there’s a chance that it would be comparable in that area. This would drastically improve Node’s usability and robustness.