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

Ditching Go for Node.js

github.com

Post reply on HN
Print view View original

101–110 of 185 posts

Re: Ditching Go for Node.js

#101

Post by im_down_w_otp »

jonathanoliver wrote: post #75

It's interesting he's referencing the Disruptor pattern. I wrote the Go port of the Disruptor implementation that he links to ( https://github.com/smartystreets/go-disruptor ) a while back and it performed beautifully. That said, channels weren't slow either. Our finding showed that we could easily push 10-30 million messages per second through a channel, so I'm struggling to understand what he defines as slow. That…

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 the Broadcom SoCs on a Raspberry Pi.

Re: Ditching Go for Node.js

#102

Post by andmarios »

Using go's websocket library would also be viable.

For the receiving end, go can use http handlers for websockets. So when a message from any websocket is received the handler will be spawn and process it (just as any http request). Preferably dispatch it to a big central channel.

Keeping separate channels for each websocket seems overkill to me. Go has maps. Create a map with all the websocket connections and maybe smaller maps for each chat room, then set n workers to listen to the central channel and dispatch messages directly to each room member.

Re: Ditching Go for Node.js

#103

Post by crucialfelix »

grsblk wrote: post #99
chmln wrote: post #39

Earlier quoted context omitted.

I've found typescript an invaluable tool. Having worked on large backend codebases in both TS and JS, the difference is stark. The TS API in my case had something like 90% less errors, and those were all subtle bugs in business logic. On the other hand, the large JS API over time had all sorts of unexpected type errors and undefined behavior. I'm aware that this is anecdotal evidence, but TS is pretty much a no-brain…

> The TS API in my case had something like 90% less errors That sounds like a red flag to me. I hardly have any type related bugs in my pure JS server code. Must be a poor developer in the team. Too easy to blame JS for that.

That's the great thing about Type systems. It doesn't matter if the development team is amazing or not. Typescript still makes huge classes of errors impossible. It also speeds up development due to superior IDE support.

Re: Ditching Go for Node.js

#105

Post by jimsmart »

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.

As the time-old adage goes "a bad workman blames his tools".

Re: Ditching Go for Node.js

#106

Post by petre »

marcusramberg wrote: post #76
krylon wrote: post #45

So, I am not a big fan of Javascript. I do not despise it or anything, I just never got to like it. I guess. I did really love POE, though, so when I heard of Node.JS, I thought I will probably like this very much. I am not sure what happened. I think it was the tutorials being always out of date. Node.js seem so be such a fast-moving target. I do not mind asynchronous, callback-driven code. But when a tutorial that…

If you liked POE you might enjoy Mojolicious :) http://mojolicious.org/

Writing async Mojo::IOLoop code is so much less verbose, easier than POE. It's possibly the most elegant Perl event loop. Thank you.

Re: Ditching Go for Node.js

#107

Post by Vendan »

zokier wrote: post #62

As someone who has neither Go, nodejs, or RPi experience the results seem surprising. Many have already commented that the author must have been doing something wrong; the code is there for everyone to see, so could some wiser gopher take a look and tell whats actually going on here?

I did, and wrote some else in here, but a lot of it boils down to poor choices in the Go code. They're using an embedded K/V store designed for high read loads and are writing to it often, there's really complex concurrent lockfree datastructures, and very poorly designed deserialization systems. On the flip side, they switched to Node and to a db that can deal with mixed read/write, nixed all the complex datastructures, and node can deal with unstructured JSON.

Re: Ditching Go for Node.js

#109

Post by jimsmart »

If instead of ditching Go he had posted some kind of help request to the 'gonuts' group / mailing list, I'm 100% certain that several people would've helped him with code reviews and feedback. I've seen this happen in the gonuts group countless times, including contributions/assistance from the core Go team that hang out there :)

As noted by other commenters, below, the code seems to have some issues. And, if it still didn't perform well after addressing those, somebody in gonuts would've helped teach how to profile it, and then expert-eyes could have looked over the profiler output and provided further feedback.

Re: Ditching Go for Node.js

#110

Post by erik_seaberg »

iends wrote: post #65
blowski wrote: post #56

Earlier quoted context omitted.

It’s interesting how divisive Go’s type system is. For some people it’s the main reason they use it, for others it’s a fatal handicap. FWIW I predominantly use PHP, so I have no dog in this fight.

I think a lot of the differences between how people view Go is based on where they are previously coming from. The C/C++ folks are used to worse or more complex type systems so they view Go as fresh air. The “better python” people love the easy to use type system and the performance improvements. But those “better python” people are used to things like package managers which the C/C++ have done just fine without. The…

I think some programmers want to carefully select a type specialized data structure, and others just bury the problem under a pile of array iteration.

And to hell with compile time. If the build takes 10x as long but we run 5% fewer prod servers, that pays for itself in minutes. And if type and nullability checking prevents one prod outage, that saves more time and stress than every build I've waited for this year.

Post reply on HN