From the Clive design paper[1]:

At this moment, the kernel used is a BSD kernel, but we are working now on making Go run on the bare hardware and on hypervisors. When that is done, the BSD kernels will be replaced with our own one.

So if that is enough to be a systems programming language, then C# is also one on account of the Singularity OS[2].

[1]: http://lsub.org/export/clivesys.pdf [2]: https://en.wikipedia.org/wiki/Singularity_(operating_system)

I can be made to be one, one still needs to remember Singularity and Midori aren't using pure C#, they have extended the language. Namely Sing# and System C# respectively.

Both projects influenced the design of native .NET on Windows Phone 8, followed by .NET Native, IILC and CoreRT.

Also many of the C# extensions on Midori are being explored for C# 7 and future versions.

C# when compiled to native code is not much different than using Modula-3, in terms of available features. It just needs a little more fine tuning in terms of features.

Last I checked Go doesn't have any memory placement semantics. That's a non-starter IMO for a systems programming language.

I like performance in my systems programming languages and you won't get that if you can't control where your memory lives.

> Last I checked Go doesn't have any memory placement semantics.

Many OSes like Oberon, Cedar, Topaz, SPIN among others were written in languages without direct support for it, so it is possible to write an OS without it.

The runtime package just needs to offer the services for it, just like many C functions are actually implemented in Assembly.

Theoretically they (or whomever writes an OS in Go) could extend the runtime to add something like `makestack(Type, size IntegerType) Type` to mimic alloca or add in a guarantee that `var b [100]byte` will be allocated on the stack.

(Right now I think it is, but I know there's a Go issue dealing with a function like this, and one of the comments was about potentially creating `a` on the heap and returning an invisible pointer instead of the actual 1e9 bytes.)

    func foo() (a [1e9]byte) { return a }

There's a lot more than that that you have to do. You can't even implement defer without allocation, just to name one example.

True, the amount of Assembly in a bare metal runtime in Go vs a runtime free version of Rust will be higher.

Still, there are quite a few scenarios that could be served by such implementation, instead of being implemented in C or C++.

As I mentioned in another thread, any embedded board computer similar to a Raspberry PI could most likely be easily targeted by such cross-compiler.

"Systems programming language" seems to be one a frequent definition miscommunication, right alongside "a Lisp" and "self taugt programmer".

People use the phrases without acknowledging or without realizing that there is a great breadth (and sometimes controversy) in what people take them to mean. I think you're doing it right defining it where you use it.

You cannot use Go in kernel programming at all without a monumental amount of work. You'd need your own implementation of the language. Go originally did have a runtime that did not require systemcalls and could run on bare hardware, however, this was removed very early on as not being worth the effort.

Yes I do remember that runtime when I was still reading gonuts.

As always, a language and its implementations are not the same thing.

It is nothing special to have a bare runtime that would enable a Go application to be statically compiled and deployed into a Raspberry PI, for example.

It just needs someone to create such Go compiler.

Of course, such work would probably be a nice thesis project for OS design classes.