Earlier quoted context omitted.
> The other question is whether there actually is a reason that it will eventually do so. I personally have my doubts. C has found that perfect sweet spot between not getting in the way of doing things and running on almost any platform. That is the question. The way I see it, Rust's attractiveness to C developers goes up considerably the more accountable they are for the code they ship. If IoT and embedded devices s…
I think more importantly Rust has to clearly demonstrate that it really is better for projects that use C currently. I think the failure of wider adoption of D is a good case study.
I halfway agree. More evidence is always welcome, but the nature of that evidence will almost always be subjective, and I'm not sure a lot of language adherents even care all that much when the evidence is objective. So more is better, but "clearly demonstrate" may be pie in the sky thinking.
> I think the failure of wider adoption of D is a good case study.
I always considered D interesting, but not worth the effort for the gains it offered. A more ergonomic C/C++ is nice, but ergonomics just steer you the right way, they're a far cry from preventing a while class of errors. A GC does offer some help in that direction, but comes with a clear continuous cost. Compiler level error prevention with zero cost abstractions comes across as something a bit more new and novel, and changes the cost/benefit analysis some. It's now a one-time up-front cost, with the possibility that the cost will lesson over time as you become more accustomed to the language.
From an outsider's perspective, Nim was actually a lot more attractive than D as a replacement for C/C++. The cost seems almost negligible since it compiles to C, which makes the benefit fairly good (if overall of less magnitude than I perceive the benefit of Rust to be).