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…
Java or C# solved all of this like 10 years ago but people like making this hard on themselves.
So, 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.
> You're comparing core libraries of Go with non-core libraries of Node.js
OTOH Node.js is much more dependant on third party libraries than Go
> Since go does not have generics or unions my only option right now is to decode message in a base message struct with just the @ JSON field and then based on that try to decode message in a full payload struct. If he is in control of his protocol, why did he not shape it to suit his parser library? Instead of this: message1 = { "@": "foo", "foo1": 1, "foo2": 2 } message2 = { "@": "bar", "bar1": 1, "bar2": 2 } Do th…
I support ports of a Golang library and protocol that did this and I am very tired of having to suffer Go's anemic type system in every other language I work with. Please stop infecting us with Go-specific type tags (that btw make the protocol versioning story much more complicated) and either demand Go support generics like every other modern statically typed language, or accept your language is ill-equipped for par…
This isn't Golang specific; most statically typed languages are going to fall back on a similar pattern(TypeScript, C#, Javascript, etc). Take a look at AWS's API schemas and you will see. Personally, I loath API schemas designed with the assumption of a dynamically typed language.
> Since go does not have generics or unions my only option right now is to decode message in a base message struct with just the @ JSON field and then based on that try to decode message in a full payload struct. If he is in control of his protocol, why did he not shape it to suit his parser library? Instead of this: message1 = { "@": "foo", "foo1": 1, "foo2": 2 } message2 = { "@": "bar", "bar1": 1, "bar2": 2 } Do th…
This is "an" option for go, but I prefer a type or kind field. This plays better in other languages like C#, Java, TypeScript, and etc in my experience.
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.
A great carpenter can hammer a nail with a screwdriver, but that doesn't mean it's a good idea.
When the tools help you, a good developer can focus on making better things rather than not making mistakes.
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.
I am not too familiar with TypeScript (I only know that typing is optional for backwards compatibility). What are some practical examples of strengths it has over Go?
> Since go does not have generics or unions my only option right now is to decode message in a base message struct with just the @ JSON field and then based on that try to decode message in a full payload struct. If he is in control of his protocol, why did he not shape it to suit his parser library? Instead of this: message1 = { "@": "foo", "foo1": 1, "foo2": 2 } message2 = { "@": "bar", "bar1": 1, "bar2": 2 } Do th…
Better pattern is http://eagain.net/articles/go-json-kind/ Then you do one switch to get the correct message type to decode into, and boom, you can just `.Run` or `.Handle` or however you design the interface, and you are done.
Some variation of this is certainly what I would recommend. Elasticsearch API uses the GP's method, interestingly as it's a Java project?!, and is not that fun to work with in certain languages type systems :|
Illegal relicensing aside, this entire kerfuffle still makes anbad case for Golang. If it's THAT much easier to make a more efficient server with a fully dynamic language using just coroutines then why should anyone ever use Go in this case? Saying, "this implementation is bad" might work in another comparison, but given how much of Golang's implementation and engineering philosophy has been driven by an argument of…
No. There was a lot of effort put into things that make no sense in the go version, including using a concurrent, lockfree, snapshot iterating hash array, where they'd most likely have better performance in this case with a map and a mutex. This was NOT simple. The node.js version is simple. The Go version is overblown in complexity and abusing the language. Rewrite the go version using just as simple of structures,…
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.
It’s interesting how divisive Go’s type system is. For some people it’s the main reason they use it, for others it’s a fatal handicap. FWIW I predominantly use PHP, so I have no dog in this fight.
I think a lot of the differences between how people view Go is based on where they are previously coming from. The C/C++ folks are used to worse or more complex type systems so they view Go as fresh air. The “better python” people love the easy to use type system and the performance improvements. But those “better python” people are used to things like package managers which the C/C++ have done just fine without. The…
Java - expressive type system ? The bar must have been set really low by Go...