31–40 of 71 posts
This is one of Go's best features for me. You can trivially cross-compile statically linked binaries, copy them over to an ARM system and they run fine. Contrast that with C/C++ - sure you can cross-compile, and I have in the past, but it's a huge pain to set up and who ever remembers the command line options. Those "target triples" aren't even documented anywhere. Plus, good luck building a statically linked C++ pro…
Earlier quoted context omitted.
Compilation in Go remains lightning fast, again, faster than any other compiler I use; fast enough that it's sane to run the compiler every time I save a file so my editor can highlight the errors.
I think there are two schools of thought: 1) Perf for a product should be marked against some shipping benchmark and intermediate regressions don't matter as long as we come below the benchmark at ship time. 2) Perf improvements should be "locked in" and not regressed, unless strenuously justified. I think the parent is of group (2), where it doesn't necessarily matter that it's better than the benchmark of "against…
If the developers take a specific principled stance against $really_useful_feature on account that it would introduce complexity and thus degrade performance, then compromise this same principle in order to accomplish $entirely_unnecessary_port, it put the obvious lie to their avowed principles.
I don't mind that go compiles more slowly. To Thomas's point, it's still really fast. What I mind is that a good portion of the go community has accepted the lack of generics on the basis of principles that they haphazardly violated in order to scratch the useless but fun intellectual itch of bootstrapping the compiler.
Now that they've done this, they have revealed themselves to be entirely dishonest about their complexity/performance principles, and now the one legitimate objection that has kept generics out of the language has nothing to stand on.
Again, I don't care about performance per se, I care about dishonesty and hypocrisy in the platform's objectives.
Earlier quoted context omitted.
Why is that a problem for you? With golint / gocode I never have any need for extremely fast compilation. What's your setup like that you're rebuilding so often?
Personally, my biggest beef would be that the go developers specifically stood against generics on account of compiler complexity => slow compiling. It seems they accepted this sacrifice for some other unimportant feature* *edit: Looks as though the feature they sacrificed performance for was writing Go in Go.
Writing Go in Go is a huge feature, not an unimportant feature.
Writing the runtime in Go means we write the runtime in a much safer language. We found and fixed lots of bugs just by rewriting the runtime. Everybody, every user benefits from this tremendously.
Writing the runtime in Go means you can have a precise garbage collector. Every user of Go benefits from this tremendously.
Writing the runtime in Go means the runtime implementation becomes in many respects simpler, because there are no longer complex C-Go interactions (the Plan 9-derived C compiler used a slightly different calling convention!). This again reduces bugs and makes debugging easier. Everybody wins.
Writing the runtime in Go means there's one less custom compiler to maintain (no more Plan 9-derived C compiler!). Less maintenance means more time available for more important things. Also this simplifies new ports. Again, everybody wins.
Writing the compiler in Go means you can have a compiler that's not written in a language that sucks for writing compilers. Because writing compilers is now easier and consumes less time, there's more time available for more important things. Everybody wins.
Writing the compiler in Go means you benefit from all the tooling built for Go. This includes source code transformation tools. Automatic refactoring is very easy to do in Go because you have Go parsers in the standard library. This is not merely hypothetical, it's something that's actually used. The end result is that changing the compiler is faster, again allowing more work to be done.
Writing the compiler in Go also means the compiler can eventually become an idiomatic Go program that can be understood by Go programmers instead of being a ken-idiomatic C program that can only be understood by a few people. More people can work on the compiler. More work is being done as we speak, including work that will make generated code much faster. Everybody wins.
Writing the compiler in Go means you don't depend on million of lines of C++ toolchains in order to exist. As a Go compiler writer this has simplified my life a lot. I can compile the Go distribution in under a minute. On my phone. Which is 5 years old. Last time I tried to compile LLVM it died with a compile error after 6 (six!) hours.
Writing the compiler in Go means I can have fun while writing compilers for fun, so you benefit because I write it. Everybody wins.
I've written three compiler targets by now, one in C and two in Go. I don't plan to stop because I like what I am doing, but I'm not sure I would continue to do it if it were still written in C. People benefit from this not only by having more toys to play with, but new ports mean more comprehensive testing and new bugs found. Different platforms exercise different bugs differently, bugs which are present on all platforms.
Also the actual work done on the ports stimulates further refactoring efforts that will make Go even easier to port in the future. Again everybody wins! And it's only because this "unimportant feature" that is not even visible to most users of Go, coupled with the powerful refactoring technology which makes this possible.
Earlier quoted context omitted.
Go already has 2 compiler implementations. There is gc (Go Compiler) and gccgo[0]. [0] https://golang.org/doc/install/gccgo
But LLVM already has a lot of good backends (emscripten, arm, ppc, x86, amd64). Why reinvent the wheel when you could just make Go a LLVM frontend and be done with it?
That would be my hunch. I think it makes a lot of sense. Also, note that there is that project which exists : http://llvm.org/viewvc/llvm-project/llgo/
Earlier quoted context omitted.
But LLVM already has a lot of good backends (emscripten, arm, ppc, x86, amd64). Why reinvent the wheel when you could just make Go a LLVM frontend and be done with it?
Compile times ? Flexibility over the backend ? That would be my hunch. I think it makes a lot of sense. Also, note that there is that project which exists : http://llvm.org/viewvc/llvm-project/llgo/
There can be a compile time hit, but you can use FastISel, which is not bad. The compile time hit is mitigated by the fact that you get a far, far more mature series of optimization passes. Since the Go compiler is itself written in Go, more optimizations would make the Go compiler itself faster, further reducing the performance impact.
> Flexibility over the backend ?
Writing to LLVM in no way restricts you to a backend. You simply need a language-level IR that you can retarget to different backends as you would like. This is what Swift, for example, is doing with SIL.
Earlier quoted context omitted.
I do nightly binaries for Prometheus in all the possible archs, while things should compile perfectly there can be small things that prevent things from cross-compiling. darwin/arm, darwin/arm64, plan9/386, plan9/amd64 and solaris/amd64 don't compile for any of the 11 binaries (e.g. plan9 doesn't work due to logrus not having support for it). This leaves me with the list at http://www.robustperception.io/prometheus-n…
What is the problem with solaris/amd64?
The logrus library we use for logging doesn't support Solaris.
Earlier quoted context omitted.
I think there are two schools of thought: 1) Perf for a product should be marked against some shipping benchmark and intermediate regressions don't matter as long as we come below the benchmark at ship time. 2) Perf improvements should be "locked in" and not regressed, unless strenuously justified. I think the parent is of group (2), where it doesn't necessarily matter that it's better than the benchmark of "against…
Group (3), of which I am a member: If the developers take a specific principled stance against $really_useful_feature on account that it would introduce complexity and thus degrade performance, then compromise this same principle in order to accomplish $entirely_unnecessary_port, it put the obvious lie to their avowed principles. I don't mind that go compiles more slowly. To Thomas's point, it's still really fast. Wh…
This is one of Go's best features for me. You can trivially cross-compile statically linked binaries, copy them over to an ARM system and they run fine. Contrast that with C/C++ - sure you can cross-compile, and I have in the past, but it's a huge pain to set up and who ever remembers the command line options. Those "target triples" aren't even documented anywhere. Plus, good luck building a statically linked C++ pro…
What about LLVM? Go's support of cross compilation is laughable in comparison to the different LLVM backends. And you can just use the -arch armv7 and -arch arm64 shortcuts instead of those target triples. Also, FWIW, the reason why Go can even be cross compiled in the first place is because it has platform specific C and assembly code from cgo's runtime so it can support the different architectures/platforms. Of cou…
Earlier quoted context omitted.
In the global scheme of things it's still pretty fast, but builds on 1.5 take 2x the time of 1.4, it's pretty bad for existing golang users.
Why is that a problem for you? With golint / gocode I never have any need for extremely fast compilation. What's your setup like that you're rebuilding so often?
Earlier quoted context omitted.
I think there are two schools of thought: 1) Perf for a product should be marked against some shipping benchmark and intermediate regressions don't matter as long as we come below the benchmark at ship time. 2) Perf improvements should be "locked in" and not regressed, unless strenuously justified. I think the parent is of group (2), where it doesn't necessarily matter that it's better than the benchmark of "against…
Group (3), of which I am a member: If the developers take a specific principled stance against $really_useful_feature on account that it would introduce complexity and thus degrade performance, then compromise this same principle in order to accomplish $entirely_unnecessary_port, it put the obvious lie to their avowed principles. I don't mind that go compiles more slowly. To Thomas's point, it's still really fast. Wh…
Absolutely nobody in the universe promised you generics in Go. You may never, ever get them; the longer the language thrives without them, the less urgent they seem.