> Go was sold as a "systems language" for a long timeStill is, but it was also made abundantly clear at the time that those systems were things like network servers specifically. It was even later noted that the team was somewhat surprised that people found uses elsewhere. I do recognize this confused the Rust crowd, who bizarrely think that sum types are known as enums, and think that systems are programs that run on raw hardware (think kernels, embedded software, etc.). But nobody else randomly redefines every word they come across.
In the standard nomenclature, systems are the "opposite" of scripts. Scripts being programs that carry out a single task and then exit upon completion, as opposed to a long-running program that continually carries out (possibly a variety of) tasks. If Go isn't a systems programming language then we can conclude that it is a scripting language. But I've never heard of anyone calling it a scripting language... As far as I can tell, the world generally agrees that Go is a systems language.
And yes, this is where I would agree that Rust and Go are more similar, both being geared towards building systems (although not necessary the same type of systems). Python and Ruby are decidedly geared more towards scripting tasks. But, of course, that doesn't mean you can't build scripts in Go and Rust and systems in Python and Ruby. People were definitely trying to write systems in Python in Ruby.
> I suspect the entire container ecosystem would not have gone with Go if it wasn't for Docker picking Go mostly based on the "systems language" label.
Makes sense. The container ecosystem (Docker, Kubernetes, etc.) was originally built as (and for) network servers — the exact niche Go was designed for. I think you make a good point that they've grown to be so much more, to the point that the network bits are hardly even relevant, but if we could erase these tools and the term "systems language" from memory and start over to solve primarily for the pain points associated with running network servers again, I'm not sure you've made a good case that they wouldn't still land on Go. I get why you say that in hindsight, but these projects didn't have hindsight when they were being first created.
> A lot of the design nexus in Go was to take C and try to improve it with a handful of pared down ideas from Java
That runs counter to the claims of the Go team, who explicitly stated that their goal was to make a fast 'dynamically-typed' language. Obviously they introduced a type system so that the compiler could optimize on known primitive types, so it is not truly dynamically-typed, but it is also obvious that the type system doesn't extend beyond what is necessary for the sake of performance and what was necessary to maintain a dynamically-typed 'feel' around that, much to the chagrin of type theorists.
You are quite right that it does share a lot of commonality with C — they were conceived by the same guy, after all! But, given the goal of being "faster" that makes sense. Modern CPUs are literally designed for C. I'm not sure where Java fits. Limbo I can see. Is that what you meant? Java and Limbo were both created at the same time. Perhaps you've somehow managed to conflate them because of that? A lot of people do suggest that Go and Rust are oft considered similar simply because they were created around the same time.
The Java team did warn the Go team to not to screw up implementing generics like they did. Maybe that's where you got Java in your mind? But the warning was heeded. The generics design Go got is quite different. Or maybe you are thinking of Kubernetes originally being written in Java and being criticized for carrying many of those Java-isms into the Go rewrite?
> they wanted to improve performance so they switched to a compiled language that handles multithreading well.
...while, most importantly, sticking to something that was familiar. Perhaps you have already forgotten, but they also evaluated Rust at the time. "It is too hard to learn", they concluded. A bit overdramatic, sure, but when you read between the lines there was a valid point in there — that Rust wasn't like the tools that were commonly used before it.
Go was. The only somewhat unique thing it brought to the table was goroutines, but even that was simply taking what people were already doing with libraries in Ruby and Python (Twisted, EventMachine, etc.) and formalizing it as part of the language. It wasn't a different way of thinking, just syntax sugar.
And this is why I ultimately conclude that Go is more like Python and Ruby than it is Rust. More so Python, granted. Ruby's message passing model leads to some different conventions. Put the code for a Python program and a Go program side by side, squint slightly, and you aren't apt to be able to even see a difference. Especially if that Python program actually sticks to the Zen of Python. Put a Python program beside a Rust program and they are going to be completely different animals.
So, the original comparison was Go and Ruby, not Go and Python. As mentioned, Go is less like Ruby than it is like Python. To establish Go is more like Ruby we are operating on the premise that Python is more like Ruby than it is Rust, which I posited was the prevailing view. But maybe you disagree and that is where the contention lies? If that’s the case, why do you see Python as being more like Rust than Ruby?