This is great! I can now unify a lot of my workflow and not have to use ruby as a glue layer between applications and operations. It's great to see the Go ecosystem improving! I think in a few years, it may become the defacto tool of systems programmers.
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.
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.
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.
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.
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.
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.
Frankly go isn't my favorite glue language (and I'm one of the relatively few people who's been doing go full time for a couple years). I currently prefer python for that kind of stuff, or sometimes bash.
However it's certainly possible to use as a glue language. I've talked to some folks at DO who just install go on machines and `go run` scripts.
For small internal projects, I typically find that I end up writing the program and compiling it; It just builds up my developer toolchain from the command line to do my bidding. Also, these are all managed under source control, so my co-workers can also take advantage.
I'm going to go out on a limb and say that probably isn't true. All go at DigitalOcean is deployed using one of two mechanisms. Nothing is `go run` outside of a developer's workstation.
