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

11–20 of 185 posts

Re: Ditching Go for Node.js

#11

Post by inglor »

dullgiulio wrote: post #3
inglor wrote: post #2

I'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?

Yes,

An async function is explicitly async (in its definition).

The syntax is obvious which is why JavaScript chose to go that route (rather than adopt channels at a language level for example).

Plus, 95% of the time I care about the singular return value of a function - I just want something that's a function but async - and not a green thread that's using a channel to send information back. Both conceptually and in the code it's a lot simpler.

Re: Ditching Go for Node.js

#12

Post by nevi-me »

This is a very interesting direction to take. I've built a lot of my personal stuff on JS, and TBH, the one thing I really wish I had right now was a statically typed codebase.

I spend a lot of time thinking about why I'm creating a certain data model, whether I might need to change something in future, etc. About 60% of my productive time is spent thinking about how and why, so I hardly refactor. However, when the need arises, I wish I had something like Kotlin.

For the past few months I've been writing new JS code in TS, adding types here and there, I haven't tried out Kotlin on JS, but I'm hoping to go there.

I'm learning Go, but for other reasons. I find JS to be performant, my oldest active codebase has been around since the v0.8 days.

Re: Ditching Go for Node.js

#13

Post by iends »

verroq wrote: post #5

Why not use mutexes and callbacks instead of channels for pubsub?

This is not considered idiomatic Go and would be a premature optimization unless you ran a profiler and determined that channels are actually your bottleneck. It sounds like this has not been done.

Re: Ditching Go for Node.js

#15

Post by DiThi »

Would Matrix be a good fit for this use case? There are a bunch of different server implementations and the (web based) protocol is relatively simple and very well documented.

Re: Ditching Go for Node.js

#16

Post by anonymoushn »

inglor wrote: post #11
dullgiulio wrote: post #3

Earlier quoted context omitted.

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?

Yes, An async function is explicitly async (in its definition). The syntax is obvious which is why JavaScript chose to go that route (rather than adopt channels at a language level for example). Plus, 95% of the time I care about the singular return value of a function - I just want something that's a function but async - and not a green thread that's using a channel to send information back. Both conceptually and in…

Most of the time you write `let x = await foo()` in js should become `x, err := foo() if err != nil then return nil, err end` in go, not anything to do with channels

Re: Ditching Go for Node.js

#17

Post by iends »

anonymoushn wrote: post #9
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.

Seems like it should be linear??

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

Re: Ditching Go for Node.js

#18

Post by Thaxll »

bryanlarsen wrote: post #7
Thaxll wrote: post #4

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

Goroutine takes 2kb, so 4kb for read / write per conection.

Re: Ditching Go for Node.js

#19

Post by clandry94 »

I've been working on a similar project lately which also uses the gorilla/websocket library. I just tested connecting 1500 connections in parallel like was done in this link for Raspchat, and my application only uses 75 MB along with all other overhead within it. I'm not sure how this would cause a Raspberry Pi with 512MB memory to thrash and come to a crawl unless Raspchat has a ton of other overhead outside of connection management.

Re: Ditching Go for Node.js

#20

Post by JepZ »

bryanlarsen wrote: post #7
Thaxll wrote: post #4

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

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