4 ms·

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/Jav

by gok 8y ago

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.

dullgiulio 8y ago
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.
zippoxer 8y ago
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-dev/Ab1sFeoZg_8 https://groups.google.com/forum/?fromgroups#!topic/golang-de... [2] https://blog.golang.org/go15gc https://blog.golang.org/go15gc
p_l 8y ago
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.

by gok 8y ago

dullgiulio 8y ago

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.

zippoxer 8y ago

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-dev/Ab1sFeoZg_8 https://groups.google.com/forum/?fromgroups#!topic/golang-de... [2] https://blog.golang.org/go15gc https://blog.golang.org/go15gc

p_l 8y ago

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.