Meanwhile Rust is noncompelling due to its syntax. It made a bunch of weird design choices (like putting class methods in separate `impl` blocks) that have ruined my chances of trying to use it for any personal projects.
1. Make class methods open to extension. This allows adding methods from other contexts, including other privacy contexts. Sure you could have dedicated syntax like C#'s extension methods, but these were added after the fact. If starting your language from scratch, while have two distinct syntaxes, when one will do?
2. Allows to add methods that only exist for some combinations of generic parameters. For example you can have a generic `Foo<T>` class, and then define a method `from_bar` that only exists for `Foo<Bar>`. Again, impl blocks may not be the only solution to this, but it is a highly cohesive one.
3. Lastly this is more philosophical, but it decouples the data definition from the method definition.
Not wanting to try Rust because its syntax is unfamiliar has to be the weakest reason, especially when the syntax has excellent reasons to be different.
Rust's own standard library gets a pass. For example the [T] (a slice of T) generic type is a built-in, and the core library defines methods on that type, but in terms of sorting it only provides sort_unstable - an unstable sort, and the associated variants of that sort.
Then Rust's alloc crate, which is optional, has a new impl block for [T] and it defines sort, a stable sort on this same type which is much faster than it might be otherwise because it uses a temporary buffer, hence it needs an allocator and can't live in core.
You are not allowed to do this for other people's types. If I make a Goose in crate A, and then you try to write an impl block for A::Goose so that you can add a fly method to it, that won't work. Rust obviously could allow this, but it would invite chaos, so they don't.
What you can do is invent a trait Flying and impl Flying for A::Goose
If Hannah is allowed to write
impl birds::Goose { fn fudge(&mut self) { self.counter += 1; } }
and Sarah is allowed to write
impl birds::Goose { fn fudge(&mut self) { self.counter -= 1; } }
... Now what happens when I call fudge on a Goose? Does it increment the counter? Or decrement the counter? If instead the program is rejected because of the ambiguity, whose fault is the ambiguity? Sarah's fault? Hannah's fault? Jim's fault?
If you import both traits you get an ambiguous function error and are asked to resolve which trait you want `<Goose as noises::Trait>::fudge(...)`.