

Why I Won't Switch To Go from Node.js - hiteshtr
http://notduncansmith.github.io/blog/why-i-wont-switch-to-go

======
couchand
The 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.

~~~
klibertp
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.

------
redbad
"I really like JavaScript" might be a compelling personal narrative, but it
makes a pretty uninteresting submission to Hacker News :(

------
DigitalSea
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.

~~~
billrobertson42
Everything is a nail.

------
zachorr
The second half reads a lot like "I can write everything in Javascript so why
would I need another language"

------
mathrawka
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.

~~~
lugg
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..

~~~
notduncansmith
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.

------
samnardoni
Honest question. Why do people write posts like these?

~~~
notduncansmith
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).

------
sseveran
javascript is not perfectly readable. For all the same reasons that other
languages with poorly integrated async features are. Ahem C#, etc...

~~~
klibertp
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.

------
anonfunction
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.

------
NateDad
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.

~~~
notduncansmith
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?

------
noname123
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.

