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

61–70 of 185 posts

Re: Ditching Go for Node.js

#61

Post by romanovcode »

fermuch wrote: post #27
iends wrote: post #21

Earlier quoted context omitted.

It's incredibly easy to throw stuff together in Node.js, it's much harder to maintain over time. TS helps with this but you still run into really hard to diagnose memory leaks (mostly in 3rd party packages written in C++, but sometime in Node core itself). The tooling for these type of issues is really poor in my experience.

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.

Re: Ditching Go for Node.js

#62

Post by zokier »

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?

Re: Ditching Go for Node.js

#63

Post by weberc2 »

bryanlarsen wrote: post #29
iends wrote: post #17

Earlier quoted context omitted.

Hopefully it's linear, or it's implemented wrong.

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 words, in the worst case, some scenarios may require you to drop into `interface{}` in Go, which has the same safety guarantees as any type in JavaScript. This way only ~3% of your code is type-unsafe instead of JavaScript's 100%.

While I think there are lots of valid criticisms of Go (concurrency correctness is still hard and its type system is not very good for certain tasks), none of these are reasons to switch to JavaScript, as the author did. If he was struggling with goroutines and channels, he could still elect for a Node-like architecture (even making it single-threaded by setting GOMAXPROCS=1). If he needed generics and unions (as he cited), he switched to a language without them and without any static types at all (or a single static type, if you will); in Go he could have downgraded to `interface{}` which is analogous to JavaScript's one static type, and he would have only gave up type safety in the bits of code where Go's type system was lacking instead of everywhere.

I don't want to give the impression of overselling Go here; it's just that for the cited criteria, Go is strictly better than JavaScript.

Re: Ditching Go for Node.js

#64

Post by weberc2 »

JepZ wrote: post #20
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.

And I thought the memory usage of channels depends on the buffer size.

This is correct.

Re: Ditching Go for Node.js

#65

Post by iends »

blowski wrote: post #56
ryanplant-au wrote: post #48

Earlier quoted context omitted.

There are quite a few things I like about Go, but it's just so hard to leave the safety and reliability of TypeScript. Go's limited type system is its fatal handicap IMO.

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 Java people don’t understand why they should give up an expressive type system for faster compile times. (Might see this from people who love C++ templates too.)

At least that’s some generalizations I’ve observed, YMMV.

Re: Ditching Go for Node.js

#66

Post by bryanlarsen »

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…

Sure, if you don't mind writing your own websocket and pub/sub libraries.

Re: Ditching Go for Node.js

#67

Post by [deleted] »

fauigerzigerk wrote: post #60
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…

Is it not a problem in practice when TS type declarations and their associated JS code are written by different people at different times for different versions of a library? I have no experience with maintaining TS projects over a longer period of time, but I have started some experimental TS projects where I was looking for type declarations. What I found didn't seem to have any formal reference to a specific versi…

[deleted]

Re: Ditching Go for Node.js

#68

Post by adamweston »

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.

Like a bus?

Re: Ditching Go for Node.js

#69

Post by weberc2 »

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.

This seems to be a commonly-misunderstood point, so I would like to clarify a few things for readers. Go's tooling isn't great, but to characterize it as "trusting master" is inaccurate. Besides tools like `dep`, you can also vendor your dependencies manually or use submodules to pin to a known-good version of your dependencies. There are also tools like Nix which give you fully-reproducible builds. Just because Go has historically punted on the problem doesn't mean there aren't lots of better solutions than "trusting master". :)

Re: Ditching Go for Node.js

#70

Post by adamweston »

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…

Node makes the Node-like architecture much easier than it would be in Go, sort of by definition. Also, wouldn't Node's JIT fare much better in the face of dynamic typing than using reflection (interface {}) everywhere?
Post reply on HN