4 ms·
These are a lot of extraordinary claims. I would love to learn more about the evidence and what make you think this way. There are many successful companies tha
by thanhhaimai 2y ago
These are a lot of extraordinary claims. I would love to learn more about the evidence and what make you think this way. There are many successful companies that built scalable services with golang, so the burden of proof for the above claims are high.
- neonsunset 2y ago"Set 50 instead of 4 to replica count" and "continues scaling when you give it something that isn't anemic 2CPU 512Mi container" are two very different things :) In either case, seeing undeserved praise of Go is the most expected outcome from the audience that used to praise e.g. Elizabeth Holmes. Please do look at the way its internals work, and compare the compiler output (and I mean not the useless ASM that Go's disasm outputs but what is shown by e.g. Ghidra) and primitive overhead with Rust, C# and even Kotlin. Also hearing about Go's concurrent primitives makes me laugh. CSP is a 40 years old concept, and Go bolted itself to it, while also learning nothing from other languages to be modern, therefore can't be effectively used for more advanced concurrency scenarios nor enables you to remove overhead when needed. Try writing a concurrent data structure in Go that performs as fast as in C++. C# let's you do that. Go - not so much.
- kbolino 2y agoA language that officially recommends "don't communicate by sharing memory; share memory by communicating" is obviously not meant to implement concurrent data structures well. This means, in some cases, it is indeed the wrong language to use. Go is no longer positioned at the low-level "systems programming" segment and hasn't been since not long after its release. It's better to think of it as "compiled concurrent Python" than "a competitor to Rust".
- guilhas 2y agoEven the article solves the problem with Go still