No clue about Go, but how can it take more memory then Javascript on Node? This is hard to believe.
It's a bad comparison, cause the Go version is using a "db" (key/value store) that tends to use quite a bit of memory.
Ditching Go for Node.js
161–170 of 185 posts
Re: Ditching Go for Node.js
#162Earlier quoted context omitted.
On the data structure: arguing for locked mutation is pretty an tricky because at low volumes it'll be faster and at higher traffic volumes it will be slower. And since it's a library, who cares? Golang isn't a language that's old enough to have accumulated a ton dissonance about the "right" way to do things. Golang encourages that kind of code and you see it all over GitHub. Too bad it's something of a trap.
JS is single threaded. Putting a mutex on one data structure is not going to reduce your performance significantly below single threaded.
Mutexs and futexes are more expensive than coroutines and Golang uses futexes a lot.
Re: Ditching Go for Node.js
#163I think you are right, go is not the best language for your project, single threaded just moving blobs of data around node is a good solution. I'm not sure why anyone would have a problem understanding that. (And I'm a guy who hates node but loves go)
Re: Ditching Go for Node.js
#164Earlier quoted context omitted.
I think some programmers want to carefully select a type specialized data structure, and others just bury the problem under a pile of array iteration. And to hell with compile time. If the build takes 10x as long but we run 5% fewer prod servers, that pays for itself in minutes. And if type and nullability checking prevents one prod outage, that saves more time and stress than every build I've waited for this year.
I often don’t understand the Go teams obsession with compile times, but I’ve never worked on large Java or C++ code based that take forever to compile. I mostly want them to optimize for runtime performance even at the expense of compile time, but this does not seem popular with the core team.
You're right. You need to have worked on Google scale C++ programs to understand and acquire the obsession.
Re: Ditching Go for Node.js
#165Earlier quoted context omitted.
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?
interface{} is not reflection, and using both reflection and excessive amounts of interface{} are not a good idea in Go, and frankly, I don't see anything in this code that would require using either
To be clear, my point is that interface{} is the worst case in Go and the only case in JS.
Re: Ditching Go for Node.js
#166Earlier 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…
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?
No, there's nothing special about it, and I probably shouldn't have used that term because it might convey that it is particular to Node. Event loop, callback based programming is easily implemented in most languages.
Re: Ditching Go for Node.js
#167Earlier quoted context omitted.
JS is single threaded. Putting a mutex on one data structure is not going to reduce your performance significantly below single threaded.
Mutexs and futexes are more expensive than coroutines and Golang uses futexes a lot.
Go is multithreaded. Paying a small price to use multiple cores vs. only being able to use a single core? I'll take the multicore. It's not like concurrent lock-free datastructures are without cost...
Re: Ditching Go for Node.js
#168Earlier quoted context omitted.
Mutexs and futexes are more expensive than coroutines and Golang uses futexes a lot.
Go is multithreaded. Paying a small price to use multiple cores vs. only being able to use a single core? I'll take the multicore. It's not like concurrent lock-free datastructures are without cost...
If your workload is primarily I/O then coroutines will lose on the wall clock. And of course parallel workloads are fiddly.
But it's also worth noting Golang's current implementation of channels and messages is (as I've noted) going to be notably slow. Odds are you are going to avoid channels entirely if you care about maximizing multi-core performance.
Which is not to say that Golang "isn't fast". Just that it's not at all surprising that for some workloads NodeJS would outperform it.
Re: Ditching Go for Node.js
#169I feel his pain about the lack of decent WebSockets support in Rust. There's a few Websockets implementations but all of them are meant to run on a separate port from the web server. As in, they want you to run your web server on port 443 and the websocket on... Something else. Which makes zero sense (browsers will deny access to the second port because of security features related to SSL certificates). Also, unless…
I've found two frameworks supported websocket:
https://github.com/tomaka/rouille
https://github.com/actix/actix-web
Ref: https://github.com/flosse/rust-web-framework-comparison
Re: Ditching Go for Node.js
#170Ryan Dahl, the creator of Node.js: "That said, I think Node is not the best system to build a massive server web. I would use Go for that. And honestly, that’s the reason why I left Node. It was the realization that: oh, actually, this is not the best server-side system ever." Full interview: https://www.mappingthejourney.com/single-post/2017/08/31/epi...
I am a huge JS fan and I agree, for purely server side plays it’s probably not the best choice.
I actually think Node has not yet realized its best feature. It’s still in a research phase while it learns its best trick: components that bridge the client and server.
Meteor was an attempt. And server side boot in the MVC frameworks is another attempt. But both are wrong. Both try to create anonymous code that doesn’t know whether it’s on the client or server. But the client and server are different. The winning solution will acknowledge that, and just help the component do both. Once we have components that span client and server we can then write applications that don’t deal directly with HTTP. But not before.
That’ll be a huge thing.