Why I Won't Switch To Go from Node.js
notduncansmith.github.ioThe first three complaints addressed are far too common for how ridiculous and unfounded they are, and it's nice to see them addressed head-on.
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.
What about Clojure and ClojureScript? There's also Opa. And Ur/Web, which reached a stable state, based on a growing user base of three use cases ;)
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.
"I really like JavaScript" might be a compelling personal narrative, but it makes a pretty uninteresting submission to Hacker News :(
As a web developer the number #1 argument I use against those who say, why not a language like Go or Ruby is simple: I use Javascript on the front-end, why not the backend as well? Being able to handle everything from authentication to view rendering using the one language is a powerful thing.
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.
Everything is a nail.
The second half reads a lot like "I can write everything in Javascript so why would I need another language"
Honestly, does a context switch exist for switching between frontend JS and backend Go? I am not trying to tout my own horn here, but I don't have problems with that.
And this is coming from someone who has used Node.js for multiple startups in the past 2.5 years.
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).
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..
Author here.
> 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.
Honest question. Why do people write posts like these?
Author here. I originally wrote this as a comment in a Reddit thread, and decided to put it on my blog because I felt like having more than one post (might actually start blogging regularly again).
javascript is not perfectly readable. For all the same reasons that other languages with poorly integrated async features are. Ahem C#, etc...
From the article: "Promises, 'nuff said."
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.
Different needs call for different stacks. We've moved a lot of our systems to node.js for reasons outlined in this article but at the same time Go makes more sense for mission critical infrastructure at scale where performance matters.
I'm curious as to what toolchain he thinks he needs? I write Go all day. I don't have a "toolchain" unless you count version control and go build/go get.
As a full-stack web developer, I rely heavily on gulp and Bower (as mentioned in the article), as well as a few other small utilities. I know I wouldn't have to give those up by switching to Go, but at that point, if every dev on the project already needs to have Node installed, why not just use Node?
I love Java and I use GWT so I avoid context switching to Javascript and plus it came out of Google like Go, so it's pretty rad.