As for the implicit aspect, we already have a way to pass implicit parameters to functions: fields. These have the advantage to actually be visible, injectable, and their semantics can't change just because you modified one import line.
As for the implicit aspect, we already have a way to pass implicit parameters to functions: fields. These have the advantage to actually be visible, injectable, and their semantics can't change just because you modified one import line.
Scala neither has opaque syntax (see: many/most new languages borrowing its name:type format, smartly choosing [] over <> for type parameters, etc) nor does it have some weird execution model. Its a perfectly reasonable metric to use when talking about a normal/popular language, especially when people who don't even use the language complain about it being bloated and compare it to C++ which has a grammar twice the size of Scala. I really wish people would stop spreading FUD over these kinds of things :/
To be honest, this format was first introduced by ALGOL around 1960.
It does make more sense, though, compared to C's.
Note that Dotty's implicit approach is similar in that respect, it doesn't prescribe anything in terms of mutability/immutability.
But we've already gone down the path of implicits, they are the #1 complaint about Scala, the #1 reason why the compiler is so slow and one of the main reasons why people say that Scala code can be very hard to reason about. I can't believe Odersky is doubling down on the implicit approach with Dotty. He just seems to be stuck in a language design corner and not willing to look at other ways to approach this problem.
It's programming language design myopia.
Personally most of the “wtf is going on here” comes from implicit conversions and usage of symbols (both of which have thankfully gone out of style for the most part)
The real question is: does the team you work with share your love of implicits?
Implicits are fun to use but they lead to code that's very hard to follow, so it's not uncommon to come across people who love them but these same people don't always realize the kind of code they are writing until way later.
But in general I haven't heard that many complaints outside of the few places where we use them for type level programming (Shapeless. Where most of the complaints are related to compile times). But the goal is usually to hide this behind some library or easy to understand type class instance and using implicits and shapeless to automatically derive the instances.
In general all the type class based stuff relies on implicits to be really useful and haven't really heard any complaints related to that pattern from anyone once they actually understand what type classes are and what they are used for.
Almost all the other use we have for implicits is automatically passing some context around in the app. This is things like RequestContext traveling down through the app and transmitting it to the next service in the chain. Basically only used so you don't have to be manually passing it around all the time. (another common example of this is passing ExecutionContext around. Or the ctx: Context in scalac that Martin mentions which appears 2600 times. If having it as implicit parameter 2600 times is pain think about having to manually fill it in)
Implicits conversions is something we try to say away from if possible (there are some valid use cases for it but be careful with it)
Can implicit fans explain to me how I am supposed to navigate to the correct overloaded method in Magnet pattern? Even IDE's like intellij Idea have no idea what to navigate to. If its so hard of an IDE to figure out, how are humans supposed to deal with this.
Implicits are great, and allow you to do some really amazing things, but you have to be careful not to abuse them or risk making your code take forever to compile and be impossible to debug.
I've got a theory that the type of people doing overly complex Java enterprise (see EJB 2.1) 15 years ago haven't vanished, they're just doing Scala now.
Basically it allows you to write
def f[T](fMagnet: FMagnet[T]): X => Y
f(t) { x =>
// ...
}
instead of def f[T](t: T)(implicit tc: TC[T]): X => Y
f(t).apply { x =>
// ...
}
so just about removing one ".apply"(see https://github.com/akka/akka-http/issues/100 where i copy pasted the code bits from)
But yeah first time I read up on the magnet pattern it was a wtf moment.