It feels pretty obvious to me that the PR to add themselves was a "look how absurd the criteria is, that even this case would be included, am I really a tainted developer for having used an LLM once?", and it being merged seems to send the message "yes, any person is tainted by using an llm once"

I can't count the number of times I've seen this: "Now that I've disabled the server from starting, the app runs without issue. It is now complete and production-ready!"

Strictly speaking, you _can_ add new implementations in a non-breaking change, but they would have to be subtypes of an existing subtype of the sealed interface.

Yes, it is. So in Kotlin, "*non-exhaustive enums* are equivalent to *sealed interfaces*" isn't true, Kotlin sealed interfaces are equivalent to a normal, exhaustive enum in Rust.

Maybe what kotlin calls sealed interfaces are actually something else from a type-theoretic world, but kotlin's sealed interfaces _can_ promise that you won't add a new implementation, which does allow compiler checked exhaustive pattern matching: pl.kotl.in/iOXs1juXW

Effectively, because of this, yes, unwrap can be a footgun. But 90+% of your functions don't need to handle options, unlike go, where every pointer is implicitly an option.

Because I can take Option<&T> in one function, and handle the None case, and all the functions it calls can take &T, and statically know they don't need to check for null, even 10 layers away in a helper. If I take a pointer in go for my helper, I either check for null, or doc it expects non null

You probably want to enable optimization, by passing `-C opt-level=3` when comparing assembly, even more things will end up optimized away. godbolt.org/z/Gh3jnMEdY