Indeed, if people would only use implicits the way Odersky recommends, I'd love Scala. The problem is, too many people do exactly what he warns about in this video. And so my love-hate relationship continues... :-)
Otherwise, refresh my memory, what was he warning about with implicits?
There's currently no way around definition site boilerplate (e.g. `implicit name: Type`); `implicit` keyword and providing a variable name are required. Implicit function types eliminate definition site boilerplate while providing function composition -- looks like a solid enhancement for FP in Scala.
What Odersky warns about is defining implicits on built-in types. Which IMO too often gets abused to hide poor design.
That PR [1] is (IMO thankfully) not merged yet (marked as on hold) and reminds me of the indentation-based syntax proposal - ambitious, far from consensus on it being 'a good thing' by actual users, full of workarounds or escape hatches being sought by everyone, almost unilateral and very little to suggest it's even solving the problem it claims to (and it's fuzzy on what that is, exactly)[2].
Matching Rust's rules on this seems like the source motivator for Odersky and that only leads me to recall a conversation I had with a friend on these two languages and about a dozen or so practical, dramatically boilerplate- or complexity-reducing solutions that library authors or I had coded up; these would be either outlawed or made into large, complex workarounds under this scheme (Rust rules).
Even in a codebase directly under my purview, we would have to duplicate implicits across modules (and keep them in sync), merge deliberately-separated modules and give up on some functionality altogether to support this proposal. These are mostly 'free' additional type safety constraints that we would just have to give up on.
I'm not against making changes to make implicits easier to 'see'[3] - I'd only say that an approach with the above problems that gets worked around anyway is not the solution.
[1]: https://github.com/lampepfl/dotty/pull/2060
[2]: Indeed even in this HN thread there are people criticising implicit parameters in a bunch of places (definitely not going away, IIRC Odersky likes them) - when people say 'they don't like implicits', between the various user demands they might well be removed in every variation.
[3]: Indeed in IntelliJ IDEA and Ensime, every implicit conversion is underlined at the point of use. In that thread, someone suggests making implicits importable only with a modifier.