That's certainly reasonable, but I think it seems harder to keep up with when people compare it to languages like Go (first appeared November 2009) and Kotlin (first appeared July 2011). Those languages both seem really easy to keep up with by comparison. Of course, both of those languages are going along much more well trodden paths.
I think the "Rust is changing too much" feeling comes from people really wanting to use Rust because it has a cool new way of managing memory and zero-cost abstractions, but also feeling like it just keeps moving a little too much on them. Languages like Go and Kotlin just aren't moving much on them.
I think that another part of that feeling comes from the fact that Rust has two different pieces: a) the new way of dealing with memory and abstraction; and b) the syntax, sugar, etc. If you're looking for "a", Rust is the only game in town there. You can't just decide that you need the memory lifetimes and zero-cost abstractions, but don't want to deal with the rest of Rust's evolution.
This might be easier to illustrate by contrast. If I want a statically-typed, garbage-collected language, I can choose Java, Kotlin, C#, Scala, Go, TypeScript, etc. I feel like I have a lot of choice. If I want a dynamic language, I can go with Python, Ruby, JS, PHP, etc. If I want a language that doesn't need GC while not having memory leaks...I'm left with Rust. I can't decide that I don't like the other parts of Rust or don't want to deal with Rust's evolution. If Kotlin were evolving quickly and breaking lots of things, I could just say "Kotlin is dumb and I'll just use Java or Scala or C# or Go". I can't say "Rust is dumb and I'll use..."
When there aren't easy replacements, you're wedded to the decisions of the community. The easier the replacements, the less loud your complaints will be about a language. I think that Kotlin was pretty great for Java because it was highly compatible with Java and gave Java breathing room to figure out how it would evolve Java. Kotlin gave frustrated people a path; it gave Java breathing room to figure out its evolution; and it gave Java the opportunity to look at what worked well in Kotlin and figure out how it could apply that in Java.
When we look at Go, there are often complaints because Go offers things unavailable elsewhere: fast compile times and to a certain extent its concurrency support. So if you really want fast compile times, you don't have an alternative.
Rust is probably changing more than languages like Go and Kotlin which are similar aged. There's a good reason for that: Rust's brief is a lot more novel and expansive than those two languages. However, if you're sold on Rust's memory management and zero-cost abstractions, it might be annoying that it feels like more of a moving target than a language like Go or Kotlin - and you have no alternative to fill that void.
I sure wish Go moved faster. Took them long enough to get around to generic data types. There's still an awful lot of programming that's just not possible in the language still.
> If I want a language that doesn't need GC while not having memory leaks...I'm left with Rust.
I never used those languages, in fact I discovered them on previous HN posts, but it seems to me that in this category you can also have Nim and Zig, no?
Those are considered niche compared to Rust or C++. Rust has a large ecosystem around it and at least one large sponsor (Mozilla) and used in production by others like Cloudflare, Yelp, and npm.
I think Nim and Zig are both quite interesting and potentially very productive, but they have a long way to catch up to Rust in terms of community support.
Corporate sponsorship is just an example of the level of support that exists for Rust. And it's Mozilla I'm talking about here, not your typical corporation.
Certainly other languages were able to become widespread with large communities and library ecosystems without being directly sponsored by a corporation, such as Python or Ruby. I tend to think of those as associated with an individual, Guido or Yukihiro, though I know in Guido van Rossum's case he's worked for Google and Dropbox, though that was after Python was in wide use at those companies.
Whereas with Rust I think "Mozilla" not "Steve Klabnik", because it was corporate-sponsored from the beginning and worked on by a team.
And if you want your favorite language to grow into its potential, you need funding, and corporations have a lot of funding to put into things like potentially productive new languages.
It's similar to Javascript in a way. If I want to code for the web, I can only use JS. Sure, there are extensions like TypeScript, or even other languages that compile to JS like Elm, but most people are gonna use JS.
I think the "Rust is changing too much" feeling comes from people really wanting to use Rust because it has a cool new way of managing memory and zero-cost abstractions, but also feeling like it just keeps moving a little too much on them. Languages like Go and Kotlin just aren't moving much on them.
I think that another part of that feeling comes from the fact that Rust has two different pieces: a) the new way of dealing with memory and abstraction; and b) the syntax, sugar, etc. If you're looking for "a", Rust is the only game in town there. You can't just decide that you need the memory lifetimes and zero-cost abstractions, but don't want to deal with the rest of Rust's evolution.
This might be easier to illustrate by contrast. If I want a statically-typed, garbage-collected language, I can choose Java, Kotlin, C#, Scala, Go, TypeScript, etc. I feel like I have a lot of choice. If I want a dynamic language, I can go with Python, Ruby, JS, PHP, etc. If I want a language that doesn't need GC while not having memory leaks...I'm left with Rust. I can't decide that I don't like the other parts of Rust or don't want to deal with Rust's evolution. If Kotlin were evolving quickly and breaking lots of things, I could just say "Kotlin is dumb and I'll just use Java or Scala or C# or Go". I can't say "Rust is dumb and I'll use..."
When there aren't easy replacements, you're wedded to the decisions of the community. The easier the replacements, the less loud your complaints will be about a language. I think that Kotlin was pretty great for Java because it was highly compatible with Java and gave Java breathing room to figure out how it would evolve Java. Kotlin gave frustrated people a path; it gave Java breathing room to figure out its evolution; and it gave Java the opportunity to look at what worked well in Kotlin and figure out how it could apply that in Java.
When we look at Go, there are often complaints because Go offers things unavailable elsewhere: fast compile times and to a certain extent its concurrency support. So if you really want fast compile times, you don't have an alternative.
Rust is probably changing more than languages like Go and Kotlin which are similar aged. There's a good reason for that: Rust's brief is a lot more novel and expansive than those two languages. However, if you're sold on Rust's memory management and zero-cost abstractions, it might be annoying that it feels like more of a moving target than a language like Go or Kotlin - and you have no alternative to fill that void.