I take this statement to mean: Academia is failing us by not providing us with the next generation C. If that was the intent, I think it's not a fair jab.
Academia IS actively investigating low-level languages: ATS, Cyclone, and typed assembly are all examples. But, it's not academia's job to create widely-used languages and tools. Sometimes they do create something that achieves wide use, but that's mostly a side benefit. Their job is to generate and evaluate useful "idea nuggets" that can inform future system builders and to train students to do novel systematic research.
There seems to be a common meme that academic CS is "out of touch" with what real developers need. I think it's mostly unfair: while the world always needs a slightly better web framework, compiler, language, etc., that's not the goal of academic CS; they aim to fertilize the ground with ideas that facilitate the growth of more big and small ideas.
I don't want to say that academia is failing or should responsible of giving us this "better C", just where I guess we should look to see "new C" coming is not there. However I think that academia may have a role in this matter, that is, to study the interaction between the programmer and the programming language about getting things done. This is probably done (but I can't remember famous recent studies about this) and could provide useful hints about how we can incrementally build / modify C to get a more reliable and less bug prone language.
However ultimately "new C" will be designed by one or two guys at max, as it always happened with this kind of practical programming languages.
D and Go are just following that thread.
Eventually all mainstream OS will have such type of languages and C will be legacy.
Microsoft is already slowly doing that by dropping support for C later than C90, and adding COM based API as the default Windows API. Now mainly for Metro, perhaps for the complete OS in later versions.
Apple as well, by adding reference counting and GC on their systems language, Objective-C.
C only got spread thanks to UNIX, and brought upon us the wrath of buffer overruns and dangling pointers security exploits.
We need better languages for doing systems programming.
Additionally, GC is not strictly necessary to solve buffer overruns and dangling pointers. Region-based memory management is an alternative for many use cases.
And about GC in kernel, of course you can. The issue is that most efficient GC needs giant locking and giant locking in kernel is something that you don't want.
In fact you can really live without GC. The burden of integrating it in kernel space out-range the benefit of using it.
> Eventually all mainstream OS will have such type of languages and C will be legacy.
That's just speculation. Personally I have high hopes for languages with optional-only GC, and much stricter memory management principals. Ala, Rust.
Don't forget that UNIX was once upon a time a research operating system, and took a few decades to have industry impact.
New ideas take time to mature.
I imagine that the kernel can easily compiled with the Objective-C or Objective-C++ compiler, if Apple so wishes.
All languages require runtimes, even C. The thing is that C as high level assembler it is, uses the operating system as its runtime.
The C language is also part of Objective-C, in a similar vein as C++ also supports most of the C89 features with small exceptions.
So it is possible to have the Objective-C runtime compiled using the C subset of Objective-C. This is known as compiler bootstrapping.
No, admittedly, I don't, at any more than a basic level. But you're still wrong.
Try compiling, linking, and running an ObjC program without the ObjC runtime. See how that fails. See how long it takes you to write a minimal runtime that can run your program in user-space, and then kernel-space. It won't be quick.
Try compiling, linking, and running a plain-vanilla C program without the "C runtime" (I guess you mean a combination of libc, libgcc, and crt.o, basically what you get when you pass -nostdlib -nostartfiles to gcc). Yep, that'll fail too. Then get it to compile and run anyway. Not that hard.
That's* the difference I'm talking about.
At the very least, kernels like Linux and Mach/Darwin already have kernel-friendly replacements for the libc functionality they commonly use. Doing something similar for ObjC would be time consuming. Certainly it isn't impossible, but note that I never said that: I merely pointed out it wasn't easy.
The same applies if you would be using the C subset of a C++ compiler.
I am old enough to remember the days when UNIX and C were funny research projects. Look at them now.
So I leave you with a list of research projects for the boring days, when you don't have anything to read.
http://www-spin.cs.washington.edu/
http://www.oberon.ethz.ch/archives/systemsarchive/native_new
http://www.ocp.inf.ethz.ch/wiki/Documentation/Front
http://programatica.cs.pdx.edu/House/
http://research.microsoft.com/en-us/projects/singularity/
I don't doubt that C is not the systems programming language of the future. But it's not going to be done in a system that's based around automatic GC either.
Additionally, I find it interesting to note, that if you had in fact been very familiar with all the work you mention. You should actually have noted that many of these systems go through significant effort to sidestep the GC.
It not just talk about some guys showing up papers at OS geek conferences.
The Oberon Native for example, was for long time the main operating system at the operating system research department at ETHZ. Most researchers used it as their daily OS for all tasks you can think of.
http://www.ethoberon.ethz.ch/WirthPubl/ProjectOberon.pdf
The GC was done at kernel level. Besides Oberon code, there is just a little bit of assembly for the device drivers and boot loader.
That's a ridiculous dismissal to make; we live in a world where hand-written assembly is considered a badge of honor, where people prefer to patch up a 40-year-old dinosaur rather than make something new, where people to go ridiculous lengths to avoid using a mouse simply because Unix didn't have mouse support in 1973. Is it any wonder that we're not using anything better?
Even in video games where this held true for longer, this is generally no longer the case.
> where people prefer to patch up a 40-year-old dinosaur rather than make something new
Also not true, Generally engineers prefer to make new things, The problem is that, creating new products from scratch to replace old ones ends up almost always being more effort than expected. Failure, is what causes patching the dinosaur the better approach, rather then engineering desires, Netscape is a classic example.
> where people to go ridiculous lengths to avoid using a mouse simply because Unix didn't have mouse support in 1973
I don't know what world you live in, because in the world I live in, computers with mice are much more popular than the alternative.
The fact that none of these systems are in usage is true, you can make excuses for them, but the fact of the matter is that there is a lot of smart people trying, and very little success. There is little evidence to support that this is a superior approach.
There's no such thing as language copyright.
While NeXT did not exactly created Objective-C, it acquired a license to be able to create their own implementation, which became the official Objective-C compiler.
Plus, lets see what is the outcome of the Oracle vs Google trial regarding copyright.
Implementation -- yes, the language itself -- no.
What about languages like Cyclone, decac, Clay?
D and Go are not trying to provide us with a better C, because they don't share the concept of, a language that translates straightforward to assembler, but still is designed so that you can mount good abstractions with it.
This is what you need for kernel programming, embedded systems, and a good deal of system programming as well.
At the same point C is one of the top-used languages in the world, with a vast code base, and yet almost all the attempts in the languages area are about much higher level or exoteric stuff. Not that I don't want that kind of research, but it's bizzarre that no one is focusing where a lot of meat is.
I bet this better C will arise in a few years at max, and it is not going to come from academia. Times are mature apparently, there is even a C conf this year ;)