It's still too early. There's tons of good reasons to write C code today for many projects. Furthermore, there's so much C code out there that even if nobody wrote a single new line of C today, it'd be decades before it would go away.

It's really about growing the pie rather than replacement anyway, in my opinion.

>even if nobody wrote a single new line of C today, it'd be decades before it would go away.

But then we can get sweet sweet COBOL level salaries in 40 years.

Although, a lot of us are working towards replacement of C in a lot of areas. Being able to say you've written something in Rust is one thing, but having the whole stack Rust all the way down is something else. Not to mention, it's fairly simple to create C bindings from Rust libraries using Cargo workspaces and cbindgen.

Even if it is objectively better in every way (not saying it is, only going for the most extreme end point for purposes of making a point) it is not guaranteed to replace C. Too many people have invested too much time mastering C and learning to deal with its quirks to simply give it up.

There may come a day where basically 0 new C projects are made. I do not think that will be in my lifetime. And I say that as someone with near 0 investment in the language but intends to get more serious about learning rust in the near future.

Until we replace UNIX derived OSes and throw away POSIX compatibility that day will never come.

We've already thrown away POSIX compatibility. Linux isn't POSIX. Mac OS X isn't POSIX. Windows isn't POSIX. POSIX only continues to exist in varying degrees at different times.

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. Rust still has to achieve that status and judging from other competitors like C++/D it seems hard to get to that point. Heck, even Java was advertised as systems language on Java CPUs for a while.

> 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 start having repercussions for out of date, exploitable firmware/services, either through public opinion, legal or legislative means, making a switch to a language that provides more guarantees starts to look a lot more feasible and attractive to a lot of C die-hards.

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 think more importantly Rust has to clearly demonstrate that it really is better for projects that use C currently.

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).

"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."

One way to clearly demonstrate this in my opinion would be big projects that are implemented in Rust. I remember when Java came up there were plenty of people saying that it would totally replace C/C++ but you just had to look around to see that not much big software was written with it. Same for C#. Once we see something widely used like git, a big database, a web browser or similar written in Rust then we know Rust has arrived.

In that respect, I think Servo and Firefox is the big project. Unfortunately (or fortunately, depending on the direction you look at it from), due to Mozilla's putting good engineering principles ahead of marketing and pulling in proven pieces of Rust code from Servo piecemeal, most people will likely never know. The best we can hope for is not that it's just a win, but that it's such a large, obvious win that when people go "How is Firefox so awesome"? the answer is Rust. That's a tall order to fill. :/

" putting good engineering principles ahead of marketing and pulling in proven pieces of Rust code from Servo piecemeal, most people will likely never know"

That's really not a good strategy. At work I can't just start using Rust without justification but if I can point at large projects being written in Rust suddenly has credibility.

For marketing a language? No, unless you ruthlessly capitalize on every small change.

For iterating on large changes to a stable secure web browser used by many millions? It seems to have worked well for them so far.

The problem is that if Rust doesn't establish itself in the broader market then the effort of developing it and adding to the browser is pretty questionable. You generally don't want code in a language nobody else uses.

I hope rust will make it but it's very hard to establish a language long-term.

Well, Java is the systems language on Android that has full exposure to what app developers can actually use.

NDK is quite constrained, mostly as a means to implement Java native methods.

On Android Things they went one step further and the user space drivers are written in Java.

With Treble it is also possible to write drivers in Java thanks to the new micro-kernel like architecture.

I mean it might eventually happen but currently hardware support, vendor support, also all major Unix operating system implementations are written in C and the maintainers don't look like they will change anytime soon. Also C has lot's of inertia behind it.