And yet, many of the applications I use daily and actually prefer to use turn out to be written in C. I think more people should write applications in C.

I agree, but this was not the argument I was replying to.

I don't think this is is the case. While the N9 was certainly late and likely for the reasons you explained, and Android was coming strong, I do not think the market has already consolidated at that point, also because Nokia was still selling millions of Symbian smartphones. I certainly did not own an Android phone or seen too many people using it when I bought my N9.

No, I don't think so.

I do not understand this comment "for the 10^6th" time. Even if you do not want to use someone else's library, you write it once and then reuse it. The idea that is has to be in the standard library or you have to rewrite it from scratch all the time is very weird.

I prefer C over Rust anytime because of much less complexity, more portability, higher stability, more tooling, far less supply chain issues, fast compilation times, proper dynamic libraries, less ugly syntax.

I had the N9, the GUI was good. I liked this phone much more than the Android phone I had to replace with much later. I do not know what went wrong inside Nokia, but the CEO came from Microsoft and killed Meego.

IMHO " seemed destined for irrelevance after the iPhone's 2007 arrival." is rewriting the history. My interpretation is that Nokia panicked and self-destructed by switching to Windows Phone after seeing iPhone but even more Android taking smartphone market share in 2010 and 2011, and if it instead just had kept developing their own Linux-based smartphones, it would still be around selling their own Linux-based smartphones which were far superior than Android.

You can also specialize C code for architectures, you do not need C++ template metaprograms for this. I also see them overused, creating a lot of bloat that then can hurt performance.

Rust has many flaws C does not have, including a type system build on monomorphization, annoying syntax, less explicitness, worse support for independent compilations.

But what you can is put an ownership / lifetime model similar to Rust into C or C++. This does not avoid all the hassle of Rust but would avoid some of the problems of Rust and allow a much smoother transition.

It is the usual problem of open-source and free software. What is old is not maintained properly. Rust gives companies an excuse to move on until it too is boring and old and will suffer from neglect.

For example, cyclone, a predecessor of Rust, was much closer to C

Java, C#, Rust, and Go were not created by people who want to make C safe, but people who have different ideas on how a language should work. Go is, unsurprisingly, close in philosophy but the others are very far.

Function pointers do not need to be replaced in a safe version of C.

You are right that you need something as lifetimes or a borrow checker. You certainly do not need an entirely different syntax, proc macros, monomorphization, many different string types, etc.

It is mostly hard because there are no resources for it. Even for maintaining C front-ends compilers there are barely resources, there is so much which you could do easily, but most of the energy goes into C++ or other things.