BatmanAoD

This is probably the most well-researched piece of writing on the matter: https://www.hillelwayne.com/post/are-we-really-engineers/

Yes, it’s largely for SPAs, but you said “requires killing the web app”, and most web apps are SPAs.

Wow, of course he’s pretending the response is a misrepresentation of his opinion instead of defending it in good faith.

Well, not quite, since Rust got WebAssembly support quite early.

When reading the announcement post, I was indeed hoping they’d include an example word with two "m"s in a row, so I was glad to see the example here. I don’t mind it, but it does feel almost dishonest to exclude that case from their post.

A construct that’s not supported by g++ is not a superior alternative to a simple macro.

That said, once support is near-universal, it probably will be preferable.

I’m not sure I’d consider that “failing”. At first glance, I don’t mind the distinct “m” glyphs being juxtaposed. But perhaps I’d find it annoying after a while.

The key thing to understand is that in Rust, references are considered unique types. This means that &T is a separate type from T.

So, for #1, it is not saying that T implements Copy, it is saying that regardless of what T is, &T implements Copy. This is because, by definition, it is always valid to copy a shared reference, even if T itself is not Copy.

Part of the reason this is confusing is that traits often include references in their function signatures; and in particular, Clone::clone has the signature fn clone(&self) -> Self. So when T implements clone, it has a method that takes &T and returns T. But even though the signature takes &T, the type that implements Clone is T itself. (&T always implements Clone as well, just as it always implements Copy, but as with Copy, this is independent from whether T itself implements Clone. See for example the error message you get when explicitly cloning a shared reference: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=a1b80cc83570321868c4ad55ee3353dc)

Since Copy is a marker trait, it doesn’t have any associated methods making it explicit that Copy affects how &T can be used. However, Copy requires the type to implement Clone (even though you can implement Clone in terms of Copy) and implies that T can always be automatically created from &T without an explicit call to T::clone, so you can think of the “signature” for Copy as matching that of Clone, even though there’s no actual copy method.

For #2, I recommend thinking in terms of explicit types. Adding annotations, you get:

let mut x: Box = Box::new(42); *x = 84_i32;

The type of x is Box. You cannot assign an i32 to a Box; they’re different types! But the type of *x is i32, and thus you can assign 84 to it.

The trait used to make Box behave this way is DerefMut, which explicitly makes *x assignable: https://doc.rust-lang.org/std/ops/trait.DerefMut.html

You don’t even need an old compiler to compile an old edition! That’s part of the brilliance of the edition mechanism. An up-to-date compiler must be able to compile code from all editions; it can then statically link libraries from multiple different editions together.

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/