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

71–80 of 185 posts

Re: Ditching Go for Node.js

#71

Post by w4tson »

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…

What a great comment. I know it’s a bit of a generalization but it’s helped me understand why some might get fanatical.

Re: Ditching Go for Node.js

#72

Post by nickthemagicman »

Vendan wrote: post #58
nickthemagicman wrote: post #55

TJ Hollowaychuck the author of express.js had the opposite opinion. https://medium.com/@tjholowaychuk/farewell-node-js-4ba9e7f3e...

As did Ryan Dahl, the creator of node.js https://www.mappingthejourney.com/single-post/2017/08/31/epi...

Ha! Thats insane the creator of Node switched to Go.

Re: Ditching Go for Node.js

#73

Post by acover »

iends wrote: post #50
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…

You're comparing core libraries of Go with non-core libraries of Node.js. Since Go libraries are not versioned without a tool like dep, you're putting trust that master doesn't have breaking changes vs hoping the maintainer follows SemVer correctly. In fact, even the core Go team has problem with this and has to revert changes to things under golang.org/x/ when they break backwards compatibility.

Node's fs library changed within the last 2 years. I copy pasted code and it failed.

Re: Ditching Go for Node.js

#74

Post by amelius »

todd8 wrote: post #44
bryanlarsen wrote: post #7

Earlier quoted context omitted.

It's 2 per connection, so that's 40MB of RAM. The OP also said that was minor compared to the channel overhead -- it seems the number of channels was exponential to the number of users in a room.

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".

Re: Ditching Go for Node.js

#75

Post by jonathanoliver »

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 said, with a few tweaks to the Go memory model and I think I could take the Disruptor project to completion. Without those tweaks, I have to do memory fences in assembly.

Re: Ditching Go for Node.js

#76

Post by marcusramberg »

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/

Re: Ditching Go for Node.js

#78

Post by tonyedgecombe »

romanovcode wrote: post #61
fermuch wrote: post #27

Earlier quoted context omitted.

My main concern with node is how fast everything moves. Try to maintain a project that started with es5, then migrated to es6 (but some legacy code is still es5), then added some es2017 and now is adding slowly typescript to the monster, and all of this in just 3 years! Things become a mess in no time, tooling changes constantly, and maintaining legacy code while developing new parts with current best practices helps…

The secret is to rely on as little npm packages as possible and if you do, rely on very very popular ones.

Which applies equally well to Ruby, Python, Go etc.

Re: Ditching Go for Node.js

#79

Post by lenkite »

tankenmate wrote: post #42

Why two (or three) go routines per connection? Why not one net socket (for reads) and two channels (one for writes, other for pub/sub) and select() between them? It seems like the OP is trying too hard to avoid event loops.

Please upvote parent. This is the first thing that struck my mind too. golang offers `select` for non-blocking calls. Deeply skeptical that node.js is the best solution for a chat service. (unless the backend is serving rendered UI's)

Re: Ditching Go for Node.js

#80

Post by KirinDave »

nevi-me wrote: post #52
KirinDave wrote: post #43

Earlier quoted context omitted.

You have two excellent options: TypeScript and PureScript. Even better, they play fairly well together. You can work in Purescript but still provide well typed integration points for contributors that can't. And uh, no one here is talking about how fantastically slow Go channels are. But I just saw the code last night, and it's not hard for 20 year old techniques to beat out a "futex for literally every message send"…

I'm already using TypeScript, but you sometimes have to bend over backwards to get it to work nicely with a huge JS codebase (which I have). Talking about channels, I haven't gotten there with my Go learning. Few things beat websockets + a nice wrapper (with simplicity). For example, I'm doing realtime transit, and as part of it I'm sending out hundreds of vehicle positions per 5-7 seconds. On the back-end I have a p…

I'm having trouble understanding what you're saying here, but I think we agree?

Please do consider checking out PureScript. It's a lot of the good parts of Haskell and some of it's libraries look like sorcery they're so good.

Post reply on HN