> It's not possible to port a millions line C++ code base, like Chrome, to another language so large C++ projects are stuck with objectively pretty bad language and are forced to continue to use C++ even though a better language might exist.

One good aspect about C++ is its backwards compatibility or stability. Also a drawback, but companies not having to spend huge amounts of time, expertise and money rewriting their whole codebases all the time is something they appreciate.

Rust is often somewhat stable, but not always.

https://internals.rust-lang.org/t/type-inference-breakage-in...

https://github.com/rust-lang/rust/issues/127343

300 comments on Github.

https://github.com/NixOS/nixpkgs/pull/332176

Rust has editions, but it's a feature that it will probably take years to really be able to evaluate.

What kind of compatibility story will Carbon have? What features does it have to support compatibility?

▲

aw1621107 5 days ago | parent | next [-]

> Rust is often somewhat stable, but not always.

> https://internals.rust-lang.org/t/type-inference-breakage-in...

> https://github.com/rust-lang/rust/issues/127343

> 300 comments on Github.

> https://github.com/NixOS/nixpkgs/pull/332176

Might worth noting that this change technically doesn't violate Rust's stability guarantees since type inference changes and/or adding new impls are exempt. Of course, that doesn't really help with the question of whether this change should have been made in the given timeframe (as opposed to the socket struct change IIRC?), but that ship has long sailed.

▲

justcuriousab 5 days ago | parent [-]

I wonder if the guarantees could be amended, considering the reactions from the Rust community.

▲

aw1621107 5 days ago | parent [-]

They could be amended, but I suspect they will not be. There's a reason those exemptions were added in the first place, and the impression I get is that the 1.80 issues were more of a social problem that doesn't significantly change the reasons the exemptions were added in the first place.

In addition, as I mentioned I don't think this is the first time Rust has had to navigate this kind of wide-ranging technically-allowed-but-still-breaking change. The Rust devs first created a PR to change its internal representation for IP addresses in November 2020 [0], but multiple major libraries (including mio, which tokio depends on) incorrectly assumed that the representation for Rust's IP address type was the same as libc's representation and basically type punned between the two, so the change would result in UB. The Rust devs could have pushed out the change anyways, as the change didn't violate the backwards compatibility guarantee due to just being an internal implementation detail change, but the PR didn't actually land until July 2022 [1] because the Rust devs wanted to give the ecosystem time to migrate.

More discussion at [2].

[0]: https://github.com/rust-lang/rust/pull/78802

[1]: https://github.com/rust-lang/rust/pull/78802#event-709670882...

[2]: https://old.reddit.com/r/rust/comments/wcw93o/a_major_refact...

	▲	steveklabnik 5 days ago \| parent [-]
		Yes, this was a social issue more than a technical one. At the same time, I was affected by this breakage, and it took me all of ten minutes to fix. So I both understand the outrage, and agree with it in general, but also, it was a tad overblown, I think. Should they have done a slower rollout, like the IpAddr change? Probably. Is it the end of the world that they made a mistake? Nah. But if it happens more often, that's cause for concern.

▲

pjmlp 5 days ago | parent | prev [-]

I can write C++98 or C++11 code that will fail in a C++23 compiler, because C++ also isn't 100% backwards compatible.

▲

justcuriousab 5 days ago | parent [-]

But the changes required are generally significantly smaller and less frequent, right?

	▲	pjmlp 5 days ago \| parent [-]
		If the build breaks when changing the value of -std= (or equivalent), it hardly matters how big it is.