10 ms·
Go 1.7 toolchain improvements
- hellcow 11y agoI'm glad to see a return to improving compiling speed and binary sizes. Thank you to the Go team!
- manojlds 11y agoCan someone tell me why they went from C to Go despite the huge difference in compilation time?
- folago 11y agoLong story short it's easier to code in Go than C. Here is a more complete explanation https://talks.golang.org/2014/c2go.slide#1 https://talks.golang.org/2014/c2go.slide#1.
- tobik 11y agohttps://golang.org/s/go13compiler https://golang.org/s/go13compiler
- kzrdude 11y agoYou refactor before you improve
- hacker_9 11y agoI'm confused how Go can be paraded as a low level systems language, which improves performance via concurrency, and yet the graph says it's compiler is still over twice as slow as when it was written in C?
- duncanawoods 11y agoIts an irritating dual meaning of "system's language". For Rust, D, C++ and the rest of the world, "systems" implies drivers, OS and embedded systems where low level memory management is key. For the go developers, a system is a web-service so its actually competing with GC languages like node.js and Ruby rather than C.
- danieldk 11y agoBut the D standard library also relies largely on a garbage collector, so it's questionable that it differs much from Go in that respect. As most things, it's a spectrum and not binary. Userland is also part of an operating system and could be written in Go without much trouble. One could also argue that things like Docker are also systems programming. Go is less 'systems programming' than C, C++, or Rust, because it has a garbage collector. Go is more 'systems programming' than Java, C#, node.js or Ruby, because it compiles to native binaries, provides value types (C# does too), integrates more tightly in standard UNIX APIs, etc.
- Sean1708 11y agoFWIU D is actively trying to reduce it's dependence on a GC, while go has decided that the GC is here to stay.
- Ace17 11y agoBTW, as D can call C functions. Thus, in theory, you could choose to use only the C standard library, and use D as a "C with a better syntax". This way, no garbage collector nor any bloat gets linked into your program ... but you still benefit from RAII, templates, array slices, and simplified declaration syntax.
- crawshaw 11y agoYou can write an operating system in a garbage collected language. One example, Oberon System: https://en.wikipedia.org/wiki/Oberon_(operating_system) https://en.wikipedia.org/wiki/Oberon_(operating_system) I don't know anyone who has written more than a toy OS in Go, but it does not seem a fundamentally impossible task. Getting started is harder, because the earliest parts of the kernel would be modifications to the runtime package. Once you get that out of the way, writing drivers could be quite fun. But to the broader topic, I don't have a good definition of "systems language" so I'm not going to claim Go is one. (I work on Go.)
- JoeAltmaier 11y ago
- divan 11y agoIt's not a low-level systems language in traditional view of what "system" is. For Google, "system" is a cloud, not the hardware, so take it from this perspective. By the way, here is a nice video of Q&A session with Alexandresku, Matsakis, Stroustrup and Pike (D, Rust, C++ and Go creators), where they also explain what does 'systems language' mean.
- deleted 11y ago[deleted]
- Philipp__ 11y agoI would like to see that video too...
- leaveyou 11y agohere https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Panel-Systems-Programming-Languages-in-2014-and-Beyond https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Pa...
- charlieegan3 11y agoThink it's this https://m.youtube.com/watch?v=BBbv1ej0fFo https://m.youtube.com/watch?v=BBbv1ej0fFo
- mguillemot 11y agoI think you refer to this video: https://youtu.be/BBbv1ej0fFo?t=3m40s https://youtu.be/BBbv1ej0fFo?t=3m40s (bookmarked at the start of the talk about system programming)
- dawkins 11y agoThis one? https://www.youtube.com/watch?v=BBbv1ej0fFo https://www.youtube.com/watch?v=BBbv1ej0fFo
- divan 11y agoYep!
- deleted 11y ago[deleted]
- SixSigma 11y agowho's parading it as that? Certainly not the Go team https://talks.golang.org/2012/splash.article https://talks.golang.org/2012/splash.article
- kzrdude 11y agoIt was introduced with those words. They have changed since (a long time ago too).
- epoch1970 11y agoAt the very top of the Go web site it used to prominently say "a systems programming language" [1]. [1] https://web.archive.org/web/20091112094121/http://golang.org/ https://web.archive.org/web/20091112094121/http://golang.org...
- suppressingfire 11y ago"It was introduced with those words. They have changed since (a long time ago too)."
- skywhopper 11y agoI don't think the Golang people are parading it as a "systems language". Part of the goal was to make something fast that's both safer and easier than C. I think they succeeded with that. But I don't think anyone expects a language with enforced safety and built-in garbage collection to be faster than C. That just isn't going to be possible.
- myg204 11y ago> Part of the goal was to make something fast that's both safer and easier than C. Right, and also fast compilation. I remember reading the goal was ~20% slower than C for overall performance.
- _ph_ 11y agoIt was auto-translated from C to Go. This means, they replaced well-written C code with badly (unoptimized, nonidiomatic) Go code. The reason was, to guarantee that the initial Go based version was identical to the proven C version. With the releases subsequent to 1.5 the cleanup and enhancement process of the Go version started and now it shows nice results. I think its one really great feature of Go, that the whole build/runtime infrastructure is written in Go itself. So, everyone who is fluent in Go can easily read and possible enhance the infrastructure.
- awinter-py 11y agobig question & fair point. If the system includes the task of its own maintenance (and therefore the developers who work on it), go is faster than C because of maintenance and correctness advantages. (that definition of system is more like 'systems biology' than 'close to the iron software that calls OS APIs'). If golang stays popular the compiler will keep getting faster. Especially because now that it's self-hosting, future improvements will improve compile & runtime perf.
- spriggan3 11y ago- faster compilation times - smaller binaries good job.
- bla2 11y agoFaster compared to 1.6, still much slower than 1.4.
- placeybordeaux 11y agoC is still the king of speed.
- pjmlp 11y agoNot when compared with languages that have modules. In 2000 I worked on a project where "make clean all" would take 1 hour per platform/build type.
- placeybordeaux 11y agoOh I meant in execution, not build time.
- pjmlp 11y agoSimilarly, I remember the days when junior Assembly programmers were able to outperform C compilers for home computers.
- lossolo 11y agoYou can find interesting details to this post in this thread: https://groups.google.com/forum/#!topic/golang-dev/DpMyPbclI3o https://groups.google.com/forum/#!topic/golang-dev/DpMyPbclI...
- RichWalton 11y agoWhat happened between Go 1.4.3 and 1.5 which introduced such a slow down in compile times?
- stefano 11y agoThey rewrote the compiler from C to Go.
- incepted 11y agoWell, at least I bet the compiler compiles itself faster now :-)
- wund 11y agoTo be specific I think they used a transpiler, probably Russ Cox's c2go (https://github.com/rsc/c2go https://github.com/rsc/c2go).
- oconnor663 11y agoWhat's the point of doing that? I get that you want a language to bootstrap itself, but if you skip the experience of actually writing the compiler, and the code you have to maintain is a weird non-idiomatic machine-generated thing, what have you gained?
- raverbashing 11y agoAutomatic translation for most of the code where it doesn't make a difference Then you can get this base and start improving on it
- redtuesday 11y agoMore developers (who don't know c (good enough), but are proficient in go) who can contribute to the compiler code long term (and improve the transpiled compiler). Other reasons would interest me as well.
- verytrivial 11y ago(I went to high school with Dave. Hi, Dave! Signed, misc. Banyule Alumnus)
- tptacek 11y agoIf you're not a Go programmer, bear this in mind: the Go compiler got noticeably slower after 1.4, but it is still extraordinarily fast; "run debounced after every keystroke" fast; "rebuild the world on a whim" fast. Personally, I think the Go community is a little unhealthily obsessed with this particular metric.
- dvirsky 11y agoTo me it's a broken window thing. Go's main mission is to make life easier for me as a developer, and compile times are a big factor in that. If we stopped being obsessed about it, we'd eventually end up with compile times reminiscent of C++.
- awinter-py 11y agoexactly. I don't understand why gerrit's stop & frisk feature is so controversial.
- dilap 11y agoPost 1.4 it went from "don't even think about it" to "mild annoyance". Obviously nowhere near the pain of say C++, certainly something that was missed and will be nice to get back!
- vph 11y ago>Personally, I think the Go community is a little unhealthily obsessed with this particular metric. Let's not forget that Go was invented to solve Google's problems, one of which is it took hours to compile their C,C++ codes. Compile time of Go 1.7, despite the improvement, is still 2x that of Go 1.4.
- ruffrey 11y agoAs someone new to the joys of golang, it is hard to imagine faster compile time or smaller binaries. It just keeps getting better.
- LVB 11y agoit is hard to imagine ... smaller binaries I like Go a lot, and I don't fret about binary size. But let's not be too charitable :). The CLI apps I write usually start trending towards 10MB with a few package imports. Their equivalents in C are usually less than 100k. One can imagine getting to better than a 100x difference.
- giovannibajo1 11y agoGo binaries are static, with no external dependencies. You can't win that battle.
- andreynering 11y ago> it is hard to imagine ... smaller binaries > I like Go a lot, and I don't fret about binary size. But let's not be too charitable :). The CLI apps I write usually start trending towards 10MB with a few package imports. Their equivalents in C are usually less than 100k. One can imagine getting to better than a 100x difference. Who want smaller binaries can use this compressor tool: http://upx.sourceforge.net/ http://upx.sourceforge.net/ It may be a bit slow but you just need to use it in the distributed version.
- icebraining 11y agoThat only saves disk space, though, not memory.
- sfifs 11y agoWell.. the C binaries depend on libc on your system and come with no type safety and automatic garbage collection. Go binaries are fully static (except for networking typically and you can switch that to static as well).
- montyedwards 11y agoThe only thing preventing me from using Go on Windows is lack of production quality cgo on Windows x86 and x64. For example, using external linking should "just work" with recent versions of sqlite3 but it fails on Windows.
- xrstf 11y agoI had no problems building go-sqlite3[1] on Windows 7 x64 using the toolchain provided by the Win-Builds project[2]. It's using gcc 4.8 and sqlite 3.10, so maybe that doesn't hit your meaning of "recent versions". It was certainly recent and easy enough for my needs :) [1] https://github.com/mattn/go-sqlite3 https://github.com/mattn/go-sqlite3 [2] http://win-builds.org/ http://win-builds.org/
- montyedwards 11y agoI tried TDM-GCC. In my experience, certain aspects increase risks when using go: 1. go is buggier for Windows than Linux and FreeBSD, even though they are all "first class" platforms in go. 2. cgo is also buggier for Windows than Linux and FreeBSD. cgo is not go, as Rob Pike said, so this is listed separately. 3. 386 was buggier than x64, at least in go 1.2 to 1.3 on Windows. I wish I could ignore 386 and XP but I cannot. So if a project includes all of the above aspects, well...it wasn't a good outcome for me, so I ended up sticking with C and C++ on Windows for non-hobby software. However, I've been very happy with go 1.4.3 + cgo + x64 on FreeBSD 10 and will probably update to go 1.6 or 1.7 within a year. Regarding go on Windows, I'm hoping to see go-sqlite3 issue #272 resolved: https://github.com/mattn/go-sqlite3/issues/272 https://github.com/mattn/go-sqlite3/issues/272 And go issue #14397 cmd/link, runtime: panic "invalid spdelta" with -ldflags="-linkmode internal" And go issue #10776 cmd/link: windows cgo executables missing some DWARF information And go issue #12516 runtime: throw in linked c++ library causes app crash even if caught, on windows platform And so on... I really love using go (with cgo) on non-Windows platforms, but I can't see this combo being useful on Windows for mission critical projects for a while. There's so much more to go than the language itself and switching gears to use other languages that don't offer that is painful. Maybe LXSS.sys will eventually make this irrelevant -- at least for companies that migrate from older versions to Windows 10 or to a non-Windows OS.
- munificent 11y agoThere's something vicariously gratifying about posts like this. Optimization is some of the most fun programming to do: you have a crystal clear objective goal to go for and once you've got a profiler set up it's just: 1. Find slow thing. 2. Make faster. 3. See benchmark improve. Some of the most satisfying coding I've done has been optimization.
- steveklabnik 11y agoI agree with this, but there's one more aspect: you learn something. Deeply. "Oh, I didn't realize that would do _that_..." It's also taught me just how much we can guess incorrectly the first time. It's a skill you can get better at. "Profile first" is a good heuristic, but "guess first, profile second, _then_ do the work" means you train yourself too. I'm still very much a noob at this.
- munificent 11y agoI think every time I've used a profiler, it's taught me that me intuition of where the bottleneck was was completely wrong. It's a humbling experience, in a good way.
- golergka 11y agoWell, that's only satisfying when your other thing doesn't get slower/worse because of that. And then turns out you're out of low-hanging optimization fruit and you have to choose trade offs.
- arktisklada 11y agoAs an avid go user, I'm excited about these improvements, especially the garbage colleciton