9 ms·
“This change deletes the C implementations of the Go compiler and assembler”
- deleted 12y ago[deleted]
- pjmlp 12y agoGreat news!
- deleted 12y ago[deleted]
- skippy81 12y agoVersion control ftw!
- jvreeland 12y agoyou'll still be able to see it if you check out an earlier version.
- deleted 12y ago[deleted]
- andrewchambers 12y agoGit gives you access to all revisions for ever.
- justincormack 12y agoSo what is the bootstrap process going to be? Other than already have a Go compiler I mean. Or is it have a Go cross compiler? Maybe it matters less, you used to always assume bootstrap from C but that more or less died with C++ based compilers, although you can do a multistage bootstrap from the last gcc before C++ still.
- ori_b 12y agoEither cross compile, or get the last C-based Go compiler, and use that to build the more recent Go releases.
- yiyus 12y agoIt is explained in the design document: https://docs.google.com/document/d/1P3BLR31VA8cvLJLfMibSuTdwTuF7WWLux71CYD0eeD8/edit https://docs.google.com/document/d/1P3BLR31VA8cvLJLfMibSuTdw... Basically, you start from the last C version, and every version is supposed to be able to compile the next one.
- justincormack 12y agoAh ok, so there will be a pretty long chain from 1.2 eventually, but hopefully it will be part of the test suite...
- jlouis 12y agoUsually you don't keep the chain. You just keep a working compiler. You can also bootstrap from another implementation of the language, e.g., gccgo. A common trick is to keep a highly portable interpreted version of the target language and then use this for bootstrapping, but often you attack new architectures by cross-compilation instead. It all depends. Also, it is common for self-hosting languages to require themselves to build.
- enneff 12y agoYou should always be able to build a Go 1.x compiler with just the 1.4 tool chain binaries. We have committed to sticking to the Go 1.4 language and libraries for the compiler tool chain.
- TheLoneWolfling 12y agoWhere is this fact documented? Are patches tested against 1.4 tool chain binaries?
- madhusudancs 12y agoHere https://docs.google.com/document/d/1OaatvGhEAq7VseQ9kkavxKNAfepWy2yhPUBs96FGV28/edit https://docs.google.com/document/d/1OaatvGhEAq7VseQ9kkavxKNA... In the proposal section.
- burnte 12y agoBut if one has access to the Go compiler source, is it not a reasonable guess that one would be able to access a go compiler binary from the same trusted source? I just don't see this as a problem since it is impossible to build a computer from the ground up without trusting a lot of software first.
- dmm 12y agoProbably gccgo, which is included in gcc.
- dmm 12y agoFor the purposes of bootstrapping.
- cbd1984 12y ago> So what is the bootstrap process going to be? Other than already have a Go compiler I mean. Or is it have a Go cross compiler? What's the bootstrap process for the C compiler part of the compiler?
- 4ad 12y agoThe is no C code in the compilers anymore.
- deleted 12y ago[deleted]
- smegel 12y agoAnd the boy pulled up his bootstraps and became a man.
- gresrun 12y agoOnce you go Go, you never Go back!
- bsummer4 12y agoThen, clearly, the right path is to never go Go.
- deleted 12y ago[deleted]
- bcantrill 12y agoOne does wonder if the register re-naming from their abstract (but misleading) names to their proper machine names (e.g., from "SP" to "R13") wasn't at all a reaction to the (in)famous polemic on the golang build chain.[1] [1] http://dtrace.org/blogs/wesolows/2014/12/29/golang-is-trash/ http://dtrace.org/blogs/wesolows/2014/12/29/golang-is-trash/
- davecheney 12y agoNo, this was unrelated. SP, PC and FP are virtual registers, from the POV of the assembler. On _some_ architecture those words have real meanings, like RSP on intel, but on others they are just conventions. I don't think Keith's rage quit has had a measurable impact on the direction of Go or its toolchain.
- comex 12y agoAside from what the other reply to your comment said, using R13 and R15 is actually a move away from standard notation: even though those do correspond to SP and PC, the ARM architecture manual as well as all assembly code I've seen uses the special names for those registers.
- pjc50 12y agoThat's a classic of the "too rude and opinionated to salvage anything reasonable" genre right there.
- rsc 12y agoSP, FP, and PC are all still there. What we did was make the conventions more uniform across all architectures. The rules for certain corner cases for when SP and PC were references to the virtual register and when they were references to the real register were inconsistent. As part of having a single assembly parser, we made the rules consistent, which meant eliminating some forms that were accepted on only a subset of systems, or that had different meanings on different systems. I'm a little surprised you brought that post up to begin with. It completely misses the point, as I explained in my comment here at the time (https://news.ycombinator.com/item?id=8817990 https://news.ycombinator.com/item?id=8817990). When I wrote that response I also submitted a comment on the blog itself with a link to the HN comment. That blog comment has not yet been published. If you're going to keep sending around links to such an inflammatory blog post, could you also try to get my comment there approved? Thanks.
- brandonwamboldt 12y agoCongrats to the Go team, but that link kills the browser....
- davecheney 12y agoYou can read the original commit on Gerrit, it's less explodey. https://go-review.googlesource.com/#/c/5652/ https://go-review.googlesource.com/#/c/5652/
- ngoldbaum 12y agoWow, github doesn't handle big diffs well. Some sort of automatic pagination would really help.
- deleted 12y ago[deleted]
- cratermoon 12y agoI would make the case the "big" diffs are a problem. Unless there's a really good reason (and bad dependency management is not a good reason) then commits should be smaller and more logically related.
- serf 12y agoWhile I agree that a big diff isn't a good idea, I disagree with the notion that one should develop in such a way that makes Github (or whatever VCS you're using) work right. I don't think working within the capabilities of the VCS you're using should ever be a priority for a software development effort; rather I think the VCS's priority should be to allow for their use within most contexts of software development. (the other way around)
- kasabali 12y ago" This change deletes the C implementations of the Go compiler and assembler from the master branch." is logically related as it could be. Everybody has a different interpretation of it, I guess.
- rcthompson 12y agoThis is a merge commit, which means the diff is going to include all the changes on the branch being merged. Even if all the individual commits are small, a merge diff can still be very large.
- teraflop 12y agoIt's a merge commit, so naturally it's going to have a huge diff even if the actual work was done in much smaller increments.
- bketelsen 12y agoRSC is awesome.
- davidrusu 12y agoAnyone else seeing this post as the 1st and 2nd link on the front page of HN?
- nicklovescode 12y agoyes
- icebraining 12y agoYes! And with different points, too.
- ramidarigaz 12y agoLooks like they diverged. Lots of duplicate comments. Edit: Nope. All comments show on both.
- 0x0 12y agoThe comment links are in fact the same: https://news.ycombinator.com/item?id=9097404 https://news.ycombinator.com/item?id=9097404
- rosser 12y agoYes. With the same URL for both discussion and article, though with differing scores and comment counts.
- morloch 12y agoSo they finally gave up?
- joeld42 12y agocongrats gophers! That's a big step for the language.
- shjfalkdjsa 12y agotest
- davexunit 12y agoHere we go again. Another compiler that can't be bootstrapped from source code. It's a packaging nightmare. Another magic binary to trust not to have a Thompson virus.
- chimeracoder 12y ago> Another compiler that can't be bootstrapped from source code. It can be bootstrapped from source - it just needs to be bootstrapped either using gccgo[0], or using the 1.4 compiler (which is guaranteed to work for all 1.x compilers, not just 1.5) > Another magic binary to trust not to have a Thompson virus. "Reflections on Trusting Trust" gets posted on HN regularly, and it's an interesting exercise, but you are far more likely to have an exploit hiding in plain sight in a compiler compiled from source once than you are to have one that only appears after multiple iterated compilations. It's a good concept for security experts and compiler developers to be aware of, but the likelihood is incredibly small. Also, for what it's worth, "Trusting Trust" is over three decades old, and there have been numerous response to it in the interim, with lots of study. It's like saying "Your problem reduces to 3-SAT, and satisfiability is NP-hard, so you can't solve it', throwing your hands up, and leaving it at that. In reality, solving 3-SAT in the general case is NP-hard, but it is well-studied enough that, in practice, solving SAT/3-SAT is actually pretty easy most of the time. Some of these responses have even been posted elsewhere in this thread, though they're also pretty easy to find online as well. [0] which is written in C++ - frankly, I'd be much more concerned about a single-compilation bug in any C++ code than I'd be about a multiple-compilation bug in Go.
- nullc 12y agohttp://www.dwheeler.com/trusting-trust/ http://www.dwheeler.com/trusting-trust/ < David A. Wheeler’s Page on Fully Countering Trusting Trust through Diverse Double-Compiling, for an example. Though the diversity available for a go compiler written in go isn't very tremendous.
- tbolt 12y agoSo this means the go compiler is completely written in go?
- dsymonds 12y agoIn source control, yes. There's not yet a stable release where that's the case though; Go 1.5 (due later this year) will be that release.
- Animats 12y agoNice. That's a step forward. Another bit of legacy code bites the dust. Another step forward to the post-C world we need. (If you want to compile with a different compiler as a check, there's an LLVM-based compiler for Go.)
- gillianseed 12y agoGo is also supported in GCC, as GccGo.
- Vecrios 12y agoSo, if I'm understanding this correctly, they are to re-write the Go compiler in Go, and compile it using the currently published compiler (i.e. 1.4)? Could someone, kindly, explain how future versions would be built? Thanks!
- humbledrone 12y agoMy understanding is that they wrote code that translated the C code for the original Go compiler into Go code. This translation wasn't fully general -- it made assumptions about how the C code was written -- but it allowed the port from C to Go to be very precise (i.e. bug for bug). So now that the Go compiler written in Go can compile Go, that's what they'll use going forward, and they will slowly work to make it into more idiomatic Go instead of machine-generated Go. So to answer your question, this new Go-written-in-Go compiler will initially be compiled by the Go-written-in-C compiler. The output from that will be an executable Go-written-in-Go compiler, and _that_ will be used to compile itself in the future. I.e. Go compiler version 1.4 will be used to compile Go version 1.5 will be used to compile Go version 1.6... Keep in mind that this is not at all unusual. The C compiler GCC has been compiled using older versions of GCC for a long time. Having a compiler compile itself is a sort of milestone that many languages aspire to as a way of showing that the language is "ready."
- uxp 12y agoIts generally called "self-hosting" when a compiler can compile itself[1]. It was a pretty big deal when Clang became self-hosting[2] in 2010. [1] https://en.wikipedia.org/wiki/Self-hosting https://en.wikipedia.org/wiki/Self-hosting [2] http://blog.llvm.org/2010/02/clang-successfully-self-hosts.html http://blog.llvm.org/2010/02/clang-successfully-self-hosts.h...
- Vecrios 12y agoThank you both for your inputs.
- dsymonds 12y agoFuture versions will still be built with any current published compiler. There are binary releases for each major release, and it's not hard to avoid using new language features in the compiler, so building from source only requires the most recent binary release (at worst).
- arcticbull 12y agoI still just don't understand why they insist on building their own toolchain. It just doesn't make sense to me. When you set out to build a programming language, what is your objective? To create a sweet new optimizer? To create a sweet new assembler? A sweet new intermediate representation? AST? Of course not. You set out to change the way programmers tell computers what to do. So why do this insist on duplicating: (1) An intermediate representation. (2) An optimizer. (3) An assembler. (4) A linker. And they didn't innovate in any of those areas. All those problems were solved with LLVM (and to some more difficult to interact with extent GCC). So why solve them again? It's like saying you want to build a new car to get from SF to LA and starting by building your own roads. Why would you not focus on what you bring to the table: A cool new [compiler] front-end language. Leave turning that into bits to someone who brings innovation to that space. This is more of a genuine question.
- dsymonds 12y agoWhat's your counter-proposal? If you're building a new language, you need a new AST. You can't represent Go source code in a C++ AST. There are alternate compilers for Go, in the form of gccgo and llgo. But those are both very slow to build (compared to the Go tree that takes ~30s to build the compiler, linker, assembler and standard library). And the "gc" Go compiler runs a lot faster than gccgo (though it doesn't produce code that's as good), and compilation speed is a big part of Go's value proposition.
- arcticbull 12y agoI would never set out to build a language I wanted people to use and not build it as a front-end for LLVM. I don't want to write an optimizer or assembler. I don't doubt for one second that llgo takes a longer time to compile. And in exchange for slower compile times you benefit from many PHDs worth of optimizations in LLVM. And every single target architecture they support. It's easy to build something faster when it does less. I'll admit there's no blanket right answer to that tradeoff.
- dsymonds 12y ago