I think the "static analysis" and the "runtime checks" approaches are complementary, not in opposition, making any noise around having to choose one or the other moot.

As they state in the article, they started the migration a year and a half ago, something that happened a few weeks back would never come into the decision making process.

That they can't (yet) be used to influence name resolution, so that they can't be leveraged for std API evolution. Work is being done on that front.

Older documentation that people find on the internet might be out of date and claim things that don't work but do on later editions, or vice-versa when trying out something that exists in a new edition in an older one. The mitigation for this is that if something is accepted in one edition but not another it must be taken into account in diagnostics so that the divergence is explained.

> Does it make the compiler and other tools larger and more complex for each new edition?

With editions 2015, 2018, 2021 and 2024, there are ~120 branches in the compiler for changes in behavior, including for changing diagnostics to be more specific. For comparison, just rendering a type error for if else having different types in its arms checks for 4 different conditions. 120 checks is a drop in the bucket compared to the number of things the compiler already has to check for, and the growth rate is very manageable accruing in the double digits over the course of 4 years.

> Are the migration tools always fully automatic, quick to execute, and flawless? Is any manual work, or expertise, required for upgrading in the worst case?

> Fully automatic

For most code, it is. We spend the time creating migration lints that can change your code as part of your upgrade, and we test those using crater to detect the cases that people are using in public libraries. It is conceivable that a project in a private repo is using a pattern that wasn't detected through that, so an appropriate structured suggestion isn't emitted, but I haven't heard of such a situation.

> quick to execute

it is as fast as cargo check

> flawless

If the compiler produces a structured suggestion marked as machine applicable, and I believe all edition suggestions are, our level of confidence on them being the right thing to do to get the users' code to compile with the intended behavior is high. Bugs can happen, but don't recall seeing any "incorrect suggestion" in edition lints.

> If I read a blog about Rust, and the blog forgot to mention which edition it uses for its code examples, can that cause any problems? Should I just skip the blog if it is old?

Differences between editions are actually quite small. You should be able to pick up The Book from 2015 and still learn the language. There are just things that The Book says don't work that now do, or features that were introduced that it doesn't talk about (both impl Trait and + use<'_> were introduced years later).

> If I see an interesting repository that I would like to learn from, but it was written in an old edition that I do not want to learn the rules for, will I have to upgrade the codebase myself before learning from it, or should I just skip it?

Just use the old edition or upgrade, either thing will just work. You seem to think that the behavior divergences are bigger than they are, and anything that does diverge should be emitting a diagnostic telling you what code to write instead. These are things like "in a previous edition you had to borrow here, in the next edition you don't".

> Are there any Rust projects that stay in an old edition for whatever reasons? How large a proportion of Rust projects that are still downloaded and used, are not on edition 2024? As an example, why are these popular projects still on Rust edition 2021?

Yes, there are crates that stay in older editions so that they can be used in projects that are frozen in time, like those that are shipped in some distros. (Edit: "frozen in time" as in "they won't update their toolchain", an earlier edition will always work on later ones due to backwards compat guarantees, the other way around of course can't.) To get a sense for it, serde which is a dependency that's almost inescapable is on 2021 edition and targets Rust 1.56. If a project decides that the impact on the ecosystem is bigger than the benefit of using newer language features, then it makes perfect sense to remain in an older edition.

https://lib.rs/stats sadly doesn't include statistics about the set edition, but it does have the graph at the bottom showing you rustc versions that the ecosystem supports, both for all crates and for the most recently updated. For reference, looking at releases.rs to refresh my memory, 1.31 is the introduction of edition 2018, 1.56 2021 and 1.85 2024. Those corresponds with the jumps in the chart. Note that looking at the chart it only tells you the likelihood of a random crate working on an older toolchain.

> How much work is it to upgrade someone else's codebase to a newer edition?

Not any more than updating your own codebase (and if you're upgrading someone else's it is because you've taken ownership of that code), which is to say, not much.

> Does upgrading a large project require intimate knowledge of that project in the worst case?

I can't think of any feature that would require that.

> How do Rust editions and macros interact?

The compiler has the concept of `Span`s, which is the byte offset pointing at a piece of your code. Every node in the AST has a `Span`, and is subsequently used in every later stage. It's what is used to render the diagnostics. But they also carry "context" information: whether a token comes from a macro expansion. And they also carry edition information. This let's you have a macro defined in one edition and use it in another, and the behavior will be the correct one, regardless of how you mix them.

> Does definition of macros or usage of macros make upgrading a Rust edition harder? If yes, how much harder in the worst case? Is upgrading always automatic?

The only situation I can think of is if there is a change in the parsing of macro arguments. For example, if Rust edition 20XX started parsing `A | B` as an anonymous enum type, then the macro call for `foo!(A | B)` would likely be parsed differently between editions <20XX and edition 20XX. That would be the kind of work you'd have to do. This has happened before in edition 2024, with expressions: https://doc.rust-lang.org/reference/macros-by-example.html#m.... In 2024 `expr` started not matching on `_` and `const {..}`. What was done then was introducing an `expr_2021` matcher with the prior behavior. When you update your edition to 2024 and apply the suggestions, your macro definitions get updated to use `expr_2021` instead of `expr`.

From your other comment

> Reading between the lines, it is as if you consider there to be large problems with Rust editions, but you do not wish to make Rust, Rust editions, nor the programming language concept of editions, look bad.

Reading your lines, it is as if you already had the conclusion that editions are bad, and are looking for a confession.

> Does upgrading a large project require intimate knowledge of that project in the worst case? How much work is it in the worst case?

I can't think of a situation where intimate knowledge of the project is needed.

> How do Rust editions and macros interact? Does definition of macros or usage of macros make upgrading a Rust edition harder? If yes, how much harder in the worst case?

Answered earlier.

A smart person can come up with post-hoc rationalizations that hold up under some scrutiny, to the point it is very hard to convince them otherwise. Add to that people who became famous or successful on the back of "being right" on some subject matter, getting used to "being right even in the face of overwhelming push back", and you have a recipe for very smart people being very wrong in very visible/loud ways.

You don't write a test (just) to verify that your change fixed the issue, but to ensure it doesn't regress in the future after an unrelated refactor.

In Latin America, most countries speak Spanish (with the obvious exception of Brazil and smaller colonies from the other European countries), so the every day pressure to learn another language isn't there and English becomes the "obvious" choice. I don't quite get why you seem to discount English entirely.

There's always been a Lingua Franca. It hasn't always been the same one. There will likely always be one.

It is legal in some places, illegal in as many others, and has caveats almost everywhere (children are almost always allowed, in other places it is based on speed, etc.).

There are people on bikes that ride like an asshole. There are people on cars that drive like an asshole. Both cause (different levels of) risk for pedestrians. There's only so much we can do about assholes, social ostracism works only so far and social change is much harder to accomplish than modifying our built environment to reduce or eliminate conflict points.

As an aside, I've noticed people get startled when I'm on my bike stopped but balancing on my bike while I wait for then to cross. I think some people intuitively model bikes on the same category as cars, so being anywhere close causes them to react as if a car hard crept close.

  struct Builder {
    a: Option,
    b: Option,
  }
  struct Val {
    a: u32,
    b: u32,
  }
  impl Builder {
    fn set_a(self, a: u32) -> Builder {
      Builder {
        a: Some(a),
        b: self.b,
      }
    }
  }
  impl Builder {
    fn set_b(self, b: u32) -> Builder {
      Builder {
        a: self.a,
        b: Some(b),
      }
    }
  }
  impl Builder {
    fn build(self) -> Val {
      Val {
        a: self.a.unwrap(),
        b: self.b.unwrap(),
      }
    }
  }