51–60 of 185 posts
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. :)
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 n…
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"…
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 pubsub through a gRPC stream, and I stream positions to socket.io topics. Works beautifully, I can't imagine having to roll it out manually over websockets. In another thread here, someone mentions how non-trivial working with websockets is in Rust. I think that until we have a socket.io (server) version for other languages, Node.js will always beat most other languages.
No clue about Go, but how can it take more memory then Javascript on Node? This is hard to believe.
I think it’s the event loop model reuses more per connection. He mentions nothing is stopping you from implementing an event loop model for the pub-sub in go, just there wasn’t any library support and he didn’t want to spend time building it out when it is the default model in Node.
I was curious about the memory usage for Elixir. It’s the second time I’ve read (without details).
https://medium.com/@tjholowaychuk/farewell-node-js-4ba9e7f3e...
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…
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.
FWIW I predominantly use PHP, so I have no dog in this fight.
Earlier quoted context omitted.
I think it’s the event loop model reuses more per connection. He mentions nothing is stopping you from implementing an event loop model for the pub-sub in go, just there wasn’t any library support and he didn’t want to spend time building it out when it is the default model in Node.
There was an event loop implemented in Go on HN a few weeks/months ago that people might find interesting: https://github.com/tidwall/evio
TJ Hollowaychuck the author of express.js had the opposite opinion. https://medium.com/@tjholowaychuk/farewell-node-js-4ba9e7f3e...
https://www.mappingthejourney.com/single-post/2017/08/31/epi...
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.
I do not see this in the code linked to from the article.
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…
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…
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 version of the library. I found that a bit scary. Not sure if it actually causes problems though.