> Quite significant that Bell Labs Unix alums don't want to put up with C any more and actively purge it from their tree?

Go is quite literally written by the people who invented C, wrote C, and made it what it is today. (Ken Thompson wrote one of the first commits to the language).

The reason for purging C from the Go toolchain is that it makes it harder for Go developers to contribute. Go developers already all know Go (by definition) - why make them use a language that they may not know as well in order to contribute back to the project?

Furthermore, mixing C code with Go code can cause performance issues if not done right. While you can expect the official project to "do it right", this still raises the bar for people who know Go and want to contribute, but don't know C as well.

And frankly, I don't think it's that significant to say that they don't want to write C anymore. C was a great language for its time, and it still is a great language in many ways. But it's almost half a century old; it would be more surprising if after almost 50 years they couldn't write a language that they prefer even more!

> Furthermore, mixing C code with Go code can cause performance issues if not done right. While you can expect the official project to "do it right", this still raises the bar for people who know Go and want to contribute, but don't know C as well.

This is why Go was maintaining it's own C compiler -- They had it modified to work well with Go, as far as I am aware[1].

Removing it means one less compiler to maintain.

[1] From Go 1.4, the source for the Go C compiler: https://github.com/golang/go/tree/883bc6ed0ea815293fe6309d66...

I don't have the link handy right now, but IIRC there was a mention of some system level differences in how Go might like to change things in the toolchain under the language level which could move in a fundamentally different direction from the C toolchain. An example was in the area of how stacks were created and operated.

I think one could foresee making more changes in the future in that area. It's sort of exciting to think that these fairly low level foundational details which much of programming relies on, could be rethought and maybe get us to a different place than we are now.

More I think that most compilers want to be written in the language that they compile. Go has been moving toward this for a while since the compiler rewrite in Go. It's hard to call yourself a C successor when your compiler depends on a C compiler.

I think it is more dogfooding, no? Or proof of concept/completeness?

I agree. Also another benefit is that people interested in Go and not in C can now contribute to compiler itself.

Bell Labs alums have never had a specific penchant for C, per se, though their languages have mostly had C-like ALGOL syntax.