[jnbiche]

That's a fair argument. Neither Golang nor D give you the control that C gives you. If that's your yardstick, then the only viable candidate at this point is Rust. But Rust doesn't feel or look anything like C, but more like C++ or maybe Scala.

[stusmall]

Its not just the lack of control, the bigger problem is features that have been added in. There major use cases for C that go by its nature can not fill. It can not do bare metal programming or real time applications without major changes to the language standard. Go aims to be a superior system programming language than C but not a successor to C. No one will be doing audio codecs or device drivers in go, but I would consider it over C for a greenfield system daemon.

[a-nom-a-ly]

> It can not do bare metal programming or real time applications without major changes to the language standard.

TIL that these are required for text editors and related tools.

[pjmlp]

They could, if:

- Go's unsafe package offered the same capabilities as Oberon's SYSTEM

- It offered a bit more control about GC takes place

Any AOT native compiled language can be used in place of C for user space code. There is hardly any C feature essential for such type of applications.

C can be relegated for kernel space until something better gains more market share.