Ditching Go for Node.js
github.com
Ditching Go for Node.js
1–10 of 185 posts
Re: Ditching Go for Node.js
#2I've dabbled a lot with Go. I've found it _very_ effective to a wide variety of problems I don't really have most of the time.
If I wanted to implement RAFT I would probably pick Go. If I want a simple REST/GraphSQL server then Node.js is so much easier. `async/await` is nicer for me than goroutines and I find my code easier to reason about.
Full disclosure: I'm a Node.js core team member and a Go fan. Part of my reasoning might be how much nicer Node.js got these last couple of years.
Re: Ditching Go for Node.js
#3I've dabbled a lot with Go. I've found it _very_ effective to a wide variety of problems I don't really have most of the time. If I wanted to implement RAFT I would probably pick Go. If I want a simple REST/GraphSQL server then Node.js is so much easier. `async/await` is nicer for me than goroutines and I find my code easier to reason about. Full disclosure: I'm a Node.js core team member and a Go fan. Part of my rea…
Channels are basically the primitive with which you can implement futures, thread-safe queues, etc.
Can you elaborate on why you think async/await is easier (for you) to reason about than a goroutine and a channel?
Re: Ditching Go for Node.js
#4OP is complaining about Goroutine stack size at 4kb per connection, his test shows that Node8 is taking up to 150MB of memory with 5k users, 4kb*5k = 20MB for Go memory, I don't understand how Nodejs can take less memory than Go, and without real numbers / test I'm pretty sure he's doing something wrong somewhere.
From my experience on some large prod deployment, Nodejs app takes much more memory and CPU vs Go app for doing similar work.
Re: Ditching Go for Node.js
#5Why not use mutexes and callbacks instead of channels for pubsub?
Re: Ditching Go for Node.js
#6That's the funny thing modern Node is surprisingly usable and if using TS has very advanced tooling.
Re: Ditching Go for Node.js
#7OP is complaining about Goroutine stack size at 4kb per connection, his test shows that Node8 is taking up to 150MB of memory with 5k users, 4kb*5k = 20MB for Go memory, I don't understand how Nodejs can take less memory than Go, and without real numbers / test I'm pretty sure he's doing something wrong somewhere. From my experience on some large prod deployment, Nodejs app takes much more memory and CPU vs Go app fo…
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.
Re: Ditching Go for Node.js
#8Some 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 large portion of my job in a large node.js code base in the $day_job). You'll basically have to resort to using lldb and heapdumps in the Node world. I'm surprised the number of concurrent clients you go with Go was so small. I know lots of people using Go and Gorilla websockets that exceed 1.5k clients with similar memory constraints. To be perfectly honest, it sounds like you're doing something wrong.
As of Go 1.4, the default stack size per goroutine was 2KB and not 4KB.
If you add in TypeScript, you'll have a better type system than Go provides in the Node ecosystem. That's a huge point for using Node.js, especially if there are multiple contributors and the code base lasts for many years.
Re: Ditching Go for Node.js
#9OP is complaining about Goroutine stack size at 4kb per connection, his test shows that Node8 is taking up to 150MB of memory with 5k users, 4kb*5k = 20MB for Go memory, I don't understand how Nodejs can take less memory than Go, and without real numbers / test I'm pretty sure he's doing something wrong somewhere. From my experience on some large prod deployment, Nodejs app takes much more memory and CPU vs Go app fo…
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.
Seems like it should be linear??
Re: Ditching Go for Node.js
#10I've dabbled a lot with Go. I've found it _very_ effective to a wide variety of problems I don't really have most of the time. If I wanted to implement RAFT I would probably pick Go. If I want a simple REST/GraphSQL server then Node.js is so much easier. `async/await` is nicer for me than goroutines and I find my code easier to reason about. Full disclosure: I'm a Node.js core team member and a Go fan. Part of my rea…
I think it's a decision between levels of abstraction, with Node being a level higher than Go in that area. Probably easier to use it to link services together (glue apps), because with Go you'll probably have to define types and such a lot.