> As someone who is interested in systems programming, and has experience working with Go
I wonder how Go got it's reputation as a systems language. Imo, it occupies the same abstraction level as Java or C#.
I wonder how Go got it's reputation as a systems language. Imo, it occupies the same abstraction level as Java or C#.
https://www.youtube.com/watch?v=rKnDgT73v8s
I would not say it's the same as Java or C#. The crucial difference is that it compiles to a native executable binary file, not something that needs a virtual machine.
"C Is Not a Low-level Language" (https://queue.acm.org/detail.cfm?id=3212479)
While I feel that article is being too harsh on C, it would be interesting to have cache intrinsics just like we have SIMD intrinsics. I would imagine that would be more complex to implement, however.
I tried to find the video on youtube, but to no avail.
The more complicated answer is that, traditionally, systems programming languages were those which are not scripting or assembler languages. If you listen to Pike for more than a few seconds you'll soon notice that he's a bit of a language purist, so whatever modern interpretation you might have for a term is unlikely to match what he is communicating.
More specifically, it was announced as a systems programming language designed for things like web servers and systems of that nature, with more control than Java in some areas. Even with conflicting definitions of systems, there should have been no illusions about it being designed to be in roughly the same space as Java with that context. It was very much suggested from the onset that it was meant to compete with Java.
But, ultimately the game of telephone truncated the context that would have helped with finding the right definition of systems and, I expect exacerbate things, there was Rust coming onto the scene juicing the situation with its fans often claiming that "Go isn't a systems language, Rust is!" leaving some revisionism about people believing that Go was a systems language (in the modern sense).
Unless one doesn't consider writing compilers, linkers, GPU debuggers, container management, syscall emulators, unikernels systems programming.
Since you can write the above with any language, perhaps even Python or Lua if you wanted to, it's not exactly the ability to write the above or the fact of having written the above in a language, that makes a language to be considered a "systems programming language".
In some way, what is called a systems languge it's not a technical capacity thing ("can do X, Y and Z, so it's a systems language").
It's a term applied deliberately, that also includes other aspects.
Doubly so if what we're concerned about is labelling itself, like "what is and what isn't considered a systems language". Then we're in the word domain, not in the measurement domain.
In fact their holy C can only be used for the daily activities, when going outside the ISO C Bible, tainting itself with unholy compiler extensions.
By "enough detail" and "clear bounds" i mean: a group of people independently arriving at the same sets of classification based on your provided definitions.
There's no such thing - that was the whole point of my comment.
A systems language is not such because of conforming to a definition, it's a delibarate classification ("this language is, that one isn't" as opposed to "this langauge is because it conforms to this definition"). And that "is/isn't" isn't even up to the individual programmer, it's cultural.
There are characteristics that drive this classification, but it's not driven by a strict definition. It's more of "know it when I see it" kind of affair.
It is kinda confusing that the term is used for that and for low-level embedded/firmware/kernel programming, despite both areas having little in common with each other.
Is it, though? My impression it only started with Go calling it that way
It's not meant to mean operating systems language, nor embedded systems language.
Rather for writing parts of a systems, such as servers. I would say that the definition is not that far away for Java or C#, but the expectation is simply that it would be "lower level" components of a system, including unix like utilities.
Now it means building higher-level userland tools and internet oriented tools. I think the implicit consensus is the lower level stuff is a "solved problem".
Not powerful enough to be compared to Java.
Probably closer to Node.js, that's to say, it is like JavaScript in the server. Judging by the developers who use it. Except it is compiled.