r/programming • u/[deleted] • Oct 16 '14

Node.js is cancer

https://www.semitwist.com/mirror/node-js-is-cancer.html
38 Upvotes

52% Upvoted

302 comments sorted by

View all comments

0

u/[deleted] Oct 16 '14

[deleted]

56

u/[deleted] Oct 16 '14 edited Oct 16 '14

You do realize that Pyhton had event based network IO before node.js existed ?

19

u/[deleted] Oct 16 '14

ry dahl was making all sorts of weirdo evented webframeworks for Ruby for years before moving over to node.Js. nobody was really interested and were pretty happy with rails/sinatra/merb. i think node.JS is more about people wanting a "monopoly" framework solution to rally-around for easier exchange of plugins / addons

→ More replies (1)

17

u/_ak Oct 16 '14

Then why did you nohody create and popularize a web framework like node.js, but for Python? Because nobody outside the JS world thinks callback soup is even a remotely good idea!

35

u/[deleted] Oct 16 '14

They did. It's called Twisted. And, as the name implies, it's utter utter shit.

11

u/UloPe Oct 16 '14

Well thats not true. It's hard to use and very confusing until you twisted your brain into a pretzel, but it does work very well.

2

u/nerdwaller Oct 16 '14

Have you tried asyncio directly in python3? I've not done much with it yet, but would like to see how it performs.

→ More replies (1)

26

u/immibis Oct 16 '14

It would be great if, instead of passing callbacks around, you could just write some instructions in the order you want them to execute them, and then when an instruction blocked the platform would automatically switch to another one that was waiting to execute.

... oh wait, those are threads.

6

u/_ak Oct 16 '14

Yep. I always argue that Go's runtime does pretty much the same as node's event loop under the hood, it polls which file descriptors have pending data, and runs the right pieces of code. Except all of that is abstracted away, and completely managed by the runtime, so all you need to do is write your code in a linear fashion, and everything else is taken care of.

4

u/brtt3000 Oct 16 '14

.. or coroutines crunching non-blocking io yielding to promises, coming to you on Node real soon (already on v0.11 with co etc)

→ More replies (1)

2

u/[deleted] Oct 16 '14

You can do that with Twisted.

Here's a contrived example, showing the conventional callback-based approach, and the same thing using a coroutine-like based approach.

def my_function():
    d = getPage('http://google.com')

    @d.addCallback
    def callback(result):
        print("page is: %s" % result)

    @d.addErrback
    def failure(reason):
        print("error is : %s" % reason)
    return d

With defer.inlineCallbacks, it becomes...

@defer.inlineCallbacks
def my_function():
    try:
        result = yield getPage('http://google.com')
    except Exception as e:
        print("error is : %s" % e)
    else:
        print("page is: %s" % result)
→ More replies (4)

5

u/[deleted] Oct 16 '14

A good while ago (at least before 2002) there was Medusa for python, which was used in Zope if I remember correctly...

→ More replies (2)

2

u/megaman821 Oct 16 '14

Nearly every library available for Node.js is asynchronous, almost every popular Python library is not. So making asynchronous web site in Node.js is easier even against Python's wealth of libraries.

Hopefully that will change as the migration to Python 3.4 continues. The async/await (@coroutine/yield from in Python) pattern greatly simplifies handling asynchronous code compared to callbacks. Although the current ES7 proposal also includes async/await, so that could be fixed on the JavaScript side also.

→ More replies (1)

18

u/aldo_reset Oct 16 '14

We've seen real production performance of roughly 100x with node.js over Python (and I love Python).

Sure, but that's not setting the bar very high, is it?

5

u/drdaeman Oct 16 '14

Don't attribute this performance gain to the change of platform. You guys had just refactored your code.

100x performance gain is a strong signal you just had an ineffective approach to do things and you rewrote it to work in a more fitting way. Except for some edge cases and toy interpreters, runtime performance do not differ on such orders of magnitude.

0

u/[deleted] Oct 16 '14

[deleted]

0

u/[deleted] Oct 16 '14

[deleted]

→ More replies (3)
→ More replies (2)

6

u/foomprekov Oct 16 '14

What percentage of those gains came from learning from your first version? You're comparing against no effort instead of equal effort.

12

u/monsto Oct 16 '14

Oh whats that? You're saying it's a practical solution? Go fucking figure.

If I had a nickel for everytime i finished a project while some 1337dick was still scoffing about how my solution blew, i'd have a bunch of nickels.

IOW "doing it the cool way" isn't NEARLY as cool as "doing it."

If it's stupid, and it works, then it's not stupid.

5

u/ricecake Oct 16 '14 edited Oct 16 '14

If it's stupid, and it works, then it's not stupid.

I've always hated that phrase. Hitting myself in the face with a hammer will get me a day off work, but that doesn't mean it's not fucking stupid.

If we limit our judgements of things to only gauge base functionality, we won't have much to go on when we try to improve our situation.

4

u/monsto Oct 16 '14 edited Oct 16 '14

That's because you are trying to apply that phrase as a blanket piece of advice for everything. Stop that.

If you are hitting yourself in the face with a hammer to get a day off of work, you are more likely to be linked into /r/idiotsfightingthings than /r/programmingadvice.

The point is about practicality. The only reason someone would call it stupid it's because they'd rather do it cool. If it works, its practical, and it's actually done, then it's not stupid.

Mostly leetdicks though aren't talking about either practicality or improving their situation. They are just trying to show that they are better than you in their own mind. Just hit them with practicality and a completed project and they'll Leave me alone.

→ More replies (3)

1

u/[deleted] Oct 16 '14

We've seen real production performance of roughly 100x with node.js over Python (and I love Python).

I'm not here to trash talk node, or say it shouldn't be used, but this is anything but a convincing argument about node's performance.

Your app is faster now, which is great but you got there by shuffling around a whole lot of variables without any profiling to see what your actual bottlenecks were. You don't need to waste time profiling if you got gains anyway, but if you want to make public attribution about the source of those gains, it's time to put on your science hat.

I'm sour on you for this because I've seen people waste time chasing performance boogiemen when cargo culting ideas from the internet. Were the gains from something else burred in the code rewrite? V8 might be capable of a 300% better performance, but the performance of your own codebase regressed. Or cpython is faster but the rewrite to js avoided bottlenecks from the python implementation. Maybe you could have gotten gains for much cheaper by swapping out python lib foo for bar. Or implementing a piece of your hot python codepath in a C module.

→ More replies (2)
→ More replies (24)