Hacker News Reader

Comment by qaq | Hacker News Reader

Since when did per minute become a thing? 16K/sec is typical for a node app on fairly avg server.

16k r/s is not trivial to get for a non-hello-world app on NodeJS even on a big server, but if you read the article you'd see it's actually about a quarter of that.

... Yeah basically it is an article about using concurrency.

I was not obviously commenting on the content but on a trend of coming up with measurements that make for a catchy title.

> 16K/sec is typical for a node app on fairly avg server.

This certainly doesn't read like "I'm talking about the title" to me.

Also, in other parts of the thread you take performance questions seriously, further diluting the impression your post was about the title or phrasing.

The title is presenting handling 16K/sec as something special my only original point was that the author is using per minute metrics to make numbers look more impressive. It's very possible that I did a very poor job of making that point :). My comment that I am sure Go more performant than node was beign downvoted so that took things in a diff. direction.

A million sounds nice.

Yes, but 'per minute' not so much. It really is rather odd to express perf figures like this

It’s not a thing and it’s fairly trivial to get to that load on a typical go app as well.

I am sure Go can do at the very least 2x-3x vs node for the same workload.

Since you are sure, do you have any examples or proof to back that ?

A random result from Google http://blog.digg.com/post/141552444676/making-the-switch-fro.... My day job is writing large scale node services that service over million concur. clients doing fairly intensive data acquisition/processing so I am not hating on Node :)

Don't get me wrong, I don't intend to mock your statement in any way but a statement backed by some data and/or actual examples adds a lot of credibility to it.

I think Golang benefits from two related things:

1: There's basically one way to do anything, even if you pull in a library that collects those one ways to do another thing.

2: Those one ways are each developed by some of the most skilled engineers in the world and documented by someone with amazing clarity. (https://golang.org/pkg/)

I have always had a lot of trouble trying to learn to program (used to struggle more with focus and memory), but Golang is just easy. I can look at an API I wrote as a learning project after 6 months of not writing any code and understand it perfectly.

Node was not so bad when things worked, but I hit the same brick wall I did with [insert language] when something didn't go like the guide said it should.

Since Node is single threaded how do you make that scale on multi core without something that spawn multiple Node app and thus using 2x 3x 4x the memory ...?

It's obviously application specific in our case data is written to Kafka and a bunch of workers are reading it off and do processing

It depends on the workload.

CPU bound? For sure.

Fake CPU bound (as this one is, spending tons of time in go's concurrency machinery), clearly not.

I/O bound? I would have said no before Spectre and Meltdown ruined all our intuitions about performance. It's just a mess right now.

New Relic

Reply on news.ycombinator.com