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

111–120 of 185 posts

Re: Ditching Go for Node.js

#111

Post by iends »

chimeracoder wrote: post #98
iends wrote: post #50

Earlier quoted context omitted.

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.

> 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. The Go team has no problem with this; /x/ packages are explicitly not covered by the backwards compatibility guarantee, and in fact they may be considered to disappear at any point.

I’m specifically talking about things not under the Go 1.0 compatibility guarantee because those things are obviously reverted. Different Go packages from the Go team have different guarantees, for example being compatible with the with the last two Go releases only. I’m on mobile so I can get you examples later after thanksgiving festivities are over but this definitely happens, but you wouldn’t notice unless you read a lot of the Go commits or run into the issue yourself.

Re: Ditching Go for Node.js

#112

Post by tschellenbach »

I'm working on the exact opposite migration at the moment :) (Most of our stack is Go, but we use the excellent Faye library written in Node) The Node code is really well done. https://faye.jcoglan.com/ Nothing wrong with the Node codebase. In our case we just had to add a lot of business logic. I could have done that in Node (we did for a long time), but I decided that with the latest set of changes we'd bring this component in line with the rest of our infrastructure.

It's hard to know without the code, but the author seems to be doing a few things wrong:

1. You only need a few channels, not N. Maybe 4-5 is enough. 2. In terms of goroutines you only need as many as are actively communicating with your server. So creating a new connection creates a goroutine, sending a message to a channel creates a goroutine etc. 3. You need something like Redis if you want to support multiple nodes

For inspiration check out this awesome project: https://github.com/faye/faye-redis-node

This will perform well in Node and even better in Go.

Re: Ditching Go for Node.js

#113

Post by iends »

acover wrote: post #73
iends wrote: post #50

Earlier quoted context omitted.

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.

I guess you’re talking about well published changes resulting in new major versions being released?

Re: Ditching Go for Node.js

#114

Post by the_common_man »

acover wrote: post #73
iends wrote: post #50

Earlier quoted context omitted.

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.

Usually those things are pretty solid especially wrt backwards compat. I am curious as to what you copy/pasted and how it failed.

Re: Ditching Go for Node.js

#115

Post by the_common_man »

nickthemagicman wrote: post #72
Vendan wrote: post #58

Earlier quoted context omitted.

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.

Node is very different now from what he started.

Re: Ditching Go for Node.js

#116

Post by MrBuddyCasino »

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

Re: Ditching Go for Node.js

#117

Post by iends »

MuffinFlavored wrote: post #96
iends wrote: post #8

Some random thoughts as somebody who codes a lot of Node.js at work and a lot Go in my freetime (and sometimes at work): Did you try using pprof and the other tooling go provides to better understand your performance limitations? Tooling is a lot better in go ecosystem for understanding CPU and memory consumption, so if/when you run into into issues with Node you're going to be in a world of pain (this is basically a…

> Tooling is a lot better in go ecosystem for understanding CPU and memory consumption, so if/when you run into into issues with Node you're going to be in a world of pain (this is basically a large portion of my job in a large node.js code base in the $day_job). Is there no movement to change that? What about `node --inspect`?

node —-inspect is a great debugger but last I looked the tooling around memory wasn’t very good. As far as I know, the best practice is to use Ben Nooordius’ heapdump tool (which is super flakey between bugs and Linux oom killer) or lldb with a node plugin. Joynet has/had some cool stuff for illuminos based OSes and IBM seems to be working on some tooling but it’s not there yet.

Re: Ditching Go for Node.js

#118

Post by iends »

erik_seaberg wrote: post #110
iends wrote: post #65

Earlier quoted context omitted.

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.

I often don’t understand the Go teams obsession with compile times, but I’ve never worked on large Java or C++ code based that take forever to compile. I mostly want them to optimize for runtime performance even at the expense of compile time, but this does not seem popular with the core team.

Re: Ditching Go for Node.js

#120

Post by zsombor »

weberc2 wrote: post #63
bryanlarsen wrote: post #29

Earlier quoted context omitted.

Hopefully, but all he said was "fanout" which could be either. He knows it's implemented wrong, that's the point of the article: that Go doesn't make it easy for him to implement it right. The only question is the degree of wrongness. :)

I don't think this criticism holds water since he opted for JavaScript. If he was having problems with goroutines and channels, he could have picked a Node-like architecture (single-threaded, callback-driven) and still likely enjoyed better performance (and optimization tooling!) than with Node. If his issue was Go's type system, then he shouldn't have chosen a language with a strictly worse type system. In other wor…

Both Go and JS are async and callback driven. The difference is that with JS those nasty callbacks are painfully explicit, whereas it is all hidden in Go. Node's callstack is a goroutine, except that the latter can also be preempted. If you have 100000 requests in progress in Node, it will consume at least as much memory as a well written Go program would.
Post reply on HN