Hacker News Reader

Comment by tptacek | Hacker News Reader

I've always felt this is one of the better characterizations of Go. Great programming tool. Not an especially great programming language. A lot of the time, more than we acknowledge in PL slapfights, that's what you really want. And, sometimes, being in an efficient but limited language allows you to focus better on your problem domain, which can be useful creatively.

View on HN

On Go-the-language, I agree. It takes a few things from PL design that have widely been shown to be helpful and packages them up in a simple language that C/Java programmers can use to be productive in an hour or so.

The implementation is a different story. It was really goofy to implement a new compiler backend, garbage collector, scheduler, calling conventions, and hey, why not make have the standard library make syscalls directly, what could possibly go wrong? The result has been the last several years has largely been spent reimplementing solved problems (basic compiler optimizations, a GC which is competitive with JVMs from 15 years ago, etc) rather than actually evolving the language.

In short, I wish they'd stuck with their "just do a few things well" philosophy in both language design and implementation.

The compiler backend, till the Go rewrite, had been in production use for ~15 years or so from the top of my head, it's just neither GCC, nor the new hotness LLVM.

Calling convention TBQH is something that often has to be custom in a language outside of interop bits, otherwise you are forced to deal with various C-style brammage. Unfortunately most OSes don't have language-independent interop calling conventions (Windows has COM, VMS has, iirc, SDL, the rest pretty much has nothing), so even if technically there's some official document practically you get stuck with peculiarities of a specific compiler and its relationship with C standard library. Syscalls are about the only safe interface on most unices and the reason why you can make self-standing Go programs that don't bring glibc garbage and random and unexpected shared library dependencies, something that is quite a reason for the following Go gets on container based platforms.

One of Go's features is fast compilation, which wouldn't have been the case if it used LLVM.

> a GC which is competitive with JVMs from 15 years ago

I don't know where you got this impression, but it's absolutely wrong. Go's garbage collector is excellent. It has sub-millisecond pauses [1] (for multi-gig heaps), and it mostly runs in parallel to the application.

You might be referring to Go's old GC, which was dropped when the current was introduced. [2]

[1] https://groups.google.com/forum/?fromgroups#!topic/golang-de...

[2] https://blog.golang.org/go15gc

Go has never been a single implementation language. It had a GCC backend since the start.

GC (Go Compiler) has very peculiar characteristics: for one thing, it's written in Go itself. Another important thing is that it's very fast. That was an objective since the beginning of the Go project.

Finally, comparison with Java GC (garbage collection) are quite nonsense as Go has a very different allocation pattern than Java software.

I would call your comment a better characterization of that "better characterization" :) Says it shorter, and gels with some of what I have experienced, specifically the last sentence. That even works if are you in a less limited language but consciously do not use some of the more advanced features, because you know you don't need them for some work at hand.

Reply on news.ycombinator.com