They're all C programmers!

Why to you think all of them created languages to replace C on their daily work?

There are many reasons to use a specific programming languages besides "I like it".

For example I will never use C on personal projects, but will use it without any complaints if that is what my customers ask for.

In what possible sense can it be described as an assembler?

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

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

Remember that it also enforces the idea of types, scopes, blocks, functions, the heap and the data stack quite strictly. It might be a very low level language compared to something like Java, but in terms of being unassuming of architectural intent, I can't say that I agree that it is even in the same ballpark as any of the assembly languages I've used.

Also there's no fast way to check arithmetic overflow from portable C, which limits bignum performance.

Due to these limitations better portable assembly languages like C-- have been designed; these days LLVM bitcode is an option as well (which is not actually portable IIRC...).

C is one of the few languages today that still gives you very precise control over how you use memory. That can be a powerful tool, especially given how important effective cache usage is on chips.

If there was, then it wouldn't be "portable"

I think the joke/humor/analogy is that C compilers are so good and C itself is so low level, that you don't actually gain much (if anything at all) by dropping down to ASM now (compared to 10-20 years ago).

"By design, C provides constructs that map efficiently to typical machine instructions"[1]

I believe this is what the op was getting at. This is why C is called a "mid level" language.

[1] http://en.wikipedia.org/wiki/C_%28programming_language%29

https://en.wikipedia.org/wiki/Niklaus_Wirth

https://en.wikipedia.org/wiki/Alan_Kay

https://en.wikipedia.org/wiki/Jean_Ichbiah

...

Wasn't CFront written in C++?[1] (Of course, the initial version of C with classes was probably written in C.)

[1] https://en.wikipedia.org/wiki/Cfront

Which languages do you think guys at Microsoft, Apple and Google get to choose?

Those developed by their employers or others?

I'm not saying it would be necessary slower than a compiler written in C, if they wrote the more critical parts in assembler, but you would think compiling speed would be one of the outstanding discussion points, after a major rewrite.

http://talks.golang.org/2015/gogo.slide#15

While the next mentions that the got it back up -- but not by how much.

It wasn't exactly crystal clear from the docs/website, but apparently[1] "master" is go1.5 -- so with go1.4 on windows, one can:

    # from a git bash, already have go1.4 installed
    git clone https://github.com/golang/go.git go.git
    cd go.git/src
    git checkout master
    export GOROOT_BOOTSTRAP=$GOROOT
    time cmd "/c all.bat"

    real    0m29.078s
    user    0m0.015s
    sys     0m0.030s

    # with our fresh go1.5 (see more below):
   
    real    0m33.034s
    user    0m0.000s
    sys     0m0.000s

Note that if you want to do this, in particular the second part, it gets a bit hairy, as "go.exe" needs to be in your path, and you need to change your gopath (easy).

On my system, I had everything in $HOME/opt (%HOME%\opt), so all i did was move opt\go to opt\go1.4, and copy go.git to \opt\go. One can confirm the right version is being run with 'go version' (and 'cmd "/c go version"' from bash).

[1] After a few useless hits, I found: https://godoc.org/golang.org/x/mobile/cmd/gomobile -- which mentions what's needed to actually test go 1.5. If they want testers, they should probably add something under "install from source" on golang.org about "And if you want to live on the edge, or say, test go in go, use "master")

https://groups.google.com/forum/#!msg/golang-dev/6obxRcm-rqc...

Edit: Of course, faster speeds would be interesting to hear about, so great question.

Fast compilation is an explicit goal of Go, so they certainly think it matters.

https://github.com/golang/go/tree/dev.ssa

No idea how long it will take to mature, but I hope there are some decent performance improvements once it is fully functional.

> Generate machine descriptions from PDFs (or maybe XML).

> Will have a purely machine-generated instruction definition:

> "Read in PDF, write out an assembler configuration".

> Already deployed for the disassemblers.

(my emphasis)

That coupled with a whole tool chain in a friendly language like go, makes be exited for how this might be used by other language designers. While "compile to go" might not be as attractive as "compile to c" -- it's not half-bad. More importantly it kind of smells like part of this tool chain should make it quite easy to generate machine code quite easily.

Nothing against llvm, rpython/pypy, graal etc - but the more the merrier!

https://github.com/acityinohio/baduk

All that said you can of course write your own bots, but Copmputer Go isn't as easy as one might think. In fact it's still considered a much harder problem than Computer Chess.

[1] http://www.lysator.liu.se/~gunnar/gtp/

[2] http://en.wikipedia.org/wiki/Smart_Game_Format

https://github.com/skybrian/Gongo

> [14:54:36] Topic is Go, the game (not the silly language) ! (the language see #go-nuts

> Code is cleaner, testable, profilable, easier to work on.

This is just great!

How do you write a GC in a GC'd language?

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

Can the GC be interrupted by itself if it takes too long or uses too much memory?

It seems like there are several things about the GC that would need to be special-cased, since the GC is implicitly invoked by the runtime.

edit: This is the link I meant - https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomp...

c_i is the i'th version of the compiler.

    c1 c2 // c1 compiles c2

    c2 c3 // c2 compiles c3

Horrible.

Much like HackerNews website implementation, actually.

That slide-script is just broken.

Of course, that's the nature of bootstrapping! If someone managed to erase all the software from all the computers in the world, we'd have to go back and find an "Old world" Mac and use the on-die Forth compiler to write a C compiler so we could start compiling things again.

Otherwise, I'm guessing that for Go 1.6, they'll rely on you having a binary distribution of 1.5 (probably from your distribution, or their website), etc.

That's not true at all, (1) you write the backend for the target machine, (2) you recompile the compiler with the new backend included on a supported host, (3) then use the new compiler to compile itself for the target using the new backend, (4) you now have a compiler that runs on the target.

Same process is used to port C compilers (or any self-hosting compiler, really).

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 compiles a Go compiler -- or is this still done as "here's the machine code, now compile the Go runtime"?

I suppose my question is a similie to "the chicken or the egg?".

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

You've got no go1.4 there to boostrap you (new architecture), and you can't get the binary because you're trying to build the first one.

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

Build the new version of the compiler with the previous version of the compiler

Rebuild the new version of the compiler with the new compiler from the previous step, that was built with the old compiler

Rebuild the new compiler with the new compiler from the previous step, that was also built with the new compiler, and that's your official binary

The initial creation of the language requires somebody to write a compiler for it in assembly or in some other language that already has one, but once you get that first one built, all the rest could be in their own language.

Yes.

> whenever i see the "X is all but Y" phrase, it makes sense to me that X is not Y.

It's not "X is not Y", it's "X is all but Y", that is, X is very nearly not Y. "All but impossible" means it's possible, but only barely.

All but impossible, it's everything up to, but not including impossible.

See http://en.wikipedia.org/wiki/Self-hosting

Start by implementing in Assembly as little as possible for the programming language as an interpreter.

Meaning just one form of conditionals, just one looping construct, very few basic types, basic IO.

Then use the bare bones interpreter for the second stage, writing a real compiler that is able to process the same basic language and additional constructs.

Another alternative is to add some bytecode format that can then be used equally for interpretation or as input to native code generation.

Niklaus Wirth originally designed P-Code with the intent to make Pascal compilers easier to port. He wasn't thinking to use it as full OS VM, like the guys at UCSD did with they Pascal dialect.

Another trick is to design the bytecode in such a way that it can directly be translated to native code via a macro assembler. It won't generate fast code, but it will provide an easy path for a compiler instead.

Nowadays the Assembly step tends to be replaced by another language that can be found in most platforms, so many tend to choose C.

Not always because it is the best language to write compilers in, but rather because it is ubiquitous or there is some library the authors want to use, thus perpetuating the myth that all languages require C for those not so well versed in compiler design.

> Use the left and right arrow keys _or click the left and right edges of the page_ to navigate between slides.

I will note that go programs still seem to build orders of magnitude faster than C++ programs, even after this change.

Because the compiler is now written in Go, compiler optimization will affect how fast programs compile.

The compiler may speed up or slow down because it is doing more advanced code analysis, but is generating better assembly. I do not know if this will cancel itself out or not.

https://talks.golang.org/2015/state-of-go-may.slide#11

  •  Talk 1: Andrew Gerrand on Go 
  •  Talk 2: Rob Pike on Go 
  •  Talk 3: Aaron Schlesinger, Concurrency Conventions in Go   
  •  Talk 4: Steve Francia, Common Mistakes in Go and When to Avoid Them

I'm having trouble running the compiler.

     bpgcomp bpgcomp.bpg -o bpgcomp