> I think that most C developers (which is what I was primarily at the time) would interpret "systems language" to mean "loosely equivalent to C or C++"
And that would be a fair interpretation. Before Go, Rust, and the like arrived on the scene C and C++ were about the only languages you'd use to write said long-running programs. You could maybe also throw Java in there, but safe to say it was a pretty short list. Most everyone else was focused on scripting workloads there for the longest time. I might even suggest that Go was the very language that broke us out of that loop, ushering in the new era of systems languages.
> Funnily enough, Russ Cox himself said in 2014 that he "slightly regrets" calling Go a systems programming language because it leads to confusion[1].
Stands to reason. Nobody wants to introduce confusion (maybe Pike, who is a language purist). Alternative interpretations obviously exist. Still, it's not clear what else to call it unless we want to settle on Go being a scripting language. But I don't think either of us consider Go as being a scripting language, do we?
> I don't think of it is as being primarily a network server.
In hindsight, as was said. But we're talking about day one. No project has the full vision at the onset. Software is built up, piece by piece, with next steps determined as you go. There may have been some glimmer of understanding of needing to interface with the system at a low level that Go is not well suited for, but "oooh shiny networking abilities"...
> but is instead about what purpose it serves
Well, we know for certain that the only intended purpose for Go was network services. Obviously people have found other uses for it in the wild, but it was always made clear that it was built for a purpose. So, which languages do you think are more in line with building network services? Those that became famous because of Django and Rails, or those that became famous for Torvalds not wanting it in the Linux kernel?
> Before Go, Rust, and the like arrived on the scene
I'm glad you now agree that Go and Rust have enough similarities to be grouped together in this discussion. ;)
> There may have been some glimmer of understanding of needing to interface with the system at a low level that Go is not well suited for, but "oooh shiny networking abilities"...
I mean, that's just not how Docker was developed at all. I was there (okay, maybe not at the very start but I was involved in the project when it was still very young).
The honest answer is that they didn't foresee how annoying it would be to deal with those things in Go, not that they didn't expect to have to do those things. For one thing, their internal version of Docker at dotCloud was written in Python and so they had a good idea of the kinds of things they will need to do in the rewrite. Lots of lessons were learned over the past decade, you can't just retroactively apply modern maxims like that (i.e., "well, obviously we now know that Go isn't good at X so when they started using it obviously they didn't really plan to use it for X" isn't particularly convincing, especially to people who actually lived through it).
(But none of this is particularly relevant to the original point IMHO.)
> I'm glad you now agree that Go and Rust have enough similarities to be grouped together in this discussion. ;)
I'm glad you finally got around to reading the thread. ;) They've been grouped on the same spectrum since the beginning. For example, "Go is most similar to Go, but on the spectrum is way closer to Python and Ruby than it is Rust."
> The honest answer is that they didn't foresee how annoying it would be to deal with those things in Go
I'm sure it was underestimated — developers tend to be optimistic — but certainly when the creators are explicitly telling you that it is a 'dynamically-typed' language intended for writing network services you're going to understand that you're in for a least a bit of a bumpy ride if you try use it for something that would traditionally have been written in C. No need to look back retroactively. Go was originally announced that way.
Regardless, what is curious, though, is that it wasn't recognized as annoying very quickly at the onset. This does suggest, like before, that work began in the places Go excels and once the other stuff came 'round the sunk costs starting sinking in. You were there, so feel free to tell us the whole story, but you'd think the ship would have been abandoned pretty quickly if the "hard parts" were where things started. It is not like the team didn't already give up on another language.
> (But none of this is particularly relevant to the original point IMHO.)
Or is it? I mean, if Go were just like Rust then wouldn't you say those annoying aspects of Docker wouldn't be annoying anymore? That was my read from earlier. But since Go is more like Python and Ruby...
And that would be a fair interpretation. Before Go, Rust, and the like arrived on the scene C and C++ were about the only languages you'd use to write said long-running programs. You could maybe also throw Java in there, but safe to say it was a pretty short list. Most everyone else was focused on scripting workloads there for the longest time. I might even suggest that Go was the very language that broke us out of that loop, ushering in the new era of systems languages.
> Funnily enough, Russ Cox himself said in 2014 that he "slightly regrets" calling Go a systems programming language because it leads to confusion[1].
Stands to reason. Nobody wants to introduce confusion (maybe Pike, who is a language purist). Alternative interpretations obviously exist. Still, it's not clear what else to call it unless we want to settle on Go being a scripting language. But I don't think either of us consider Go as being a scripting language, do we?
> I don't think of it is as being primarily a network server.
In hindsight, as was said. But we're talking about day one. No project has the full vision at the onset. Software is built up, piece by piece, with next steps determined as you go. There may have been some glimmer of understanding of needing to interface with the system at a low level that Go is not well suited for, but "oooh shiny networking abilities"...
> but is instead about what purpose it serves
Well, we know for certain that the only intended purpose for Go was network services. Obviously people have found other uses for it in the wild, but it was always made clear that it was built for a purpose. So, which languages do you think are more in line with building network services? Those that became famous because of Django and Rails, or those that became famous for Torvalds not wanting it in the Linux kernel?