Live data from Hacker News

Go in Go

talks.golang.org

121–130 of 156 posts

Re: Go in Go

#123

Sorry for the noob question, but could someone help me understand how this is (conceptual) possible? I get that you can write a program which compiles language X to machine code, e.g. how python interpreting Go to write the assembly necessary would be technically possible. My question is, how is the compiler generated? If it's written in c, gcc -o compiler, but what is the piece I'm missing when it comes to Go compil…

Simple, you need a working version of go1.4 to compile go1.5.

The bootstrapping process can therefore take advantage of the fact that go1.4 will continue to build as it does today, and use that to get a working go installation to build go1.5+.

Re: Go in Go

#124

Earlier quoted context omitted.

I never understood this sentiment. C isn't assembly exactly because there isn't necessarily a direct correlation between the instructions the programmer writes and the resulting machine code. To me, this is as contrived as the idea that Javascript is "LISP in Java's clothing" In what possible sense can it be described as an assembler?

> because there isn't necessarily a direct correlation between the instructions the programmer writes and the resulting machine code If there was, then it wouldn't be "portable"

My point is that if you choose to ignore this characteristic of assembly languages, what exactly is an assembly language? C is a comparably high level language, which affords it things like portability and optimizing compilers. Assembly languages are used for minute and immediate control of the exact implementation.

Re: Go in Go

#125

Sorry for the noob question, but could someone help me understand how this is (conceptual) possible? I get that you can write a program which compiles language X to machine code, e.g. how python interpreting Go to write the assembly necessary would be technically possible. My question is, how is the compiler generated? If it's written in c, gcc -o compiler, but what is the piece I'm missing when it comes to Go compil…

Simple, you need a working version of go1.4 to compile go1.5. The bootstrapping process can therefore take advantage of the fact that go1.4 will continue to build as it does today, and use that to get a working go installation to build go1.5+.

Ah, great. Thanks for the explanation :)

Re: Go in Go

#126

There is no slide about writing the GC in Go. How do you write a GC in a GC'd language?

The usual way to do it is to define a restricted subset of the language that has explicit memory management and is statically typed, and implement GC with that.

For example, Pre-Scheme and RPython.

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.3.40...

https://en.wikipedia.org/wiki/PyPy#RPython

Re: Go in Go

#127

Earlier quoted context omitted.

Well, C is essentially "portable assembly", so it's to be expected...

I never understood this sentiment. C isn't assembly exactly because there isn't necessarily a direct correlation between the instructions the programmer writes and the resulting machine code. To me, this is as contrived as the idea that Javascript is "LISP in Java's clothing" In what possible sense can it be described as an assembler?

It’s relatively easy to mentally compile unoptimised C, or to look at an unoptimised assembly listing and correlate it with the source, but that’s about as far as the metaphor goes. C is a high-level language.

Only when I’m writing very performance-sensitive code do I actually think “here’s a branch, there’s a load, yonder is a divide”. Most of the time it’s “eh, compiler’ll get it”.

Re: Go in Go

#128

Earlier quoted context omitted.

Well, C is essentially "portable assembly", so it's to be expected...

I never understood this sentiment. C isn't assembly exactly because there isn't necessarily a direct correlation between the instructions the programmer writes and the resulting machine code. To me, this is as contrived as the idea that Javascript is "LISP in Java's clothing" In what possible sense can it be described as an assembler?

Because C is a very low level language, it imposes very little architectural decisions on higher levels that could cause impedance mismatches.

For example, you wouldn't want to implement a garbage collector in a garbage collected language; C won't get in your way.

This is also why there are loads of C libraries out there: they can be used with bindings from essentially any other language, which is generally not true for libraries implemented in non-C languages (in particular, C++).

Re: Go in Go

#129

Sorry for the noob question, but could someone help me understand how this is (conceptual) possible? I get that you can write a program which compiles language X to machine code, e.g. how python interpreting Go to write the assembly necessary would be technically possible. My question is, how is the compiler generated? If it's written in c, gcc -o compiler, but what is the piece I'm missing when it comes to Go compil…

On a related note, while Go at least has Go 1.4 available to allow bootstrapping from a C compiler for the near future (see [1] for more detail), many languages have no easy way to do so. For example, Rust's compiler was originally written in OCaml, and Nim's in Object Pascal, but both compilers were migrated to be written in the respective languages themselves, and AFAIK both languages have since evolved alongside their compilers for long enough that bootstrapping all the way from before said migrations to the present would require a massive chain of newer and newer compiler versions - not an undertaking anyone really wants to carry out.

Instead, any Linux distribution etc. that wants to integrate the language into its build system has to start by importing a binary from somewhere else. In general this isn't a problem, because that binary is used only to compile the compiler from source (and then that compiler recompiles itself, usually), so any bugs in it are unlikely to affect the final product. However, the topic tends to come up of Ken Thompson's famous paper [2] describing a hypothetical scenario where a compiler binary is intentionally backdoored to insert a vulnerability when it's compiling some security-critical program, plus a copy of the same backdoor whenever it detects it's compiling itself. In that case, the backdoor could theoretically infect the final result of a bootstrap, despite it being compiled from pristine source; no attack of that nature has ever been detected in the wild, though.

[1] https://docs.google.com/document/d/1OaatvGhEAq7VseQ9kkavxKNA...

[2] https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomp...

Re: Go in Go

#130

Earlier quoted context omitted.

I never understood this sentiment. C isn't assembly exactly because there isn't necessarily a direct correlation between the instructions the programmer writes and the resulting machine code. To me, this is as contrived as the idea that Javascript is "LISP in Java's clothing" In what possible sense can it be described as an assembler?

There is very little difference to the machine code (traditionally, before CPUs got so complex)

I'm not sure what you are saying here. Do you mean to say that it makes no difference to the machine how the code is generated, or are you saying that there is a CPU for which there is "little difference" between its machine code and C?
Post reply on HN