Ditching Go for Node.js • Hacker News Board

Re: Ditching Go for Node.js

#181

Post by todd8 » Sat, Nov 25, 2017, 2:48 PM UTC

amelius wrote: post #74

todd8 wrote: post #44

Earlier quoted context omitted.

A fully connected graph of n users contains n*(n-1) links if users don't connect to themselves (I would describe this as polynomial growth in the number of channels, a lot better than exponential). A chat broker that acts as a switchboard between users could, I suppose, reduce this to a linear relationship between users and channels.

You have to divide that by 2. It's "half the matrix".

Thanks, my mistake. You're right, there are n(n-1)/2 arcs in the fully connected graph (K_n).

Re: Ditching Go for Node.js

#182

Post by im_down_w_otp » Sun, Nov 26, 2017, 6:29 PM UTC

jonathanoliver wrote: post #179

im_down_w_otp wrote: post #101

Earlier quoted context omitted.

On a really slow, in-order-execution processor w/ tiny caches and fairly awful front-side bus that's also all responsible for managing the network connection over USB? The thing about Intel non-Atom level hardware is that Intel has spent a lot of money over the better part of two decades packing processors full of features that make all kinds of theoretically inefficient things run pretty fast. This is not true of th…

Good point. Go channels weren't nearly as efficient on non-x86 hardware. When I compiled my Go Disruptor port and ran it on my Nexus 5 mobile phone, I was getting about 9 million messages/sec.

And your Nexus 5 is much, much faster than a Raspberry Pi :-)

Re: Ditching Go for Node.js

#183

Post by koffiezet » Mon, Nov 27, 2017, 5:34 PM UTC

dullgiulio wrote: post #92

Vendan wrote: post #49

Earlier quoted context omitted.

And now to get ranty: Boltdb was being handled badly: https://github.com/maxpert/raspchat/blob/79315d861968c126670... You should be using bolt's helper funcs, so you don't forget to close the transaction https://github.com/maxpert/raspchat/blob/79315d861968c126670... At least this is actually deferred, but still. https://github.com/maxpert/raspchat/blob/79315d861968c126670... These messages are horrifying, would be m…

https://github.com/maxpert/raspchat/blob/79315d861968c126670... This is a spinner?! No wonders the code is slow. The general use of inheritance and very non-idiomatic code makes me think this is another person who ditched Go before understanding any of it. It seems a very popular sport.

And if you look where that code is called from - wrapped inside a mutex...

And then people wonder why it eats up 100% CPU and are completely maxed out before reaching 1000 requests/sec...

Yup... Bad slow language!

Re: Ditching Go for Node.js

#184

Post by styfle » Wed, Dec 06, 2017, 12:18 PM UTC

erikpukinskis wrote: post #170

MrBuddyCasino wrote: post #116

Ryan Dahl, the creator of Node.js: "That said, I think Node is not the best system to build a massive server web. I would use Go for that. And honestly, that’s the reason why I left Node. It was the realization that: oh, actually, this is not the best server-side system ever." Full interview: https://www.mappingthejourney.com/single-post/2017/08/31/epi...

I am a huge JS fan and I agree, for purely server side plays it’s probably not the best choice. I actually think Node has not yet realized its best feature. It’s still in a research phase while it learns its best trick: components that bridge the client and server. Meteor was an attempt. And server side boot in the MVC frameworks is another attempt. But both are wrong. Both try to create anonymous code that doesn’t k…

Good point.

What do you think about shared components using React SSR?

https://github.com/styfle/react-server-example-tsx

Re: Ditching Go for Node.js

#185

Post by Thetawaves » Thu, Dec 07, 2017, 8:50 PM UTC

tankenmate wrote: post #178

Thetawaves wrote: post #176

Earlier quoted context omitted.

You generally need one thread to read for incoming messages, typical: for { select { case You need another thread to listen for messages on a channel and send them out the socket typical: for { select { case

Instead of? for { select { case

You wont be able to write messages while blocked on the read in this scenario.