
Farewell Node.js - beltex
https://medium.com/code-adventures/4ba9e7f3e52b
======
nadaviv
I've been using his libraries since I started out with node, and there isn't a
single project that I'm working on today that doesn't have at least 2 or 3 of
his libraries as dependencies.

He has contributed a lot to the nodejs ecosystem (around 600 packages! [1]),
and it saddens me to see him go. The Go guys should be very excited to have
him on board!

[1]
[https://www.npmjs.org/~tjholowaychuk](https://www.npmjs.org/~tjholowaychuk)

~~~
tdumitrescu
Yeah, it's absolutely crazy how much that dude put out there over the last
years, totally impossible to do JS web dev work without using at least a few
of his libraries like Express, Jade, Mocha, Co. and then one day it's like
"alright done with that." If I could be even 1/2 that productive...

~~~
Jonovono
Maybe this will make you feel better :p [http://www.quora.com/TJ-
Holowaychuk-1/How-is-TJ-Holowaychuk-...](http://www.quora.com/TJ-
Holowaychuk-1/How-is-TJ-Holowaychuk-so-insanely-productive). Speculation he is
actually a Pen name.

~~~
smoe
Or maybe Google is behind this. They created an icon within an emerging
community where all the cool kids go, in the hope they will follow once he
publicly converts to golangism

~~~
ansimionescu
Yep, that's exactly the kind of thing Googlers spend their time on. /s

------
spasquali
Go is a great language, and I'm looking forward to see what TJ does with it.

He's bored, and moving on. That's it. He's trying to justify what must be a
painful decision by making a bunch of abstract claims about how Node isn't a
production-ready language. The elephant in the room: how is it that TJ was
able to build so many things, over so many years, that are used -- in
production -- in so many places, in a language that is "difficult to debug,
refactor and develop."? Is he a masochist?

I think he's hit a personal wall. It seems he has a beef with the way the core
is being developed. And Go is indeed fun, and exciting. This isn't surprising.
People get burned out.

~~~
tjholowaychuk
Not at all, my claims of node not being production ready are 100% legit, and
based on real-world applications. The thing that is enjoyable Go is that it IS
production ready, if I could say the same about node I would still be using
it.

Like I mentioned in my post, I decided to rewrite an application that I had
been working on for the last month with Go. I decided that if I could do it in
a week, and if it went well that I would ditch node. It went even better than
I had hoped, and is much less frail. Node has many design flaws down to its
very roots.

I'm not saying those are due to terrible engineering or anything, but they
were choices that were made and Node is stuck with them for the foreseeable
future until breaking changes can be made. That is if the core people can
admit that it's not great to work with :)

I think the main problem is often people working on the depths of some system
forget to really use it. It's so easy to get caught up in the details but if
you don't step back and use your own product you're screwed!

~~~
spasquali
Your experiences moving a Node app to Go would make for a great study. You're
extremely influential, and it may be better to give concrete examples of how
Node can be improved.

I wonder about this "enjoyable" criteria. I'm assuming you're not claiming to
be the only person who has written large Node systems, or that nobody has ever
written larger, more highly trafficked, more complex Node applications than
you have. So the point seems to be: for you, Go is more fun than Node at
scale. As a well known contributor, that's a valuable perspective. I'd like to
know more about how your personal experience could be translated into general
truths all developers could understand.

It seems to me that Node is used rather extensively by the core contributors.
I don't get the impression that they have never actually used the product,
based on their repos etc.

Thanks for all your work. I'm sure the Go community will similarly benefit
from your efforts.

~~~
tjholowaychuk
I think the issue is we've been slowly accepting that the node is the right
way to do things. Five years of working with someone will do that to you. If
you follow me on twitter you probably see me complain about it in various ways
all the time, it's not that I'm bored with it, node's problems are real and
some people just seem to ignore them, or maybe just deal with them because
they know backwards compat can't be broken immediately. It has always bothered
me that people would advocate such broken systems (streams etc) when real-
world alternatives were better even before now, even C has a much better
example of what a stream should be.

I'm definitely not the only one writing large systems, but I think the
tolerance level varies per developer. Also plenty of people make a living/name
from Node, of course they're more likely to praise it than to be honest about
its faults, I'm definitely a minority in that respect. Having broken concepts
is one thing, but resisting change when they're obviously broken is not a good
thing. Many of these same people make money from consultation, where it's
advantageous to have a broken system. I'm not trying to screw them over but
someone has to be honest.

It took years to get .addHeader() in because no one in core believed in a
progressive API, they didn't use node in real-world applications to see the
need. This still happens all the time, take npm-www for example, Isaac is a
rad guy but him aswell as most other "core" community members advocated
building tiny little things and stitching them all together, and just recently
realized that in practice this doesn't scale, thus ended up going with Hapi.
This lack of insight is all over Node as a community.

It's hard to describe well, but I hope people will try Go (or similar
alternative), you'll really see how much more robust it is. If node fixed its
conceptually flawed event system, rewrote http so it wasn't awful to work
with, and fixed streams then we'd have a pretty good system to work with. It's
_very_ easy to pass off problems with node as problems you'd have with any
platform, but that's unfortunately just not reality.

~~~
spasquali
I have to push back against some of your statements.

“I think the issue is we've been slowly accepting that the node is the right
way to do things. Five years of working with someone will do that to you.”

Who is “we” and what is the evidence for the conclusion? How is it true that
1) In 5 years all coworkers think exactly the same way; and 2) Some purported
truth about human behavior relates to the general usage of a programming
language within an opinionated and free community? This seems like some random
statement without any (provable) basis in reality.

“It has always bothered me that people would advocate such broken systems
(streams etc) when real-world alternatives were better even before now”

You’ve started companies, joined companies, and encouraged Node technology at
companies. You’ve advocated for others to use the systems that you’ve built.
These companies have investors and other who trust your judgement. Why did you
advocate a broken system, for so many years? Or did you come to this
conclusion just a few weeks ago? What led you to that conclusion?

“I'm definitely not the only one writing large systems, but I think the
tolerance level varies per developer.”

I’m not sure that anyone I know who builds massive enterprise systems ignores
the “bad parts” of a system. None of them are tolerant of bad ideas. You
really can’t be if you’re a professional with responsibilities to your team,
your company, and shareholders. To suggest that Node is popular because Node
developers are more tolerant of bad systems is, well, a weak theory that I
think doesn’t stand up to reason.

“Also plenty of people make a living/name from Node, of course they're more
likely to praise it than to be honest about its faults, I'm definitely a
minority in that respect…Many of these same people make money from
consultation, where it's advantageous to have a broken system. I'm not trying
to screw them over but someone has to be honest.”

It’s not controversial to point out that you have advocated for (praised) a
system that you believed was full of faults, for years, for great profit, in
many senses. So you’re indeed a minority, but not in the way that you think
you are. All of this sounds, to me, a little screwy.

“This lack of insight is all over Node as a community.”

I’ve re-read the paragraph preceding the above conclusion, but have failed to
find a cogent argument. Something about #addHeader, and Isaacs is rad, and
something else about “building tiny little things and stitching them all
together” is a fools errand — this seems to be an “insight”. From Eric
Raymond’s Unix rules: “Rule of Composition: Developers should write programs
that can communicate easily with other programs. This rule aims to allow
developers to break down projects into small, simple programs rather than
overly complex monolithic programs.”. Unix has scaled pretty nicely.

Now, you may be right. Also, Raymond might be right. Also, the entirety of the
thousands of developers who build serious, professional software by following
this credo might be right. Or some may be wrong. Or all may be wrong. But the
point is… I still don’t see you producing an irrefutable argument, especially
since you want to conclude that Node is fundamentally broken, isn’t “ready for
prime time”, and so forth. I mean, you’re the most prolific contributor to the
Node project, and you have advocated on several occasions for exactly this
sort of methodology. It’s confusing.

“It's very easy to pass off problems with node as problems you'd have with any
platform, but that's unfortunately just not reality.”

Not sure what you’re saying here. I could link a few hundred articles covering
every language, including Go, that say the same thing you’re saying about Node
— but I don’t know what they’re getting at either. No programming language
solves all problems, and is easier than all others, and has no mistakes in it,
and etc. Do you dispute that? If not…why exactly is the fact that Node has
some problems, and some imperfections, and some mistakes, a reason to dismiss
it outright? From your earlier post: “my claims of node not being production
ready are 100% legit, and based on real-world applications.”. 100% legit?
That’s pretty legit! But howzit legit?

I’ve been a little hard here, but I feel I had to be. Again, you’ve been a
great contributor to the project, and I hope you do some more great things.

------
olegp
Couldn't agree more with this post. Node has always had a problem with
favoring performance over robustness, coupled with an overly zealous,
polarized community that exists in a bubble. This resulted in synchronous
libraries like fibers being shot down without proper consideration.

At StartHQ ([https://starthq.com](https://starthq.com)) we've abstracted away
all async code with a sync layer using fibers and that has served us well over
the past year, but I can totally see how trying to mix the two would have been
a recipe for disaster.

Here is a video of a talk we gave on this:
[http://www.youtube.com/watch?v=pmyDJnEza6A](http://www.youtube.com/watch?v=pmyDJnEza6A)
and here are the slides: [http://www.slideshare.net/olegp/start-hq-server-
side](http://www.slideshare.net/olegp/start-hq-server-side)

~~~
bhauer
> _Node has always had a problem with favoring performance over robustness_

I don't disagree with the gist of what you're saying, and I think you're
correct. But the premise of Node being high-performance is perhaps more
reputation than actual fact. I think it gets that reputation because it is
higher-performance than some more popular options, but in the big scheme of
things, it's but a medium-performance platform [1].

[1]
[http://www.techempower.com/benchmarks/#section=data-r9&hw=i7...](http://www.techempower.com/benchmarks/#section=data-r9&hw=i7&test=json)

~~~
olegp
Agreed. I benchmarked Node/V8 vs. the JVM and while Node has lower memory
usage, Java is as performant while being more reliable, with less variance in
HTTP response times, due to the better garbage collector.

[http://www.slideshare.net/olegp/server-side-javascript-
going...](http://www.slideshare.net/olegp/server-side-javascript-going-all-
the-way) \- there are some graphs from slide 46 onwards.

------
bipin-nag
He is one of the topmost contributors to the node.js ecosystem if not the
most. He has given a plenty of good libraries. Besides the reasons he gave to
leave node.js, I feel that he was under-appreciated and over-worked many
times. With components he tried to create a toolchain, wrote express and koa
for server, jade for templating, mocha for debugging etc.

He tried to do a lot many things single-handedly. Which is why he needs a lot
of maintainers. I don't blame him for overloading and stressing out. That is
the way how it goes in node.js. Working in node.js is like battling a multi-
headed beast. The core javascript keeps evolving, node.js isn't even in
version 1.0, API changes a lot. There are lot of blanks to fill and too much
time goes into boilerplate stuff and managing existing code.

It is just not rewarding and fulfilling to contribute to node.js. On top of
that he faced a lot of friction from other contributors. He had some really
difficult times, like express-connect conflict, bower-components conflict.
Having handled conflicts too many, some people also consider him as being rude
and too self-centered. Besides he is young and is probably one of the first
things he has done he is serious about.

Many times before I asked to myself how does this guy do it. In a community
where to contribute even a little one has to put in a lot of effort, his
contributions are gigantic. I hope he continues to work, although not at too
many projects . His experiences will definitely be handy.

~~~
enome
On top of that I remember the first nodeup podcasts and on twitter some key
member from the community would bitch about express all the time. Ranging from
express is bloated to middleware is a shitty abstraction to you don't need a
framework in Node.js. It was really weird because express was (is?) one of the
most used framework in the Node.js community and here you have people that
other people follow and listen to tell you that it's crap.

~~~
tjholowaychuk
Haha yup, I wont lie I have been an asshole at times, mostly because you sort
of have to defend yourself when you're surrounded by people who attack your
work, but after a while I realized it wasn't worth it so I just sort of
detached (no longer on IRC, the mailing list etc). Defending your work isn't
worth becoming rude yourself. Communities always form cliques that's just how
it is.

The core node community was very unreceptive to change since the very
beginning, to be honest Ryan and Isaac were some of the few humble people in
the bunch. I've always been a "threat" to "the node way" of doing things,
whatever that means. The elitism gets a little old.

------
mambodog
One (very arbitrary) metric of TJ's position in the node community:
[https://github.com/substack/npmtop](https://github.com/substack/npmtop)

running it today tells us that he's still number one:

    
    
      rank   percent   packages   author
      ----   -------   --------   ------
         1    0.60 %      548     tjholowaychuk
         2    0.44 %      401     substack
         3    0.41 %      379     jongleberry
         4    0.40 %      367     dominictarr
         5    0.37 %      341     jonschlinkert
         6    0.37 %      337     sindresorhus
         7    0.36 %      331     juliangruber
         8    0.34 %      317     mikolalysenko
         9    0.31 %      289     raynos
        10    0.28 %      260     mathias
        11    0.28 %      257     hughsk
        12    0.28 %      255     forbeslindesay
        13    0.26 %      239     tootallnate
        14    0.23 %      216     clewfirst
        15    0.23 %      208     azer

------
kolev
Reminds me of Zed Shaw leaving Ruby... Honestly, Node.js has done a lot, but,
come on, it's still JavaScript in the core. The selling point that you can run
the same code both on the client and on the server doesn't really hold up to
the reality check. I'm not so excited about Go, I honestly find Rust better.
Dart also seems promising - especially having dart2js and Google backing it,
too, but it doesn't seem to be picking hype as fast as Ruby and then Node.js
did. To me, having a powerful package manager seems to be the common theme and
they key to success. I still can't believe with all the ego, Python is still
relying on a joke like pip. Although I agree it would be challenging, I think
the world will be a better place if there's a cross-language package manager,
with language-specific plugins. At the end of the day, maybe 75% of the logic
is shared and is around downloading things, installing symlinks, checking
dependencies, and so on. Package that with a cross-language
pyenv/rbenv/nodeenv, etc., and you would have a killer.

~~~
sriku
> I'm not so excited about Go, I honestly find Rust better.

Same here, but Go has productive libraries that can help you hit the ground
running. Just with the packaged standard libraries, you can do things like
have a useful webserver going. I prefer Rust though and might stick with JS
until I exhaust it .. or until Rust matures enough to put into production and
then jump fully on to Rust. Rust compiles to llvm-bitcode, unlike Go, so
that's a win for me.

edit: I stand corrected - [https://github.com/go-
llvm/llgo](https://github.com/go-llvm/llgo)

~~~
kolev
I've seen that, but just noticed that the project is led by a Canonical
developer, which I find interesting.

------
aroman
This is as significant a loss for the Node community as the loss of _why was
to the Ruby community. Maybe even more so.

------
anonfunction
For those that don't know TJ Holowaychuk, he's the guy behind express and
commander.js (and a lot more) which are two of the most popular node.js
packages.

~~~
waitingkuo
My favorites are jade and stylus, which are also hot!

~~~
couchand
Mocha is the only JavaScript testing framework that works on the server and
the browser and is simply beautiful. Superagent is likewise a simple and
obvious API that works identically in both environments.

TJ has done quite a bit to advance the state of the art in JavaScript
development, it will be interesting to see what he does with Go.

~~~
notduncansmith
Jasmine works on the server and the browser.
[http://jasmine.github.io/1.3/introduction.html](http://jasmine.github.io/1.3/introduction.html)

------
pjmlp
Another I left <dynamic language> for <strong typed language> when faced with
performance/large codebase/tooling issues post.

Additionally we are now past Rails wave, Node.js wave and into Go wave.

~~~
adamors
> Additionally we are now past Rails wave, Node.js wave and into Go wave.

And the narrative is similar as well: starting a new project with the shiny
new thing is cool but maintaining it is boring and awful and to quote the OP
"I need maintainers!".

Part of the problem is the language of course. Maintaining even a medium sized
codebase written in a dynamic language is a challenge. But the other part is
the mantra that "coding is easy" and "everyone should do it". And now there's
an entire generation of developers whose idea of software development is
"writing an app in Node in a weekend". Which of course doesn't require years
of maintenance, complicated tooling or even adherence to common best practice.

------
deepakkapoor
[http://www.quora.com/TJ-Holowaychuk-1/How-is-TJ-
Holowaychuk-...](http://www.quora.com/TJ-Holowaychuk-1/How-is-TJ-Holowaychuk-
so-insanely-productive)

~~~
mburst
That was a pretty cool read. The theory definitely makes sense

~~~
deepakkapoor
If I was in Canada then I would go to Vision Media's office just to meet or
rather verify the assertion. It would be a win win in either case.

~~~
gkoberger
visionmedia is his screen name, not the company where he works. He worked at a
company called LearnBoost ([https://www.learnboost.com/blog/welcome-aaron-and-
tj/](https://www.learnboost.com/blog/welcome-aaron-and-tj/)), which I can only
assume is some sort of mob-style front for laundering JavaScript code. (Look
at their employee list and GitHub repo)

Now, I've heard he works for Segement.io (in SOMA), but does so remotely.

------
ericff
I really want to know why he chose golang instead of X or Y (Elixir, Erlang,
Scala, ClojureScript).

Have he said anything about that in other blog? Or anyone of you have sent him
email about that?

I use node.js (0.3 to now) quite a long time. I also feel the smell of
node.js, forever, express and socket.io. Recently, I am considering switch to
Elixir. But I am afraid now.

From day one in node.js to now, we know that node.js is not prefect and not
fastest. But it is so popular and some many great guys, like TJ, contributed
many packages into the eco-system.

Go is not prefect too. But once it get more popular and more packages. Better
vm like Erlang or X or Y may be just ignored by devs.

~~~
ericff
TJ replied my email, he said:

Hey! Mostly Go because it suits what I pictures as my ideal language pretty
well. It's simple, C-like, great concurrency primitives, great standard
library. I've had bad experienced with anything JVM so I'd stay away from
Clojure, and Erlang has some legacy baggage but I'd still like to give it a
better look some day! Elixir is cool but too Ruby for me

------
throwaway41597
> We could achieve similar things in Node with generators, but in my opinion
> generators will only ever get us half way there

I wish more people realized this. Generators seem to be billed (ironically by
TJ amongst others with his Koa project) as the solution to callback hell but,
having tried Go, I got the same felling that actors are much easier to reason
about and debug (although concurrency is still hard).

On the client side, web workers allow parallelism but the API is inconvenient
to use: you need to have a file for each web worker whereas Go's `go` routines
are akin to a function call. In addition to this standardized conundrum, you
have browsers discrepancies with the APIs available inside a worker varying
between vendors [1].

On node, you have the cluster API, which allows managing several processes so
it's even further from light threads. On the bright side, most (all?) APIs
have both a sync and async version.

As a result, there's nothing you can use for multithreading in a module
without coordinating with the whole project. I think JavaScript needs language
support for light threads, not APIs for multiprocessing.

[1]: [https://developer.mozilla.org/en-
US/docs/Web/API/Worker/Func...](https://developer.mozilla.org/en-
US/docs/Web/API/Worker/Functions_and_classes_available_to_workers)

~~~
aikah
Nodejs could have workers,it's not really a javascript.Node maintainers just
didnt implement that stuff.

I personnally dont like generators for concurrency.It's the wrong solution to
the problem.For now I stick with promises,and I hope JS gets async/await
keywords quickly.

~~~
throwaway41597
> Nodejs could have workers

Agreed, but what I meant is that the API (running a file in a worker) is
inconvenient, first because there is no closure. Go allows the go routine to
read variables in scope and has a race detector to tell you when your accesses
are unsafe. There's also the issue of managing workers: is a web worker an OS
thread or a light thread [1]? how many can you spawn? which worker should you
send work to? These problems are solved by Go. I think it would be very hard
to obtain the same reliably and performance with today's web workers. Other
languages solve this with a language construct, not an API to run another
file.

> I hope JS gets async/await keywords quickly

It would be a step up. But most of the time you want to express a linear list
of tasks. Javascript should support this by having a synchronous variant of
its APIs and having light threads.

My hope is more that some language having such features will compile to asm.js

[1]: it's either a thread, a process or an "equivalent construct"
[http://dev.w3.org/html5/workers/#processing-
model](http://dev.w3.org/html5/workers/#processing-model)

------
sriku
Server side dev folks have always enjoyed choice of language/system when it
comes to building. You can simply choose the thing that works best for you,
that you're more comfortable with, is most performant for your app, etc. On
the client side, we have ... javascript. While JS is pretty fast these days
everywhere and we can cross compile with emscripten and all, I'm almost
tempted to say that the true web standard for programmability on both client-
side and server side ought to be some kind of a byte-code .. a concept the
Java guys had right way back.

If you consider that we have PNaCl compiling llvm-bitcode to native within the
browser, Emscripten cross compiling llvm-bitcode to asm.js (which Firefox's
engine converts to native), Safari's engine compiling js itself to llvm-
bitcode, I'm thinking why not make llvm-bitcode an open web standard? That
way, any language that compiles to llvm-bitcode would be equally usable on the
server side and on the client side.

The biggest potential downside to that would probably be educational. I learn
a lot by looking at source code and the web was always open in that way,
though with minified JS these days that's not so possible any more. However,
it might make it easier to distribute source code in any language, since a
module can then compile and run such code right in the browser.

edit: These thoughts came up when I was thinking about how TJ won't be able to
take his work with him as he moves to Go. Well, I suppose he wants to do new
kind of work for which Go is better suited, but is then all of the prior work
just a brief view along the journey?

------
alecco
Hilarious/sad how this has 210 points in 9hrs and it's 2nd page.

------
shadowmint
I was suprised to see the comment that tooling for Node wasn't great; I
thought the node tooling (npm, gulp, grunt, etc.) was significantly superior
to the primitive (ie. relatively low level) tooling go provides.

...but I see that's a very specific comment:

    
    
        the tooling Go provides for profiling and debugging is great...
    

Ah, that makes more sense. This is definitely an area where node applications
are really troublesome to work with (live debugging).

~~~
notduncansmith
I was surprised as well, until I saw that. The npm/gulp/bower/less/node stack
is pretty awesome for full-stack web development. All in one language, all
open source, easy-breezy package management. If Go had that sort of complete
stack (and for God's sake a package manager to rival npm), I'd probably be
pushing Go as hard as possible at work.

As it stands, there's way too much friction and it would cost a LOT of money
to invest in Go. There's a good chance that the ecosystem may not evolve to
Node's level for years - and worst of all, if you want to build competitive
web apps, _you still can 't avoid Javascript_.

------
cnp
Always, always loved his attitude towards stuff. Seriously. And when its time
to go, its time! Good luck TJ and thank you so much for everything.

------
novaleaf
I guess I'm a little late to the party, but can someone comment on the issues
TJ mentions? Specifically, I've never seen problems with callbacks being
double-executed. Under what conditions would it occur?

------
_greim_
This post really resonates with me. I'm not as prolific and don't have the
ability to breeze into a new language on a whim, but seeing so many other
languages gaining momentum nowadays really makes me feel restless. All the
best of luck to him, and I certainly hope I'm not stuck in the same rut the
next ten years.

------
nemothekid
We're a pretty heavy Go production shop, but today I decided that we would
move our dumb rails codebase (we were really only using the asset pipeline) to
nodejs+mincer (mainly to get rid ruby).

Hope the departure of an incredibly js developer doesn't impact the community
too badly.

------
disputin
Moving from Node to Go? From a platform to a language? And what's with the one
size fits all - moving? And if moving a project from Node to Go, was Node the
correct choice initially, for that project - more one size fits all?

------
derengel
I guess the important lesson from him here (which he mentions) is to get out
of your comfort zone and learn new stuff, as to be able to tackle problems
with a wider view of things and solve them with the most adequate tools.

------
archgeek
Maybe Golang is great for developing frameworks, but as someone who build
websites i prefer Node because Go's typing makes development slower and more
expensive.

~~~
ragesh
Dynamic typing was very cool when I started out with Node, too. It lets you
get things wired up very quickly and come up with a very functional app with
almost no friction. But in my experience, once the app reaches a point where I
no longer remember every single line of code that was written in it, I start
to miss what a type system could tell you.

Hmm, do I pass a string in the first parameter, or was it the second? What
does that funciton return? Am I really getting a number in this parameter? Of
course, you can get around that confusion by adding more unit tests and
parameter validation but with strong typing I'd get all that for free.

~~~
notduncansmith
While I don't disagree with you that that's inconvenient and totally solved by
strongly typed languages (I love having my arguments filled in when writing a
function call in Go), this usually isn't a big deal in _literally any_ of the
production Node systems I've worked on (some of which are particularly
complex).

At my shop, we emphasize making obvious (if somewhat verbose at times) names
for functions, so that it's pretty easy to intuit what arguments it takes.
Also a naked function (e.g. "foo(bar)") will always be defined in the same
(<100 line) file, so it's not hard to find it, or in a module (which is a
Cmd+P away).

All this to say, while I agree with you that strong type systems mostly
eliminate this pain, it's not exactly "painful" in Javascript either.

~~~
ragesh
I totally see your point. I think what's tripping me up is that I'm new to
node/JavaScript and coming from a strongly typed world, I'm still writing my
apps with that framework in mind. Working with dynamically typed code requires
you to think about your application differently and I'm just starting to
understand the patterns.

~~~
notduncansmith
I understand that. There certainly is a learning curve, and I don't pretend
that all the Node stuff I've written since day 0 has been awesome - I've
churned out my fair share of nasty, unmaintainable garbage because I abused
the freedom that Javascript gave me.

One tip: rubber ducking is really valuable. If it takes more than ~30 seconds
to explain whats going on in ~10 lines of code, then you probably should do
some abstracting.

------
davidw
Pity he didn't have a look at Erlang. It's not likely to be the "next big
thing", but it's really good at what it does.

~~~
brickcap
He did give erlang a try and tweeted about it 4 years back. I think judging
from some of this other comments on disqus(I can't find them at the moment) he
did not like it very much.

[https://twitter.com/tjholowaychuk/status/16988926506](https://twitter.com/tjholowaychuk/status/16988926506)

------
wesbos
TJ did a lot for this community, sad to see him go but really happy that he
did contributed so many library that we will continue to learn.

------
bsiddiqui
convinced he represents an org of devs [http://www.quora.com/TJ-
Holowaychuk-1/How-is-TJ-Holowaychuk-...](http://www.quora.com/TJ-
Holowaychuk-1/How-is-TJ-Holowaychuk-so-insanely-productive)

------
mike--
Wait a couple of years and author finds erlang or scala...

~~~
th0br0
... or Rust, given that the language should have matured by then. But other
than that, I'm also waiting for people to eventually discard Go and move on to
one of those languages...

------
develop7
despite Go isn't actually an answer, good for him anyway

------
ilaksh
I wonder if people are picking Go over Nimrod mainly because Go is more
popular.

~~~
woah
It's certainly one of the best reasons to pick a language. Popular = Ecosystem
.

