In fact there are hardware models that fit Erlang better, such as non-cache-coherent NUMA. So from a certain perspective, it's not that C is low level, it's that the CPU was designed to execute C. And the CPU is anyhow general enough to be used in non-C-like ways.
I personally think Go missed a trick when it didn't require channel data to be provably impossible to alias across goroutines. (It could be immutable, pass-by-value, or "unique" such that aliasing is disallowed.)
As for nulls, Go actually doesn't really have them, the poster above is mistaken - Go has zeroed values, and you are encouraged to make them valid-but-empty. That includes zeroed pointers.
Is there a material difference between that and null? I don't care what I'm "encouraged" to do -- does the language force you to opt in to null?
Yes if you're using pointer-like things, but at least in Go it's an unsurprising thing, all uninitialized data is zeroed. And Go permits you to work with by-value structs and arrays if you want.
t.next == nil
The C way with single return means that it's generally impossible to just forward the same error object - the caller has a different type from the callee, so where one returns null another has to return -1, and so forth.
My point is that it's stupid and harmful to do a little better than C when you can actually learn from experience [1] and the last forty years of PL research and do much better than C.
[1] http://qconlondon.com/london-2009/presentation/Null+Referenc...
A process scheduler's job involves saving and unloading the virtual memory mapping of a process that is blocked or pre-empted, and overwriting it with the virtual memory mapping of a new process. The process scheduler must have direct access to physical memory in order to perform this transition. Any kind of pointer safety would be built on top of a virtual memory abstraction; the process scheduler must necessarily be outside of this abstraction to do its job.
Given that a scheduler's going to be running in kernel mode, why can it not just muck around with kernel address space and leave it to the page table to do the translation?
Yeah, I did clarify my request a little -- by safe I meant safe with optional nullability.
Those aren't the "fundamental problems of C", those are the reasons people use C in the first place. The point of "systems languages" like C and Go is that they directly expose a (standardized interface to) the Von Neumann architecture your computer actually implements, which allows for arbitrary references to memory that may be uninitialized, multiply-aliased, etc. This is what allows for the efficient implementation of such things as garbage collectors, process schedulers, virtual memory managers, IPC libraries, network stacks, and so forth, that the runtimes for higher-level languages rely upon as fundamental abstractions.
So, given the assumption that such code is necessary to write, why shouldn't we try to have a better language to write it in than C? I'm not suggesting that Go is such a language, but your argument seems to be that it's pointless to try to do better than C (because every language, no matter how good, starts with no one using it, and thus necessarily will have fewer programmers than C does.)