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?
