From the modern systems programming languages set, Go does better in this respect. But admittedly it doesn't reach to quite as low in fitness for low level programming as Rust.
Oh, not even close. It does what most languages do and just elides, ignores, or hard-codes the answers to all the questions Rust has. That's a solution, sure, a very valid one chosen by many languages over many decades, but certainly not "much better". We absolutely need at least one language that doesn't hide all that and I think the programming language community as a whole will really benefit from the list of choices for that being expanded from "C++", which is getting really long in the tooth And I'm not even sure C++ was ever really designed to be this language, I think a lot of it just sort of happened by default and it sort of backed into this role, and frankly, it shows. Rust being designed for this can't hardly help but be nicer, even if we completely ripped out the borrow checker aspect.
Depends if one considers compilers, linkers, networking stacks, kernel emulation, unikernels, userspace drivers, databases, GPGPU debugging systems programming or not.
I personally consider better use Go than C for such purposes, even if they aren't "systems programming".
I think this is a matter of opinion not fact. I have worked as a Go programmer for three separate companies and it may be the least readable, least understandable language I have encountered.
Yes. The only people for whom this is controversial are message board nerds. The actual language designers don't have much trouble over the concept. Here's a link to the designers of Rust, C++, Go, and D on a panel having little problem working through the nuances:
This perpetual debate reminds me of the trouble HN used to have with the concepts of "contractors" and "consultants", where any time someone mentioned that they were doing consulting work there'd be an argument about whether it was in fact contracting. It's a message board tic, is what I'm saying, not a real semantic concern.
To be fair, that first question about 'what is a systems programming language' is answered by Rob Pike then Andrei Alexandrescu as
Pike: When we first announced Go we called it a systems programming language, and I slightly regret that because a lot of people assumed that meant it was an operating systems writing language. And what we should have called it was a 'server writing language', which is what we really thought of it as. As I said in the talk before and the questions, it's turned out to be more generally useful than that. But know what I understand is that what we have is a cloud infrastructure language because what we used to call servers are now called cloud infrastructure. And so another definition of systems programming is stuff that runs in the cloud.
Alexandrescu: I'm really glad I let Rob speak right now because my first question was 'go introduces itself as a systems programming language' and then that disappeared from the website. What's the deal with that? So he was way ahead of me by preempting that possible question.
So it seems to me that they struggle with the nuances of the concept as much as the commenters here, particularly as it pertains to Golang.
Depends if one considers compilers, linkers, networking stacks, kernel emulation, unikernels, userspace drivers, databases, GPGPU debugging systems programming or not.
Despite my opinion on Go's design, I rather would like to see people using Go instead of C for such use cases.
To be fair, compilers and linkers can be thought of as pure functions (if we ignore stuff like including timestamps in builds e.g.). They have no special requirements language-wise. You can write them in any general purpose programming language. Even Brainfuck will do (for one-file programs fed through stdin). No argument about the others though.
Although I guess JIT compilers may be classified as systems programming, since you need to do some OS-specific tricks with virtual memory during execution of the compiler.
Yes, as it's used for that a lot. Eg many databases (CockroachDB, Prometheus, InfluxDB, dgraph etc), gVisor, Kubernetes, Fuchsia, etcd, and so on. And also in the origin story it was aiming to compete with C++ for many use cases IIRC.
That's tricky to answer, because it depends a lot on what you count as "system software". If you mean literally "the operating system", then arguably not. But if you include middleware, databases and other "infrastructure" stuff, then arguably yes.
A proper database can be implemented in python -- I've done it -- but that doesn't make it a systems language. A "systems language" comes with the strong implication that it is possible to write an implementation of most software that is competitive with the state-of-the-art in terms of performance, efficiency, and/or scalability. That is only possible in languages like C, C++, Rust, and similar, hence the "systems language" tag.
Languages that are not systems language trade-off this capability for other benefits like concise expressiveness and ease of use.
Lots of real world systems have other design tradeoffs than aiming to be state of the art in those axis. Eg cost, security, maintainability, adaptability to changes, etc.
Agreed. And I didn't mean to imply that it's impossible to use Go that way, but I think it's fair to say that it's less common and perhaps even less desirable to do that.
OTOH, people have written (at least parts of) Operating Systems in Java[1] even, so never say never...
Yes it is, but not a a good low level systems language mainly due to garbage collection and runtime requirements. It still is used for writing keyword here systems.
