Hacker News Reader

Comment by bitmapbrother | Hacker News Reader

.1 of a millisecond is very impressive. Does this mean Go can finally be considered a systems programming language?

Go can become a systems programming language, even if the GC haters don't think so.

It has the same features as Oberon for systems, programming which was used to build quite a few Workstation OS at Swiss Federal Institute of Technology in Zurich (ETHZ), by Niklaus Wirth.

https://en.wikipedia.org/wiki/Oberon_(operating_system)

You can read the source code here in the 2013 revised edition of the 1992 book.

http://people.inf.ethz.ch/wirth/ProjectOberon/index.html

The only thing missing from Go versus what Oberon offered is register access on the unsafe package, but even then can be sorted out with an extension or a few calls into Assembly.

Oberon-07, which is even more minimalist that either Go or the original Oberon is sold by Astrobe for bare metal programming on cortex M boards.

http://www.astrobe.com/default.htm

Go is already bootstraped into itself, so the writing compilers is taken care of.

It is used by Docker and Kubernetes for managing containers.

It just needs someone writing an OS with Go for its Master or PhD thesis, or even just port Oberon source code, which is freely available into Go.

http://wiki.osdev.org/Go_Bare_Bones

Personally, I would say latency isn't the problem, and that not being able to avoid the gc makes Go automatically not a systems programming language. Not all situations can afford a gc, and really for a lot of systems programming usage (Particularly embedded systems) using a gc just obscures memory usage when you in a lot of cases the memory can be declared statically to begin with (Ensuring a maximum amount of memory usage).

That's not to say you couldn't potentially write an OS or an embedded system in Go (I mean, you can write OS's in Lisp if you really want) but I doubt it would be fun and I doubt anybody would recommend it. You definitely won't be writing idiomatic Go without a lot of extra pieces that you can't really afford in those situations.

Using Oberon, Java and .NET is surely more fun than plain C and there are a few embedded companies selling such stacks for their boards.

Most other sophisticated GCs (e.g. .NET and Java's) can obtain pause times in a similar range for generation 0 collections. So if GC is the reason you don't want to use one of those you'd probably be more interested in improvements in worst case pause times. Go is however very good at avoiding unnecessary object allocation and doesn't need a JIT so it may still be closer to what you need than those languages.

Right, and tenured generation collections are already concurrent in HotSpot and .NET. Generally only heap compaction needs to stop the world; you can disable compaction if this is a problem for you.

What the Go developers consider a "systems programming language" was exactly explained in the very first announcement/presentation of Go. They clearly outlined that it's for building systems like Google's, not operating systems.

> .1 of a millisecond is very impressive. Does this mean Go can finally be considered a systems programming language?

Can you write an OS kernel in Go ? no Go's runtime still depends on a OS. And whoever talked about Go as a system language didn't have kernels in mind, but "network infrastructure".

Of course you can, time to learn about Mesa/Cedar, Modula-2+, Modula-3, Oberon, Sing#, System C# and possibly a few others.

Here you can learn how those guys at Swiss Federal Institute of Technology in Zurich did it.

http://people.inf.ethz.ch/wirth/ProjectOberon/index.html

Basically the runtime is done bare metal thus becomes the OS kernel.

Oh, and Oberon wasn't just a research OS, it was actually used across the computing department by many of its employees.

Go needs a runtime, but it need not be a full OS; it could be a not too big library that gets linked to a kernel written in go.

Similarly, can you write an OS kernel in ISO C? No, you still need some assembly or runtime support. For example, ISO C doesn't have any notion of making syscalls or returning from the kernel to a caller or for setting up page tables.

Any argument why go isn't suitable for systems programming along these lines should be about how much and what kind of runtime is acceptable for a systems programming language.

A (fairly popular, I think, but certainly not universally agreed upon) argument could be that systems programming languages cannot have garbage collection because it should be possible to implement a garbage collector in them, and doing that in a language that already has one is possible but silly.

Go's garbage collector is implemented in Go.

I can't find it in the documentation, but I would think that must be implemented in ProtoGo, where ProtoGo is a Go-like language that doesn't use Go's garbage collector or a library that does (Enforcing not using anything that uses the garbage collector may be left to the programmer)

That is necessary even with a concurrent garbage collector because a garbage collector that allocates in its own heap may hang itself (propaganda allocates; gc triggered; gc allocates; gc triggered to satisfy the allocation; new gc triggered; etc.) . Or do Go's developers accept this risk and live with it?

> Enforcing not using anything that uses the garbage collector may be left to the programmer

It's left to the compiler actually. Programmers can't be trusted.

The runtime does not implicitly generate garbage (like arbitrary Go code). It is compiled with a mode that fails compilation if something can't be stack-allocated. When heap allocation is necessary, it is requested manually. However, the memory returned is garbage collected, as usual, there is no free.

Besides 4ad reply, here you can see how Oberon has its GC implemented in Oberon, as another example of a bootstrapped GC enabled systems programming language.

http://people.inf.ethz.ch/wirth/ProjectOberon/Sources/Kernel...

You can absolutely write a kernel in Go, many year ago Go used to ship with a bare metal runtime, as a demonstration...

Since the term is not defined anything can be considered a systems programming language.

The Go developers provided their definition, which is something people conveniently ignore whenever they try to be clever about Go not being a systems programming language.

To be fair, if I repurpose a term that is widely used in one way to mean something else, the confusion that ensues is kind of my fault.

So many places I worked had systems engineering department and none of them had anything to do with operating systems/ device drivers. I wonder whether it has to do with OS hackers hanging on internet together and deciding what systems would mean.

There was no repurposing, as the context was exactly explained. Only later, the detractors decontextualized the Go team's original statements.

The lack of control over threading makes it problematic as systems programming language.

Reply on news.ycombinator.com