I’ll have to disagree with this. Adding new features is a problem if old things break but otherwise it just makes future programs easier to write.

You should be writing your next set of code with the newest features if they cut down dev time, cut down bugs or make that area more maintainable

code that's been written today has been made obsolete by a language feature in the latest nightly build

I mean couldnt you say that about any language? There's lots of old C code that's obsoleted by features in C11. There's lots of stuff written in python today that's obsoleted by stuff in the 3.13 alpha. It's just kinda how things go.

Doesnt the edition system prevent this from being too big of an issue anyway?

I don't have an opinion in this debate. I just started playing with Go and planning on doing so with Rust.

I wanted to point to the fact that Go is also in flux and is also seeing changes to its semantics, and this is relavent in the current events with Go 1.21 being released less than a month ago.

https://go.dev/blog/go1.21

In a future version of Go we’re planning to address one of the most common gotchas of Go programming: loop variable capture. Go 1.21 comes with a preview of this feature that you can enable in your code using an environment variable. See the LoopvarExperiment wiki page for more details.

This isn't really true though. Rust has integrated versioning and it cordons things off between editions. If you're within the same edition, you get updates without breaking changes. Even if you aren't in the same edition, you can grab specific compiler versions. Granted, in these circumstances you won't get security updates, but you have to be very out of date for that to be a problem.

I wrote an app using brand new Rust features for work 2 years ago. Despite upgrading the compiler version several times, I never needed to make a single code change. It is still being used daily as well.

Its already the case the language and ecosystem is so much in flux that code that's been written today has been made obsolete by a language feature in the latest nightly build.

This is just...not actually true, depending on what you mean by "obsolete". Rust has been stable since 2015; almost all code written for version 1.0 still compiles today.

Rust is risking of going the C++ way: have some many freatures bolted on that even as an experienced developer, you can checkout a random project on Github and discover a new language feature.

This is more subjective, but most of the current feature-stabilization work in Rust is not "bolting on" completely new functionality, but rather focused on reducing places in the language where different features are currently incompatible. This blog post is a bit old, but expresses what I mean: https://smallcultfollowing.com/babysteps/blog/2022/09/22/rust-2024-the-year-of-everywhere/

I disagree. Rust has editions, in which long term stability is guaranteed. On top of that the stdlib has guaranteed backwards compatibility as well. You're not required to chase nightly (and you shouldn't).

Coming back to code after a year is hard regardless of language. I’ve had C code I came back to after a year that was dead simple language feature wise but hard as hell to follow business wise. I would actually argue more modern features like Union types in typescript has actually made it easier for me. “Oh this function has to handle two cases of objects an object with an id and without an id”