Porting the Go compiler to Go [LWN.net]

Porting the Go compiler to Go

Posted Apr 26, 2014 3:25 UTC (Sat) by Kit (guest, #55925) [Link] (2 responses)

Wouldn't you be able to just cross compile Go in that situation?

Porting the Go compiler to Go

Posted Apr 26, 2014 13:37 UTC (Sat) by fishface60 (subscriber, #88700) [Link] (1 responses)

It's simpler to cross-compile the minimum set of packages, then build the rest natively.

If you only have to deal with cross-compiling the C compiler you can focus all your effort on dealing with the changes involved in the new version of the C compiler, or new architecture.

The Go compiler can then work out what architecture it needs to target from what it's currently running on, which is much less manual effort, as it can detect that automatically.

Porting the Go compiler to Go

Posted May 1, 2014 23:58 UTC (Thu) by Comet (subscriber, #11646) [Link]

Go is inherently a cross-compiler. Every build is a cross-compile. You set an couple of environment variables to adjust the build target, and if the standard library has been installed as a privileged user, you'll need to make sure that's redone as a privileged user (or say "screw it" and run with a user install of Go).

Go's is the cleanest cross-compilation experience I've ever had, and the nearest competition is NetBSD's setup.

Porting the Go compiler to Go

Posted Apr 26, 2014 3:44 UTC (Sat) by iabervon (subscriber, #722) [Link]

When porting a compiler to a new architecture, you generally cross-compile initially rather than bootstrapping. That is, you add code generation for your new architecture to your existing Go compiler written in Go, compile it for x86_64 with your existing x86_64 binary, compile it for your new architecture with the compiler from the previous step, install the compiler from the previous step on your new machine, and optionally compile it a final time on the new machine, to see if the generated code for the new architecture actually works. No need to use code in any other language in this process (aside, possibly, from some low-level routines you might want to write in assembly and link in rather than having your code generation emit a constant chunk of code).

Porting the Go compiler to Go

Posted Apr 26, 2014 14:36 UTC (Sat) by HelloWorld (guest, #56129) [Link] (5 responses)

> Could you explain the problems you think Go has in more detail? I haven't looked at it yet and it sounds like I shouldn't?
The problem with Go is that it isn't nearly ambitious enough. I think that the programming language should help the programmer to express invariants about the program, and the way to do that is through the type system. Go has embarassingly little to offer here. Very basic functions like map (apply a function to every element in a list and return the list of the resulting values) or filter (apply a predicate to every function in a list and return the list of those where the predicate holds) can not be expressed in a generic, type-safe way due to the lack of parametric polymorphism (aka generics). They also lack sum types (aka tagged unions), which are extremely useful for error handling among others. These concepts were understood decades ago, they're nowhere near revolutionary or controversial. Go's interface mechanism is sort of neat, but it's also not innovative, you can get that (and a lot more!) in, say, Ocaml. And there are so many other areas where significant progress was made in the last decades, like module systems (look at what ML has had for decades) or syntax (even Algol's syntax was better than Go's, Lisp has had proper macros since the 1960s). Basically, whatever part you look at, Go is several decades behind the state of the art.

What makes it actively evil is that it is nevertheless a significant improvement upon C and yet very easy to pick up for a C programmer. That sounds like a good thing at first, but it's not. It makes C programmers switch to Go because it really is less painful to program in, but they don't realize that they could get so much more out of a programming language if they were prepared to walk off the beaten paths. And that's what makes me think that it'll throw computing back by decades if it gains a significant amount of traction.

Porting the Go compiler to Go

Posted Apr 26, 2014 22:35 UTC (Sat) by mathstuf (subscriber, #69389) [Link] (3 responses)

I don't know about C, but C++ devs (the original target audience) seem to just be ignoring Go for the most part (as I am). Probably due to the lack of generics. Go has been more successful among Python and Ruby devs. Probably because losing generics is worth static typing[1].

[1]It's a tough tradeoff, but I think I'd go with static typing given the exclusive disjunction between the two.

Porting the Go compiler to Go

Posted Apr 27, 2014 16:41 UTC (Sun) by Nelson (subscriber, #21712) [Link] (1 responses)

I ignored it at first too, largely due to the specs.

Give it a spin, seriously, the simplicity of it is part of what makes it fun to use. It's simple, lean, clean, easy to pick up and it is fun to use. Just enough safety.. Once you've committed to C++ or for that matter Java or a lot of other modern dynamic languages, you've had to pick up so much BS that doesn't get your problem solved faster or better, just little details and nuances. There really isn't that much nuance to Go and when you get used to it, it is a beautiful thing.

Porting the Go compiler to Go

Posted Apr 27, 2014 16:56 UTC (Sun) by mathstuf (subscriber, #69389) [Link]

I probably should. See how many times I needs to write filter and map before I wish I had Boost ;) .

Porting the Go compiler to Go

Posted May 7, 2014 21:31 UTC (Wed) by cmccabe (guest, #60281) [Link]

I think projects that are sticking with C++ are doing it for one of two reasons:
1. Inertia. Remember, C++ was a hot new language when Ronald Reagan was president. For all the usual reasons, big old codebases don't get rewritten very often.
2. Fear of garbage collection. Most of the C++ projects that wanted the benefits of garbage collection already jumped ship for Java back during the Java craze of the late 1990s.

Unfortunately, garbage collected, statically-typed languages have become synonymous with Java in the minds of many C++ developers. It's a shame, because Go doesn't have a lot of the limitations of Java. Java programs take a few seconds to start; Go programs start instantly. Java requires you to set up CLASSPATH; Go just requires you to run a static binary. Java requires you to write clumsy and awkward JNI shims to interface with native code; go has cgo which allows you to put C code inline inside .go files in just a line or two. Java doesn't support unsigned numbers; go does.

More fundamentally, the way the languages manage memory is different. Java fundamentally doesn't have value types, only references (*). What this means in practice is that if you have object Foo containing objects Bar and Baz, you need to allocate Bar and Baz separately, and put references to them inside Foo. This means that you have at least 8 bytes of extra overhead per-object compared to a language like Go, which just lets you put Bar and Baz inside the allocation for Foo. When you add in stuff like non-static classes, RTTI overhead, and so on, the per-object overhead in Java is actually quite high. And this matters a lot in modern architectures, where the CPU can do quite a lot in the time it takes to fetch values from main memory.

There are some projects out there that genuinely might benefit from managing memory manually. But I'm skeptical that this overlaps much with the set of projects that also need a language higher-level than C. Time will tell, I guess. The fact that people are getting angry about Go is a good sign, like when people were criticizing UNIX for being too popular and successful compared to VMS and Lisp machines.

* For the pedants out there: yes, Java supports value types for ints and other primitives. This is why you often see horrifying hacks where people create an array of ints and start passing it around and interpreting it in various ways.

Porting the Go compiler to Go

Posted Apr 28, 2014 10:51 UTC (Mon) by k3ninho (subscriber, #50375) [Link]

>[This] makes me think that it'll throw computing back by decades if it gains a significant amount of traction.

All of these great language features will trickle their way down to the lowest common denominator programming languages, so that in, say C72[1], there will be generics and tagged unions. The way to speed this flow up is to post videos saying "this feature is neat in $lang1, I want to port it to $lang2, here's where $lang2 fails so I can't"[2].

If you hate Go now, take a moment to consider what happens when the Go team deploy their 'fully operational battlestation' at the point in time when they include these language features in the programming API and go on to tell you to use "go fix sourcetree" to massage your old code[3] to meet the new format, allowing you to adopt the new features.

[1] 2172 or 2272, I'm not sure. And you'd think by then we'd avoid century abiguity, too.
[2] With a 5-figure number for the YouTube comments that say 'patches or it didn't happen'.
[3] Which you have entwined with integrated tests, yeah?

K3n.