Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hard-won lessons: Five years with Node.js

blog.scottnonnenberg.com

Post reply on HN
Print view View original

141–150 of 365 posts

Re: Hard-won lessons: Five years with Node.js

#141

Post by sgift »

m1sta_ wrote: post #133
stickfigure wrote: post #121

Earlier quoted context omitted.

The default behavior for Node when there is an uncaught error is to crash the process, killing all requests in flight. Even if you go out of your way to stop this default behavior, errors still likely leave the process in an inconsistent state. Node can't just unwind a few stack frames like synchronous platforms. Do you read JSON from ajax post bodies? Do you access fields in that JSON without sanity checking it? Try…

If only node had exception handling and functions!

Node has - for me - the same problem as C#. Unchecked exceptions on every corner. You don't even know what can explode until it explodes. And then takes your Node instance down. But I am one of these weirdos who likes checked exceptions in Java, so maybe this is not a problem for others.

Re: Hard-won lessons: Five years with Node.js

#142

Post by sgift »

eel wrote: post #67
lasfter wrote: post #15

I can't imagine choosing to write Javascript on the server, but considering its popularity I'm wondering if I'm wrong. So I'm curious as to the reasons people chose Node.js and whether you would recommend it, anybody willing to share their experiences?

At a previous gig, without getting into specifics, we built a huge internal client-server system. The client was written in Node.js and ran as services on both Windows and Linux on a few thousand machines. The server was written in Node.js and ran as a Linux daemon. Node.js matched the developers' skill sets and gave us the ability to quickly write a server that could easily handle several thousand concurrent request…

> * Target environment is not Windows

That one is still my main problem. I know, I know, Windows is evil and so on, but our customers use it. We are remarkably free in choosing our tools or whatever, but Windows is usually a constant (Intranet environments) and every day I crash against the absolute "Windows is a second class platform" problem of NPM modules. For an environment which is supposedly platform-agnostic the amount of "only on Unix" is astonishing.

Re: Hard-won lessons: Five years with Node.js

#143

Post by tannhaeuser »

lasfter wrote: post #15

I can't imagine choosing to write Javascript on the server, but considering its popularity I'm wondering if I'm wrong. So I'm curious as to the reasons people chose Node.js and whether you would recommend it, anybody willing to share their experiences?

Node.js being based on JavaScript was accidental I believe. What the developer was after was an asynchronous, evented, non-blocking/non-multithreaded server runtime for game servers and similar apps without Java et al.'s "synchronized" and "volatile" model.

Of course, Node.js is only suited for I/O-scheduled but not CPU-heavy workloads.

Re: Hard-won lessons: Five years with Node.js

#144

Post by lod723 »

ralusek wrote: post #132
lod723 wrote: post #97

Earlier quoted context omitted.

> Once you get the hang of promises, you are capable of doing concurrent asynchronous tasks in a manner that would be significantly more difficult in any other language. FYI, anyone who has worked with Elixir or Erlang views these sort of statements about Node as completely ridiculous. The only languages right now that are making a serious effort to bring real concurrency to modern programming are Go and Elixir. Node…

For concurrent asynchronous tasks, being single threaded or multithreaded shouldn't make any meaningful difference. To make a million concurrent asynchronous calls on a single thread takes couple MS, to make on multiple threads takes about the same. For concurrent SYNCHRONOUS tasks, being single threaded or multithreaded makes a huge difference, but that's not what we're talking about here. It's also not at all fair…

The multiprocess Node concurrency model is brittle and fault intolerant. The event loop scan actually has real bottlenecks at a certain level of fds in flight. A real scheduler really wins here; libuv sits below the knowledge of the runtime to really be optimal. You become CPU bound far sooner than you expect.

With a global heap, you also become memory bound far sooner than you expect as well.

Re: Hard-won lessons: Five years with Node.js

#145

Post by lod723 »

goatlover wrote: post #135
lod723 wrote: post #97

Earlier quoted context omitted.

> Once you get the hang of promises, you are capable of doing concurrent asynchronous tasks in a manner that would be significantly more difficult in any other language. FYI, anyone who has worked with Elixir or Erlang views these sort of statements about Node as completely ridiculous. The only languages right now that are making a serious effort to bring real concurrency to modern programming are Go and Elixir. Node…

Julia's support for concurrency is right there with Go and Elixir.

Will take a look! There really should be more ecosystems that try to solve modern problems effectively.

Re: Hard-won lessons: Five years with Node.js

#146

Post by petersellers »

ars wrote: post #109
hota_mazi wrote: post #94

Earlier quoted context omitted.

> The edit/refresh cycle starts to slow IDEA and Eclipse compile your code as you write it. And with Hotswap, you don't even need to redeploy anything. They also all offer REPL's that are much more sophisticated than anything Javascript has to offer. I think you haven't used a JVM language and its ecosystem in a very long time.

> And with Hotswap, you don't even need to redeploy anything. Except when you have to restart the JVM because you added a class or a whole bunch of other things that it can't hotswap in the new code.

It's true that the hotswap support built in to the JVM is somewhat limited, but there are tools that are more comprehensive and can hotswap new classes, methods, method signature changes, etc. (JRebel and spring-loaded are the ones that come to mind).

Re: Hard-won lessons: Five years with Node.js

#147

Post by Daishiman »

erikpukinskis wrote: post #78
cnp wrote: post #39

Earlier quoted context omitted.

> Another subject the author brings up is "the ecosystem". Javascript has so many libraries that keeping up with them, their updates, and using them in a canonical way throughout a large codebase is a full-time job for at least one engineer. I love the language, but this is absolutely true.

Same, and same. It's very research-y. It is an incredible place to work if you treat your development process like research anyway, but if you just want to jam through production cycles I would pick Python or something stable.

So, not development?

Re: Hard-won lessons: Five years with Node.js

#148

Post by [deleted] »

hota_mazi wrote: post #123
ars wrote: post #109

Earlier quoted context omitted.

> And with Hotswap, you don't even need to redeploy anything. Except when you have to restart the JVM because you added a class or a whole bunch of other things that it can't hotswap in the new code.

Still better than any dynamically typed language (I mean any) where you always have to redeploy everything since none of these language support incremental compilation, let alone incremental reloading.

[deleted]

Re: Hard-won lessons: Five years with Node.js

#149

Post by nepeckman »

hota_mazi wrote: post #73
pyrophane wrote: post #70

Earlier quoted context omitted.

I can understand it. If you want to just get something together quickly then dynamic languages do have an edge. They allow you to say "just give me whatever and if it fits, it fits" and if you aren't that concerned about it breaking you can build something extremely fast.

You're just repeating the same claim without any evidence. Why is it faster to write code in a dynamically typed language? Most modern statically typed languages have type inference so you don't even need to write type annotations for the most part, assuming these extra characters were the reason. So what's that mysterious reason that makes writing dynamically typed language faster?

The slow part of static languages isn't just typing out the annotations. Its needing to describe the type in the first place, and needing to change that type description if the shape of your data changes. If you want to prototype quickly in a dynamic language, you don't need to mess around with any sort of class description as you decide how you want your program to work.

Re: Hard-won lessons: Five years with Node.js

#150

Post by scalatohaskell »

rapsey wrote: post #127
hota_mazi wrote: post #57

Earlier quoted context omitted.

> yet I still turn to Node.js for proof of concept projects because certain things are just quicker to implement. Why? Writing Java is really very fast these days, especially with IDE's. I can get a small web site serving JSON REST requests and memcache up in ten minutes with a simple Maven/Gradle build and full IDE integration.

> I can get a small web site serving JSON REST requests and memcache up in ten minutes with a simple Maven/Gradle build and full IDE integration Java guys always say how they have really developed tooling and look down on other languages. The problem is those nice tools have become a hindrance as well. You can't develop in Java/Kotlin if you don't use those huge complicated tools. I can't speak for all, but at least…

> You can't develop in Java/Kotlin if you don't use those huge complicated tools.

This is based on what? It is totally untrue from my experience. Quite the opposite.

Post reply on HN