I write kernel drivers and firmware code mainly in C and a little bit of assembler. I agree with you pretty much. That said, it's healthy to have some people

I write kernel drivers and firmware code mainly in C and a little bit of assembler. I agree with you pretty much. That said, it's healthy to have some people exploring alternative paths. Maybe some of that exploration will be fruitful, way or another. Especially firmware development is somewhat ossified to C. C is universally supported and a lot of people in this trade don't even see need for a change, despite vastly increased system complexity and exposure over open networks. It's not enough for the things to just to work — they need to work securely, otherwise ultimately our infrastructure is at risk. C can work with 16 bytes to 16 TB+ (or a lot more) of RAM. It can span from a 4-bit single core microcontrollers to massive RDMA supercomputing clusters. C contender does not need to cover all of that, but should keep that enormous range in mind. The contender should also be able to interface with C library and linking interfaces. Otherwise it's hard to compose working systems. No matter how amazing the new language is, you can't build everything from scratch. So far I've placed my biggest hopes in Rust. But we'll see how the things evolve. One should keep an open mind. I wish good luck for the Red folks. By the way, you often can't allocate or free memory in firmware or kernel drivers either. Like in a kernel IRQ handler or on an embedded device with hard realtime and stability requirements. In that kind of case GC or manual allocation would not make much difference at all — you'd only allocate at initialization or at teardown.