Technically, neither the limit or full progression is defined by the information available. The set {k8, k3, k0} may be equally represented as a decreasing series of container orchestrators with reducing prime differences.
it smokes Spring in benchmarks, often by a factor of 10x or more, and on plaintext it's 50x faster than spring and even with the fastest Rust/C++ frameworks, so must be some awfully light baggage
Any modern language allows you to create threads (semantically equivalent to goroutines) and pass messages between them. Most of them even have high-level concurrency support such as parallel map, structured concurrency, reactive extensions, type-safe generic collections...
We could say that Golang makes concurrency using thread semantics scale to a large number of threads. When this paradigm is appropriate, then indeed Go is nice. The select statement is nice. But this is not always the right approach.
Yes, it is true that go needs slightly fewer characters to launch a naked thread than in C# or Java. In that sense, it is easier. Anyone who considers that a major selling point is a walking race condition.
As a tongue in cheek analogy, what if we consider my new language G, in which G is an alias for goto. G is going to finally make control flow easy. I've done away with complicated control flow constructs such as for or while - users wouldn't understand them anyway. Users are encouraged to use the G keyword liberally. After all, it's only 1 character. Indeed, by that metric, it's even simpler than go's go keyword. What could go wrong?
`k8s, k3s, ... = k{x}s as x -> 0`
in which case we have 8/x -> +inf