Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“This change deletes the C implementations of the Go compiler and assembler”

github.com

Post reply on HN
Print view View original

91–100 of 137 posts

Re: “This change deletes the C implementations of the Go compiler and assembler”

#91

Post by arcticbull »

I 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.

Re: “This change deletes the C implementations of the Go compiler and assembler”

#92

Post by cperciva »

indians_pro wrote: post #87
cperciva wrote: post #84

Earlier quoted context omitted.

You mean, audit a large number of independently-written Go compilers?

Nicely done. To be fair though, Go is just 6 years old and still evolving.

Exactly. Which is why I think it's important to keep the option of compiling its compiler from a language which has a large diversity of compilers.

Re: “This change deletes the C implementations of the Go compiler and assembler”

#94

Post by dsymonds »

arcticbull wrote: post #91

I 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:…

What'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.

Re: “This change deletes the C implementations of the Go compiler and assembler”

#95

Post by arcticbull »

dsymonds wrote: post #94
arcticbull wrote: post #91

I 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:…

What'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 p…

I 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.

Re: “This change deletes the C implementations of the Go compiler and assembler”

#96

Post by dsymonds »

arcticbull wrote: post #95
dsymonds wrote: post #94

Earlier quoted context omitted.

What'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 p…

I 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 i…

Yes, that's why there's both gc and gccgo (llgo came later). Apart from the rigour of having two independent compilers, they are seeking different tradeoffs. gc is very interested in running fast, and gccgo benefits from decades of work that have been put into gcc's various optimisations.

Does that answer your original statement that you didn't understand why we build our own toolchain?

Re: “This change deletes the C implementations of the Go compiler and assembler”

#97

Post by uxp »

humbledrone wrote: post #88
Vecrios wrote: post #83

So, 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!

My 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 in…

Its 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

[2] http://blog.llvm.org/2010/02/clang-successfully-self-hosts.h...

Re: “This change deletes the C implementations of the Go compiler and assembler”

#98

Post by bpicolo »

foz wrote: post #85
ngoldbaum wrote: post #16

Wow, github doesn't handle big diffs well. Some sort of automatic pagination would really help.

Github handles it well, but our browsers don't. It would be nice if they loaded large diffs progressively, as you scroll.

Github is a website, it's it's job to make the browser handle it well.

Re: “This change deletes the C implementations of the Go compiler and assembler”

#99

Post by bdarnell »

arcticbull wrote: post #91

I 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:…

The Go team does want to innovate on the toolchain. A key factor in the design of Go is the belief that once a language is "good enough", developers are better served by a superior toolchain (and specifically faster compilation) than by a fancier language. They want to own the toolchain so they can optimize it for Go and make their own tradeoffs about speed versus features.

Re: “This change deletes the C implementations of the Go compiler and assembler”

#100

Post by chimeracoder »

dsymonds wrote: post #94
arcticbull wrote: post #91

I 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:…

What'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 p…

> 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).

For any non-Gophers reading this: I write Go as my primary language, and have for the past two and a half years. I just timed the respective compilation speeds on a handful of my larger projects using both gc and gccgo (and tested on a separate computer as well just for kicks).

gccgo was marginally slower, though not enough to be appreciable. In the case of two projects, gccgo was actually slightly faster. The Go compiler/linker/assembler/stdlib are probably larger and more complex than the most complex project on my local machine at the moment, but I think my projects are a reasonable barometer of what a typical Go programmer might expect to work with (as opposed to someone working on the Go language itself).

The more pressing issue as far as I'm concerned is that gccgo is on a different release schedule than gc (because it ships with the rest of the gcc collection). That's not to say it's not worth optimizing either compiler further when it comes to compilation speed, but it's important for people considering the two compilers to understand the sense of scale we're talking about - literally less than a second for most of my projects. Literally, the time it takes you to type 'go build' is probably more significant.

Post reply on HN