Erlang
Ditching Go for Node.js
91–100 of 185 posts
Re: Ditching Go for Node.js
#92One thing to note is that they were using boltdb, which is an in process K/V store designed for high read loads, and doing a lot of writes to it. boltdb also tends to use a lot of memory, as it's using a mmap'd file. The switch also moved them to sqlite, which I would say is a much better fit for what they are doing, but means a lot of this is an apples and oranges comparison.
And now to get ranty: Boltdb was being handled badly: https://github.com/maxpert/raspchat/blob/79315d861968c126670... You should be using bolt's helper funcs, so you don't forget to close the transaction https://github.com/maxpert/raspchat/blob/79315d861968c126670... At least this is actually deferred, but still. https://github.com/maxpert/raspchat/blob/79315d861968c126670... These messages are horrifying, would be m…
https://github.com/maxpert/raspchat/blob/79315d861968c126670... This is a spinner?! No wonders the code is slow.
The general use of inheritance and very non-idiomatic code makes me think this is another person who ditched Go before understanding any of it. It seems a very popular sport.
Re: Ditching Go for Node.js
#93It's interesting he's referencing the Disruptor pattern. I wrote the Go port of the Disruptor implementation that he links to ( https://github.com/smartystreets/go-disruptor ) a while back and it performed beautifully. That said, channels weren't slow either. Our finding showed that we could easily push 10-30 million messages per second through a channel, so I'm struggling to understand what he defines as slow. That…
have you tried seeing how many messages you can push if you change how often the garbage collector runs? after seeing the Golang garbage collector blog post from cloudflare?
Re: Ditching Go for Node.js
#94I'm happy about this article, not because of what it says, but because of the popularity it got. NodeJS is not as bad as people think and I'm really excited about when it will regain status in the "pros" community.
More like Go has reached peak Go in terms of hype and people are going back to the stack they know best. Go is absolutely not a silver bullet, its community hates "creative solutions" and at the end of the day it's not that enjoyable to write for a lot of people. Go ecosystem isn't that big either compared to JS.
Re: Ditching Go for Node.js
#95This 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"…
I have no dog in this fight because I find static typing tedious, but it’s interesting that Flow doesn’t seem to be winning much mindshare.
Re: Ditching Go for Node.js
#96Some 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`?
Re: Ditching Go for Node.js
#97Besides that, as many here have pointed out, this sounds like a problem somewhere hiding in the Go code ruining the performance, it is certainly true, that an event-handler based approach is increadible efficient to manage a high number of simple requests with limited resources. If every request can be handled in a single event, it only has advantages. It does not require many resources and you don't have to deal with any synchronisation issues.
In many typical web applications you have less if no interaction between the connections, but rather complex logic running at each request. There the event-based approach, which must not block, is getting more complex to manage and you want to use all cpus in the system. There a goroutine based approach should shine much stronger, as the goroutines may block and you don't have to spread your program logic across callbacks.
Re: Ditching Go for Node.js
#98So, 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.
> 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.
Re: Ditching Go for Node.js
#99Some 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…
> The TS API in my case had something like 90% less errors
That sounds like a red flag to me. I hardly have any type related bugs in my pure JS server code. Must be a poor developer in the team. Too easy to blame JS for that.
Re: Ditching Go for Node.js
#100Earlier quoted context omitted.
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.
[deleted]