So?<p>I don't think TJ wrote his post just for the sake of complaining or comparing Node with Go. He had a decision, and had to tell the community he was leaving because, you know, a lot of people uses his modules. I rely on a couple of his modules and I liked that he took some time to explain why he'll not be working on them anymore.<p>This post is no more interesting than blogging "I'll keep drinking my morning coffee.. Just as always."
> Hiring for Go — I wouldn’t even know where to start.<p>Ridiculously simple: Set out to hire a good programmer (as opposed to "a Go programmer"), and make it clear in the job description that they're expected to spend the first 6 months learning Go on the job.<p>You end up demonstrating to employees that you're willing to give them something useful, gain loyalty; AND end up with someone you can be confident is able to learn whatever else your company might need in the future, and writes better code by way of having a focus on programming knowledge, not language knowledge.
Node is not going anywhere. It may not be cool anymore, but like the old cool kids (Rails, Java, Perl), it has achieved critical mass, and still has some killer features.<p>Node makes SOA (service oriented architecture) a lot easier. SOA is what all the cool kids are moving to, and is one of the reasons why it's so easy for big companies with lots of legacy code to switch to Go. Once your code is appropriately partitioned into services, it's easy to write a single service in Go, and go is a nice language for writing services.<p>That being said, Node is particularly well suited for <i>consuming</i> services. You'll necessarily have lots of client code written to consume and use these services from your webapp. So whenever you write a batch job or notification system or anything else that is primarily server side consumption of services or glue between services, node.js is a natural fit.<p>The other natural advantage of Node is that your business logic can run on both the server and the client. Your standard client-side web app (angular, backbone, ember etc.) has the bulk of the business logic in the client-side models. On the server side, the corresponding models are mostly just shims to the database, but they will also contain some business logic. If your code is written in Node.js, you just instantiate the client side model to be access the business logic.<p>The other killer feature for node.js has already been mentioned: combining both server and client side rendering with <a href="https://github.com/rendrjs/rendr" rel="nofollow">https://github.com/rendrjs/rendr</a> or <a href="https://github.com/wvl/highbrow" rel="nofollow">https://github.com/wvl/highbrow</a>.
I dont find this blogpost very interesting.
The point of TJ's post was that concurrency in Nodejs was hard compared to Go,so was error management.It's not about one using Go or NodeJS,more about the fact that it is harder to build concurrent servers that dont crash on error in NodeJS than in Go.<p>Furthermore I personally dont rely on anything to OP wrote, so wether he stays or leaves nodejs doesnt matter.
> With Node you can literally share your code between the front and back of a system.<p>I think sharing code is dangerous as it tightens component coupling and makes architecture less flexible and more complex.<p>An average web project nowadays seems to be a back with many fronts: end-user website, admin interface, iOS app, Android app, Windows app… Making all fronts equal in their separation IMO keeps the architecture more predictable and easier to understand. Like DRY but with design decisions instead of lines of code.<p>Also, I don't see how you can be flexible without making API the only point of contact for your back(s). That way you don't lock yourself in and can rewrite any component with another framework or language, once requirements change sufficiently. I imagine it's much harder to do if you have everything in one Node project.
"With Node you can literally share your code between the front and back of a system."<p>Having to deal with a poorly-designed legacy weakly-typed scripting language not just on client (where you have no choice) but on server as well? Why be masochistic?
> We still have a rough future ahead of us. But I bet on JavaScript a long time ago, and alas, like English — it’s everywhere.<p>The "alas" in this quote is sad. Sad to be using tools you hate.
Is there really any practical examples of sharing code between back-end and front-end? I only see really specific use-cases, such as sharing the logic of a game between the client and the server, since most of the time the back-end <i>serves</i> the content and the front-end <i>displays</i> it.
> Hiring for Go — I wouldn’t even know where to start<p>Let's go with metaphors. Programming languages and driving a car are similar things. When you change your car from Toyota to Audi, you don't learn everything from scratch. You just spend sometime to get used to the car (wheeling, brakes etc) and then you're all set. Programming languages are similar. When you switch from language A to language B, you don't learn programming from scratch. So, when you want to hire someone to code in Go, you just hire a developer and tell them they're going to code in Go. After getting used with Go, they would be all set.