We switched to Node.js: the good and the not so good • Hacker News Board

Re: We switched to Node.js: the good and the not so good

#61

Post by StavrosK » Mon, Jan 14, 2013, 4:14 PM UTC

jerf wrote: post #54

StavrosK wrote: post #41

Earlier quoted context omitted.

Ah, so it uses preemptive rather than cooperative multitasking. I find that locking the whole thread is usually an error, so preemptive multitasking wouldn't help much there, and I like how cooperative multitasking lets me reason about the program, but I can see the benefits in both approaches.

Erlang does not have a problem reasoning about the program, because it doesn't share any data. They are actually independent from each other in the same ways that two OS processes are independent from each other (that is, there are still resource contention issues but abstract correctness don't unduly depend on each other). I'm running out of polite ways to say this, but Node advocates really need to learn about othe…

Oh, I'm speaking from more of a Go/gevent approach. Obviously, a correctly-designed program would try to avoid shared data structures as much as possible, in any language, e.g. for Go you would write goroutines that communicate with channels.

The "reasoning" I was referring to was more that I know that simple things like incrementing a global counter is guaranteed to be atomic. I agree with you that that's still a shared structure, and thus dirty, so I avoid it anyway.

Now that you mention it, I don't actually know why I said that before, since I never write production code like that. I guess I was referring to ad-hoc scripts, where I like knowing that I don't need a lock to guarantee atomic operations, and thus they're a bit easier to write.

Re: We switched to Node.js: the good and the not so good

#62

Post by matwood » Mon, Jan 14, 2013, 4:18 PM UTC

PommeDeTerre wrote: post #22

blacktulip wrote: post #9

Earlier quoted context omitted.

I have not tried Node (or in fact JS as a whole) yet. But it seems very hard to avoid JS in these days. I am going to learn it in a few months. Can anyone give me a rough idea how bad it is? (I know some Obj-C so is JS worse than that?)

Coming from Objective-C first, which is generally a rather sensible language, I think you'll be surprised at how stupid, unnecessary and inexcusable many of JavaScript's problems are. People who only have a PHP background, for instance, have become accustomed to such stupidity. They think it's "normal", solely because they don't really know any better. Those coming from C, C++, Java, C#, Ruby, Python or most other la…

I too have been surprised at all of the frameworks coming out for JS to be on more than the browser. From my experience large JS projects are a pain to write and maintain. It's a neat language, but I don't really get why I would want to write my server code in it.

Re: We switched to Node.js: the good and the not so good

#63

Post by StavrosK » Mon, Jan 14, 2013, 4:21 PM UTC

scott_s wrote: post #53

StavrosK wrote: post #39

Earlier quoted context omitted.

There are no reasons to use busy waiting anywhere. This isn't what we're discussing, though.

Well, yes, there is. When implementing locks, it depends on how likely and how long contention is. If the expected cost of busy waiting is less than the expected cost of interacting with a heavier-weight scheduling system (which may mean crossing the kernel boundary), then busy waiting is better. This is, of course, for lower level codes. For example, spin locks (so-called because they spin - or, busy wait - on a sta…

Sure, in that case, it makes sense. As you say, though, it's for lower-level codes.

Re: We switched to Node.js: the good and the not so good

#64

Post by danenania » Mon, Jan 14, 2013, 4:22 PM UTC

jondot wrote: post #55

I am using a mix of Ruby, Node and Java in production but after some hard-learned lessons chose to minimize the Node usage to things I absolutely need. My experience with the Node community: - Great people (Substack!) - Great attitude #node.js/freenode - However, many hours spent on solving bugs in existing libraries. My experience with maintaining production Node code: - It may be more maintainable than EventMachine…

It seems needlessly limiting to make EventMachine and Node your only candidates. Since you've already got java in the stack, what about clojure? What about go?

Re: We switched to Node.js: the good and the not so good

#65

Post by matthavener » Mon, Jan 14, 2013, 5:06 PM UTC

exo762 wrote: post #37

StavrosK wrote: post #35

Earlier quoted context omitted.

Will a "while True" not lock up an Erlang thread?

There are no reasons to use busy waiting in Erlang. Ever.

Is it even possible to busy wait in Erlang?

Re: We switched to Node.js: the good and the not so good

#66

Post by iends » Mon, Jan 14, 2013, 5:16 PM UTC

voidlogic wrote: post #56

omarkj_ wrote: post #3

Earlier quoted context omitted.

There are other reasons for rewriting like getting to a more easily maintainable code or when a previous solution has simply outlived it's usefulness. Also, C is not the only language worth rewriting in.

"Also, C is not the only language worth rewriting in" Agreed! I would really like to see someone write a node.js and Go back-end for the same front-end and do a head to head comparison. As someone who spent a fair amount of time rewriting node.js prototypes in Go, I'm probably biased. I feel like javascript is a much less maintainable language. Perhaps is was the original node.js implementations (I don't think it was…

Any particular lessons learned rewriting from node to Go?

I've got a small but growing node/socket.io app I figured I'd have to one day rewrite in go if I really wanted it to scale.

Re: We switched to Node.js: the good and the not so good

#67

Post by jondot » Mon, Jan 14, 2013, 5:38 PM UTC

danenania wrote: post #64

jondot wrote: post #55

I am using a mix of Ruby, Node and Java in production but after some hard-learned lessons chose to minimize the Node usage to things I absolutely need. My experience with the Node community: - Great people (Substack!) - Great attitude #node.js/freenode - However, many hours spent on solving bugs in existing libraries. My experience with maintaining production Node code: - It may be more maintainable than EventMachine…

It seems needlessly limiting to make EventMachine and Node your only candidates. Since you've already got java in the stack, what about clojure? What about go?

I used the examples from the original article. I think the OP ported an EventMachine code to Node.

When I said 'Java' I really meant JVM. Specifically I'm using Scala.

Regardless, I have a different Clojure based project, with it as well, I prefer doing what clojure has to offer in terms of concurrency (pmap, etc).

I have dipped a toe in Go. Loved the fact that you get a compiled binary, ecosystem still feels skinny. Ended up concluding that in a year or two it'll be worth revisiting.

Re: We switched to Node.js: the good and the not so good

#68

Post by jondot » Mon, Jan 14, 2013, 5:42 PM UTC

antihero wrote: post #52

Say I'm a Python developer and I'm looking to write services that are fast. Would I likely be better off going down the route of node.js, Go, Haskell, Erlang? I mean they are all fantastic languages and I've dabbled in most of them but from what I've read, Go seems to be the best one to use if you don't want to shake your world up, but if you do, Haskell or Erlang are nice new paradigms to dive into. Is this true?

First, you need to define 'fast'. Whats your workload and usecase? Why is python slow for you?

Re: We switched to Node.js: the good and the not so good

#69

Post by continuations » Mon, Jan 14, 2013, 6:05 PM UTC

jondot wrote: post #67

danenania wrote: post #64

Earlier quoted context omitted.

It seems needlessly limiting to make EventMachine and Node your only candidates. Since you've already got java in the stack, what about clojure? What about go?

I used the examples from the original article. I think the OP ported an EventMachine code to Node. When I said 'Java' I really meant JVM. Specifically I'm using Scala. Regardless, I have a different Clojure based project, with it as well, I prefer doing what clojure has to offer in terms of concurrency (pmap, etc). I have dipped a toe in Go. Loved the fact that you get a compiled binary, ecosystem still feels skinny.…

If you're already using Scala, why do you need Node?

What does Node give you that a Scala async framework like Play or Scalatra doesn't?

Also what does Ruby give you that Scala doesn't?

Just wondering why do you choose to use 3 stacks (Ruby, Scala, Node) when one could be enough.

Re: We switched to Node.js: the good and the not so good

#70

Post by embwbam » Mon, Jan 14, 2013, 6:06 PM UTC

mukundmr wrote: post #21

julien wrote: post #4

Earlier quoted context omitted.

Well, the reason we rewrote was not to explode all benchmarks. The reason we rewrote was to be able to ease the maintenance of our code =)

from a long term maintainability perspective, javascript can be notorious. you could always follow a disciplined approach for development to help with maintainability, but that applies to all programming languages. i don't see anything about javascript that makes it more maintainable especially for large projects.

TypeScript makes it way more maintainable.