Hacker News Reader

Comment by vezzy-fnord | Hacker News Reader

It's not going to be displacing low-level programming any time soon, unless radical changes are in store for 2.x and beyond, hypothetically.

That said, I can see it becoming a standard for daemons, utilities and low-level userspace in general due to its rather excellent POSIX and syscall support. I really find the (present) lack of this to be Rust's main deficiency, though the third-party crates are slowly picking up with bindings for things like prctl(), epoll() and so on.

EDIT: Why the downvotes? Rob Pike has stated that he regrets attaching the "system programming" label to Go, since he never intended it for OS kernels and the like. If it's about me being wrong on Rust's POSIX bindings or Go's suitability for daemons, do prove me wrong.

View on HN

Once upon a time that was a programming language called Cedar that was used at Xerox PARC to build an environment for strong typed languages similar to what Smalltalk and Interlisp-D environments offered. It used reference counting with GC for collecting cycles.

A certain swiss guy decided to create a graphical workstation based on the NS32000 processor, using a revised version of Modula-2, with a GC for systems programming, named Oberon.

The Oberon OS managed to provide a fully working graphics workstation capable of fulfilling many tasks at the ETHZ systems programming department. Specially the latest version, System 3 with the GUI Gadgets framework.

It had as descendents EthOS, BlueBottle AOS and its design influenced Plan9's ACME and Rio.

But the world was busy looking into UNIX being adopted by the industry and Oberon is no more.

As I noted regarding Oberon, but you'll have a hard time trying to break the cultural bias against GC.

I learned long time ago that you just need to wait a few programmer generations, than the bias against whatever technology is solved by virtue of nature.

When I started programming, the bias was against any language higher level than Assembly for home computers.

I believe this is why you are getting downvoted:

> It's not going to be displacing low-level programming any time soon, unless radical changes are in store for 2.x and beyond, hypothetically

What radical changes are you referring to, and why are they needed in order for Go to be a de-facto language for system programmers?

Drop the garbage collector. Systems programming cannot stop the world.

You can already do that: http://golang.org/pkg/runtime/

That's not useful for a kernel. You can disable garbage collection in go, but go doesn't provide the tools to disable creating garbage entirely. You can get really close to creating zero garbage through profiling and helping the compiler's escape analysis, but afaik the go spec makes no guarantees about stack vs heap allocation.

> That's not useful for a kernel.

Oberon Kernel.Mod, initial version 11.4.86

http://www.inf.ethz.ch/personal/wirth/ProjectOberon/Sources/...

I failed to see any references to the go runtime package in that link which leads me to believe you misunderstood my statement. Using the APIs documented in the go runtime package to disable garbage collection would not be an effective memory management strategy for a kernel.

The GC is more of a cultural issue than anything (what with Oberon being perfectly fine), but it will have an impact as a result. The runtime will be an overhead, though it does have a malleable library interface, apparently.

Reply on news.ycombinator.com