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

After a year of using Node.js in production

geekforbrains.com

Post reply on HN
Print view View original

241–248 of 248 posts

Re: After a year of using Node.js in production

#241

Post by Silhouette »

spion wrote: post #237
Silhouette wrote: post #231

Earlier quoted context omitted.

Just to be clear in case I've given the wrong idea, my point here is not really to criticise Node in general. I'm just saying, with the benefit of hindsight of course, that it was not the ideal choice for that particular job. In particular, because of the hype around Node, I think the people making the decisions (including the developer who was working on it) honestly didn't expect that, and perhaps weren't sure how…

Okay. I've had vastly different experience with node on ARM. Much more reasonable dependencies size then what you report (by about 2 orders of magnitude) and excellent performance from the JIT. Combined with the ability to first write dynamic code then switch to static types, as well as the memory safety, its been a lot more pleasant than working with C. So honestly, I really can't relate to most of what you said her…

Please keep in mind that the Raspberry Pi was only an example. We're talking about embedded here, so there are all kinds of weird and wonderful CPUs and storage systems and I/O components being used in various devices that need to run the code I'm talking about. Certainly not all of them were ARM chips. I don't know which chips caused the big problems with porting Node, nor which specific packages, so it's entirely possible that whatever you've worked on was closer to the mainstream and supported just fine.

Re: After a year of using Node.js in production

#242

Post by danneu »

MichaelGG wrote: post #163
anonyfox wrote: post #143

Earlier quoted context omitted.

Elixir/Phoenix, Go/ , Rust/ ... should all outperform node.js easily, plus they're actually parallel and not just concurrent AND are much more solid languages to begin with.

But aren't all Node.js deploys fronted by a reverse proxy (like nginx) to multiple node processes? That gives them actual parallelism in practise, right? Or is it remotely common to just have a single node process and never use more than one core?

I reckon it's common for Heroku apps to be deployed as one process per dyno.

Re: After a year of using Node.js in production

#243

Post by lenkite »

tylerlh wrote: post #40

The Netflix.com site and webapp runs on Node (and talks to a number of services written in mostly JVM based languages). While we encounter challenges just as we would with any other language -- it works for us and I would argue that it's a pretty big application. There's always a multitude of ways to get something done, and it's up to you to decide what tool will do it best. Don't treat any one language as an end-all…

If I am not wrong, Netflix folks make heavy use of 'stream based programming' using RxJs. This greatly simplifies a lot of the standard problems faced in JS - like callback hell and error handling, if one adopts it consistently across the stack. Not many folks have discovered this as yet.

Re: After a year of using Node.js in production

#244

Post by stevebmark »

dang wrote: post #235
stevebmark wrote: post #139

jesus this guy is a boring loser

This comment breaks the HN guidelines. Please post civilly and substantively, or not at all. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newswelcome.html

got it!

Re: After a year of using Node.js in production

#245

Post by paulddraper »

beders wrote: post #229
paulddraper wrote: post #131

Earlier quoted context omitted.

Yeah, but is that really necessary? GitHub runs Rails and they have load.

It's all about cost. If they would switch to more efficient languages, they could probably run on half of their current servers. But there's the huge cost of rewriting something you already have. Will that affect your total cost significantly, if you can run on less servers. I.e. it's too late to switch now. There needs to be a significant business reason to switch. "Stuff-that-kinda-works but needs more hardware thr…

So ... "Nice but there's more important things"

Re: After a year of using Node.js in production

#246

Post by tylerlh »

MichaelGG wrote: post #162
tylerlh wrote: post #40

The Netflix.com site and webapp runs on Node (and talks to a number of services written in mostly JVM based languages). While we encounter challenges just as we would with any other language -- it works for us and I would argue that it's a pretty big application. There's always a multitude of ways to get something done, and it's up to you to decide what tool will do it best. Don't treat any one language as an end-all…

How big is the Netflix webapp, though? There's what, 5 or 6 main content "views", then around 20 user-editable forms? Plus the help site. Am I viewing this incorrectly? It doesn't just doesn't feel like Netflix is a large app from the UI perspective - maybe that's just good design. Hope this doesn't come off as "I could do this in a weekend", just questioning how big the actual webapp is.

I believe you would be surprised were you to look under the hood.

There are a number of different "UI areas" in Netflix.com -- homepage, titles, signup (multiple flavors of this, depending on how you're signing up), onboarding, member browsing/viewing experiences, account management, numerous partner integrations, etc... not to mention all the work that goes into per-user customization, AB testing, and internationalization.

No offense taken on the question. IMO, if you look at the site and view it as simple then we've done our job correctly. :)

Re: After a year of using Node.js in production

#247

Post by spion »

lobster_johnson wrote: post #124
spion wrote: post #60

Earlier quoted context omitted.

There is no replacement because they're a fundamentally broken idea. They require the following to happen, in that order: * V8 needs to optimize try-finally * Node core needs to add try-finally at every single place where callbacks are invoked and make sure all state and resource cleanup is properly done to support domains * Popular libraries need to also add try-finally handlers for the above. As to why this is a pr…

Domains are used for another reason: To emulate thread-local variables. I hope that support is not going away, because it's really handy.

Its interesting that the same problem (TLS) can also be solved with something similar to promises :)

Re: After a year of using Node.js in production

#248

Post by auvrw »

Silhouette wrote: post #232
auvrw wrote: post #218

Earlier quoted context omitted.

maybe i haven't read this thread closely enough ... the parent to this post mentions "lessons of the past" and its parent mentions typed languages, so uh, what lessons are being discussed here? certainty not "the past teaches that typed languages are best," b/c lisp

For what it's worth, I don't think Lisp is a very convincing example of how useful a language with a limited type system can be, because to a first approximation no-one uses it. But more generally, the modern web development world is only just waking up to the idea that if you want to build software sensibly beyond a very small scale, you need tools for modularity and composition. Separation of concerns is important…

> to a first approximation

late reply, but something occurred to me to say more as a (hopefully funny) witticism than an actual talking point:

if we approximate usage in terms of a poly sum w/ coeff derivatives wrt time (Taylor series is the word, I think) then one might estimate lisp to be a very much used language

Post reply on HN