"read C" is a very loose term. Yes, I can read C. But, as I am not using in daily practice, I am rusty. While as a Go programmer, I am quite trained in reading Go code. You also do need to know the behavior of one compiler (the Go one) vs. also have a good understanding what the C compiler does.
Also, Go is a much clearer and strongly typed language, so Go certainly is a much nicer implementation language than C. (If I thought C was better suited, I would be using C in the first place...)
Right, but are you also skilled in writing garbage collectors? (You may be, I'm not assuming you aren't. I'm not.) Otherwise the fact that you can read Go more easily than C doesn't make a difference, as what would you do after you've read the code if you don't understand what any of the algorithms or why they are designed that way?
I'm sure it's very good that as much of the runtime is written in Go as possible, but I think people are being too optimistic when they hope it will empower people who aren't already skilled in compilers or garbage collection to contribute.
Of course, being a Go expert does not make you a GC expert automatically. You need to be both. But why should you also be a C expert? Adding another whole field of expertise to the requirements does not sound like an improvement.
And everything written in Go also means you are dealing with just one compiler and not two, if you mix Go and C code.
I don't think you should also have to be a C expert, but I am suggesting that, in practice, there is nobody in the world who is proficient in garbage collection who does not also know C. I think if you learned everything needed to understand GC, but were never exposed to C, you would already know enough to pick the language up in a couple of hours.
Nobody is going to turn up in the Go IRC room saying that they have a great idea how to reduce pause times by improving the work-stealing between concurrent markers by using a better lock-free queue algorithm, except do'h they don't know C.
I get your point about just one compiler though - less moving parts is good.
One benefit you miss is by using Go in GC all Go tools (fmt, profiler, vet, godoc lints etc) available to writers of GC also which was not possible with C.
I think it is similar to Oracle was trying to JVM in Java known as Maxine. Now JVM contributors or potential contributors would know C++ but from OpenJDK website one motivation was to leverage amazing Java tooling to write its own VM.
I just noticed Oracle seems to have removed references to Maxine VM from Oracle website and OpenJDK website. Seems that project is no longer active.
> Graal is a dynamic compiler written in Java that integrates with the HotSpot JVM
I am not sure if this is Maxine VM which I thought something analogous to Hotspot JVM. Or may be Maxine was similar in scope as the link you have given and not an experimental or otherwise replacement of Hotspot JVM
C has an eco-system? Really? Yeah, sure I can download source code and headers and somehow use 12 different antiquated tools that strung together with duck tape and bubble gum that are also not standard on Windows let's say, to actually hopefully compile that code, and then worry about 12 other different tools each with 6 different options to be able to do something simple like "link a library", and hope that works on FreeBSD and OS X and Windows, but it won't, it never does, without spending an insane amount of time tweaking headers and m4 macros, before giving up and learning CMake, but if that's what you consider a "mature eco-system", then you have very low standards.
No one doubts that there is a rich ecosystem available for C. The thing just is, when you are working in a Go environment, what benefit would adding C with its own toolchain bring?
No need for bootstrapping step, 90% of portability taken care off for free, ability to use lower level and faster primitives than Go offers, access to tons of great C libraries.
You sir, have clearly never attempted to write portable C or Go code. Writing portable C code takes a serious effort. It's not hard if you know what you have to pay attention to - but 90% portability taken care of for free? That's simply not true, unless you think being portable is "it runs on a POSIX system".
Writing portable Go code - in most cases - you don't need to do anything or make only slight changes to your code, and cross-compiling is the easiest I've ever encountered.
> Nobody is going to [...] have a great idea how to reduce pause times by improving the work-stealing between concurrent markers by using a better lock-free queue algorithm, except do'h they don't know C.
I think you do yourself a disservice to discount that.
I'll happily tell you about places in the go runtime where we could use some smarter memory fencing instructions to build faster lock-free queues on x86_64.
I also don't write C. (Well, I'm trying to write a patch to libgit2 right now, but really, the operative word there is "trying": it's just highlighting it all the more clearly: I don't know C.)
I learned about the memory fence instructions while doing concurrent programming in java. The notion that C is the only bridge we can cross -- or the right bridge to cross -- to get to assembly (or any other abstraction layers necessary for high performance engineering) is absurd. We can put it to rest now.
>Of course, being a Go expert does not make you a GC expert automatically. You need to be both. But why should you also be a C expert?
You shouldn't, but historically and statistically GC experts and compiler experts are also C experts. And it's not like "Go is written in Go" that gonna change that (we've had languages written in themselves for half a century and still most compilers are written in C/C++).
I can read both Go and C, but not in the style that is preferred by core Go runtime developers. I struggle a lot to read the code when all important data structures are one-letter names - G, P, M, etc. I understand not wanting Obj-C style identifiers, but single-letter ones?
Go runtime code reads like `x := g.b(a.C)` and you have to do quite a bit of manual cross-referencing of variables and identifiers to even get a vague idea of what is going on. It obviously somehow works for them.
You don't need to be, but if you can't read C, I'm not sure how much extra value you are going to get from reading how a particular garbage collector works.
You may use Go all day every day, but that doesn't mean you have the skill to implement or extend a GC. If you have experience in that area you almost certainly know C like the back of your hand.
Are you really restricting the pool though? Most devs can't write or efficiently develop a GC. Learning a language is easy compared to writing a reasonably performant and correct GC. Anyone in this area worth their salt can pick up C if they don't know it already and, again, they probably already do if they have experience at this level.
I've been hearing 'C is dead' for fifteen years now, but it hasn't gone anywhere.
We've had compilers being written in their own language for half a century, but it hasn't changed the fast that most (and all the succesful ones with millions of users) are written in C/C++.
Also, Go is a much clearer and strongly typed language, so Go certainly is a much nicer implementation language than C. (If I thought C was better suited, I would be using C in the first place...)