The fourth is simply confusing. If you're not sharing code between the client and the server, you're missing something big (though he does say it might just be the projects he's on).
Modern business software is faced with two competing forces: bulletproof integrity and responsive interaction. Making your application bulletproof requires that business rules are evaluated on the server, but making it responsive requires those same rules to be evaluated on the client. Think about credit card validation: it's infuriating to wait for a round-trip to the server just to discover you've mistyped your number, but that doesn't mean the server can simply trust the client.
At the moment Node.js + browser JavaScript provides the only solution I know which allows you to write your business rules once and only once. Anything else is crufty.
Then there are Seaside inspired frameworks, which generate client JS for the user. There is at least one framework like this for Python and I'm sure there are other for other languages.
JS remains the most well known and supported solution, though.
As for the last paragraph in the article, Go in my opinion is already pretty popular. It might not be mainstream like Node.js, but it has a pretty loyal following. As always, the language isn't going to determine how successful something is.
Look at Facebook, the worlds most popular website was built in PHP. Building it in a language like Ruby or Python wouldn't have made a difference to how successful it is.
Use whatever language you feel comfortable using, don't just use a language because everyone else is frothing at the mouth about it. I can't stress this enough, use whatever language you feel comfortable using and know the best.
And this is coming from someone who has used Node.js for multiple startups in the past 2.5 years.
To be honest, I'm not sure what that point was about I still feel a context switch going from server side node js in my apis and apps to client side angular / backbone. They are just different beasts.
Unless he does a lot of the node in the browser thing?
I dont know how you would avoid the context switch. There is, I guess, a chance the author is seeing that as an obvious but actually nonissue stemming from his other complaint (which I agree with) the tool chain.
The npm and friends tool chain is absolutely bliss to work with from a web developers point of view. While it is all doable with other more traditional build tools like ant or make there is something awesome about every part of your stack being in a single scripting language.
While right tool for the right job is still valid its amazing what has been accomplished in the ecosystem against all odds from javascripts initial debut..
> I believe the author meant between frameworks, patterns and compilation styles. To a lesser extent syntax (that's probably the most visible but least painful).
Spot on.
> To be honest, I'm not sure what that point was about I still feel a context switch going from server side node js in my apis and apps to client side angular / backbone.
That's not a point I was trying to make, perhaps I wasn't clear. The context-switching I was talking about wanting to avoid was Go (or some other language) and Javascript, and the fact that my tooling is JS means I'm gonna be switching all the more often. I don't really have a problem switching between client and server-side JS.
In fact, context-switching isn't that hard for me, but being able to avoid it is a nice bonus that comes with what happens to be my favorite stack.
There are two schools of thought here. One says that concurrent programming is actually an optimization and that the language and frameworks should make it as transparent as possible. The other says that concurrent programming is fundamentally different from sequential programming and it should look differently, too.
Out of curiosity, which language you think gets concurrency right? My personal favourites are Erlang, Io and Clojure, but even there concurrency is not completely transparent.
