I'll check it out; thanks!

Did you read the original "Notes" post? I thought it did a pretty good job of explaining why Rust-like ownership semantics are not necessarily at odds with having a garbage collector.

The research is the interviews he did with engineers. That sentence is obviously a simplification, especially since he immediately follows it with one about talking to a civil engineer who builds mines.

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.

Languages with dynamic typing and implicit large-integer types, such as Python and Ruby, generally just convert to that large-integer type.

I figured Java would probably define the behavior in the JVM, but based on a quick web search it sounds like it probably doesn't by default, but does provide library methods to add or subtract safely.

Rust guarantees a panic by default, but provides library methods for wrapping, saturating, and unchecked (i.e. unsafely opting back in to undefined behavior).

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

The post has been edited; it looks like someone on reddit made essentially the same point. You're right of course that void isn't a true type in Java, but the post now also discusses Void, which I suppose just shows how void infects the type system despite not being a type.

I work on a team that has some old projects in python that we're gradually deprecating. A major one is stuck on 3.7 because 3.8 added automatic async mocking (which is great!), but this broke the existing third-party async mocking framework and it's never been updated to be compatible with newer Python versions. So we'd have to invest time in porting all the tests from the 3rd-party framework to the standard library, but it's not worth it because we're hoping to deprecate the whole project soon anyway.

I think the point of the "BIG_GLOBAL_STATIC..." name is that global statics are bad, not that the syntax is ugly. That said, you're absolutely correct that combining channels with async code is the way to go.

What did you mean by "inevitably there are times you need to use spaces", then?

The one part of that that sounds weird to me is needing to change integration tests frequently when changing the code. Were you changing the behavior of existing functionality a lot?

Wouldn't the multiplexer run inside the terminal emulator? I don't use a multiplexer myself, but I thought it was independent of what emulator you use.