Gotchas from Two Years with Node • Hacker News Board

Re: Gotchas from Two Years with Node

#121

Post by falcolas » Wed, Apr 15, 2015, 12:46 PM UTC

Roboprog wrote: post #119

falcolas wrote: post #71

Earlier quoted context omitted.

> The main advantage of Go is that it makes it easier to parallelize your code thanks to goroutines and channels Well, that and Go is not bounded by a VM (jit or no), and will simply be faster than JavaScript, given the exact same logic. Don't discount the cost of running on a VM, and all of the abstractions which are thrown on top of plain JavaScript to help manage the callback complexity.

Given enough money, a JIT can be made arbitrarily fast, it seems (e.g. - JVM, LLVM bitcode interpreter) Given time, don't assume any particular language implementation will always be faster. Go might only run faster than Javascript on the odd years, depending on corporate budgets for compiler / VM tuning the previous year.

The JVM has received a lot of money and attention over the years, yet still falls quite short of its direct compiled competitors in almost any benchmark. The threshold for "enough" when it comes to improving a JIT is still arbitrarily high.

Re: Gotchas from Two Years with Node

#122

Post by toxicFork » Wed, Apr 15, 2015, 1:04 PM UTC

mikegioia wrote: post #64

toxicFork wrote: post #18

Earlier quoted context omitted.

Same happens with Java, C++, and many other languages. There are web server packages on node that do catch errors that happen in synchronous code. For async, you can use promises, which take errors into consideration. I'm not sure what happens on unhandled async errors on other languages, I guess in Java you could have a dangling request (happened to me before) or it could crash the app (also happened to me before).…

You CAN get a white page or an error message by default, you don't "just get" them. It doesn't make any sense either because (surprise) you can and should configure that away. I see your edit but what's the point of that sentence other than to jab at PHP?

It's only because I have worked on php projects where my involvement started since various degrees of completion, and these issues happened to me most frequently. My point was that PHP can be configured (or not) to handle errors better, but so can node.

Re: Gotchas from Two Years with Node

#123

Post by mark_l_watson » Wed, Apr 15, 2015, 2:08 PM UTC

cpprototypes wrote: post #98

Node has a lot of flaws today. But, even with those flaws, it's very useful for quick prototyping (discipline is required here since it must be a true prototype which means throwing away the code) and command line scripting (for me, it has mostly replaced python for small scripting tasks). Using it in a production service is possible, but should be limited to simple services (not too much business logic and it should…

I agree that JavaScript will get better with ES7, etc. that said, I am half way throw the edX Typescript class and it offers a lot of what ES6 and future releases will offer today. I also really like ClojureScript but TypeScript is an incredibly well designed language.

Re: Gotchas from Two Years with Node

#124

Post by zkhalique » Fri, Apr 17, 2015, 1:59 PM UTC

wpietri wrote: post #111

EGreg wrote: post #45

Earlier quoted context omitted.

Every language requires you to be careful. C makes you do array out of bounds checks. Javascript makes you worry about tying up your event loop with eg massive string processing. Just get a friggin asynchronous JSON parser if you're running it on untrusted client input (ie any client input). It's not that hard. Maybe node should provide a "tainted" feature for modules to mark variables that are "untrusted" and provid…

I think good languages require you to care about things that matter for your domain. For example, C's bounds checks are a consequence of demanding fine-grained control. The problem for me with Node here is that whole cooperative-multitasking thing doesn't directly buy you anything. It's a historical accident, not a necessary downside of an otherwise-positive choice. That's distinct from a browser or a GUI environment…

I care about single threadedness and evented paradigm to provide guarantees and simplify my reasoning about things. I know that if I call a function, it will return synchronously, but not necessarily with a callback. I know that my objects won't be clobbered by other threads, etc.

Re: Gotchas from Two Years with Node

#125

Post by 72deluxe » Tue, Apr 21, 2015, 9:44 AM UTC

bitg wrote: post #97

72deluxe wrote: post #21

Earlier quoted context omitted.

C++ - couldn't you just put a catch(...) within your request handler and return 500 if that is hit?

Yes you can do a global catch, but the error still happened, the functionality was faulty and you didn't handle it properly (you just showed the error, period).

Stops the entire process dying though, so you can keep on serving?