Hacker News Reader

Comment by hardwaresofton | Hacker News Reader

Sarcasm is pretty heavy in this article, but I think it's a little overly negative...

He makes a lot of comparisons with Go, but Go was created after Node. Many of the languages he notes as possible replacements for the non-blocking rant are obtuse (I love Haskell, but there's no way it's not obtuse)

[EDIT] - turns out they were made pretty much at the same time 2009... Learned something today, I guess. Felt like Go came after node to me but I guess it didn't

Also, I must be the only one that doesn't really mind callbacks. Maybe it's stockholm syndrome.

I also think node should get kudos for at least seeming different enough to prompt the move from enterprise customers. Any move away from burdened "enterprisey" software is worth praising I think. Not because java is bad/lame by default, but instead because it might prompt other companies to lust after something new that might be better (whether it's python, node, go, or haskell is irrelevant)

View on HN

I picked Go not because it's my dream tool (not having 'map' is kind of sad) but because it's proof that you can have your cake and eat it too. Otherwise, people think that you have to choose between programming sanely and high-performance, but not both.

Yes, I agree -- but Go's got it's own warts. I think they picked up that (err,result) common function signature from node (or they just thought of it themselves, either way).

However, I think once you start trying to manage go routines and all their channels, and all the messages that are flying around, go will start looking less utopian. Of course, a lot of that is subject to code architecture (well architected code will be easy to follow), but I feel like no one's found enough of the dark corners of go yet.

Oh one thing I wanted to mention - Why didn't you include any samples of go routines in your code?

Unless I am misunderstanding go immensely, a statement like "(task3(task2(task1()))" wouldn't actually be asynchronous, you would need to spawn dependent go routines right, and wait on completion on the channels?

> a statement like "(task3(task2(task1()))" wouldn't actually be asynchronous

Correct, because you're passing the result of task1() into task2(), and the result of that to task3(), afaik.

Node hasn't impacted enterprise customers. It has impacted a few high profile silicon valley companies, also Java is not synonymous with enterprise - look at Twitter for example.

I imagine Twitter every day looks online at these node articles and just laughs. That's a team that realizes Java != JEE and that JVM programming is a great thing to be doing.

> Java != Java EE

Not every usage of Java involves Java EE, but that doesn't mean Java EE isn't a really valuable tool for many of us. It has had a bad name in the past, but last version have totally changed that and it's now a very sane tech.

Twitter of course is a highly specialized thing that operates on a Scala that almost by definition not every web site out there will be at. It makes sense to build a lot of their own tools and only use lower level infrastructure as a base.

So the JVM and Java is low enough for them to build their stuff on, but many parts of Java EE may be too high level for their very specific use case.

> I also think node should get kudos for at least seeming different enough to prompt the move from enterprise customers. Any move away from burdened "enterprisey" software is worth praising I think. Not because java is bad/lame by default, but instead because it might prompt other companies to lust after something new that might be better (whether it's python, node, go, or haskell is irrelevant)

The infuriating thing is that it's not the technology that makes the difference, it's the clean slate and getting away from stupid policy. I bet the Paypal people could have written a better version in Java than the Node version, if they weren't required to use the existing internal library and follow existing coding standards and deploy using approved infrastructure and...

> He makes a lot of comparisons with Go, but Go was created after Node.

It's not like Node invented evented concurrency. Something like Twisted predates Node by many years, for instance.

Yes, very true -- Tornado also.

However, if twisted were it's own language, it may end up looking much like node. Twisted is just a library (a damn good one, yes), but if you were to try and transform it into the base framework for an entire ecosystem people might also rail against it from time to time, due to the async-by-default nature.

Also, to me, twisted seems like a much more high-level tool (replicating protocols over simple parallelization/concurrency), than something like gevent

What I'm trying to say is, even in the event that Go was created after NodeJS, the "but Go could learn from Node's mistakes" argument implied here doesn't work. There were enough event-based concurrency systems before the advent of Node, and I'm sure the creators of Go were aware of them.

Also, if you're going to choose a language to compare to, don't choose one where you can't even implement map, filter, etc. I'll take callbacks over having to use loops for everything.

"(I love Haskell, but there's no way it's not obtuse)" I invite you to drink the kool-aid, then you won't think Haskell is obtuse anymore.

Love, Haskell fan-boy

Oh I have partaken of said kool-aid. Maybe I haven't had enough of it.

I've done toy examples, and watched lectures (Erik's C9 lectures are amazing), and I just haven't found anything to write in Haskell.

At this point Haskell is starting to seem like the sketchy guy in the corner at a party. "Oh you think I'm obtuse? just drink a little bit more of this kool-aid here"

Reply on news.ycombinator.com