From using Rust, it’s clear there is still a lot of work to be done. Someday Rust will be stable and mature, but it isn’t now, and it doesn’t look like it will be a year from now either. The plasticity of the language honestly is what allows it to continue to innovate where others do not. Let’s let Rust find its niche and then lock it down, and not rush it or we’ll be regretting it in a few years.

The only languages that are “finished” are the ones nobody uses. Heck, C’s latest standard is from 2018. And there’s probably gonna be a new one next year. Most changes are minor, but sometimes they’re bigger. Just like any language. It moves much slower than most languages, but it’s still moving.

C's 2018 standard cannot be compared to Rust's development in good faith. C didn't add anything new - it just clarifies edge cases, and does not change downstream C code in meaningful ways. And that constitutes 7 years of C development.

C 2018 was a small release, sure. There are bigger ones. C11 added an entire memory model.

> it just clarifies edge cases, and does not change downstream C code in meaningful ways.

This is exactly the same as Rust. (Again, with the small exception of soundness fixes, which, depending on impact, we sometimes leave a year of warnings in before actually changing.)

Yes, there have been bigger C standards updates. But keep in mind: these happen maybe once per decade.

Sure. This is moving the goalposts though: you initially said "when will this be finished?" It is clear that C is not finished.

I would strongly disagree with that. C is finished, and what they've been working on for the past decade doesn't change that. I don't think you're arguing in good faith if you claim that the C development lifecycle is even remotely comparible to the Rust development lifecycle, and I'm not going to continue entertaining this.

I don't think that you're arguing in good faith when you claim that Rust putting out new versions means "it's not done" but C putting out new versions means "it is done."

My argument is not that they are comparable. My argument is that it's a difference of degree, not of kind.

The difference is obviously in what kind of changes are included in each "release". C has a specification (something Rust lacks) and C18 simply clarified unclear edge cases in the standard. No new features were added. Rust releases add new features and semantics, Q.E.D.

New Rust versions don't change downstream Rust code either, except in edge cases. And those edge cases are only to fix potential security vulnerabilities.

Changing the definition of idiomatic counts as changing downstream code.

Only if you feel like you need to constantly update your code to be idiomatic, which is absolutely unnecessary. No one has to change their code to conform to whatever the new version of "idiomatic" is. Their code will continue to work, and it won't be "bad".

Try Cobol, it's pretty much finished.

The latest version was released in 2014