I do kind of miss it though. Right now I’m pretty happy with Typescript...
To be clear, these complex features are still there, it's just that people tend to not use/overuse/abuse them as much. Just like how Python has metaclasses and import-hook metaprogramming, but it's not something that a typical developer has to deal with on a day-to-day or even year-to-year basis
Those thankfully have largely disappeared. The design space of programs in Scala is still large (detractors might say too large), but it's way better explored now and there's a much clearer idea of the various tradeoffs among the various approaches as well as how to harmonize one with another.
Implicit arguments... man I go back and forth on that so much. On the one hand every crazy tower of abstraction that grinds the compiler to a halt in Scala inevitably begins with implicit arguments and you can have a really rough time with them if your IDE doesn't support looking up implicit arguments. On the other hand, if you want ad-hoc polymorphism, implicit arguments are really useful, often far more so than inheritance.
My usual take on this is that you probably don't need ad-hoc polymorphism most of the time, which is my way of wriggling out of the dilemma.
For statically typed languages, implicit arguments (in some form or another) are really great at getting statically checked ad-hoc polymorphism.
But even in dynamically typed languages such as Clojure, ad-hoc polymorphism mechanisms bottom out at some form of implicitness at runtime. I assume you're referring to multimethods here (which generalize protocols, whose very existence is a performance hack akin to atoms vs volatile, so I'll focus just on multimethods)?
The entire lookup system based off of defmulti is really just the same thing as Scala's implicit system just at runtime rather than compile time, but even harder to understand IMO because it can change wildly at runtime. The same "spooky action at a distance" problems can result here.
The reason this isn't an issue in Clojure is that multimethods are very rarely used and instead a lot of code just specializes on vectors or maps (again going back to my point that you usually don't need ad-hoc polymorphism).
All languages have their own "implicits" - just not as a proper language concept, but for "special cases". The problem is, that while it gives developers are more stable/clear framework to work with, it also limits the development of the language itself.
If you look at Scala, implicits could be used to model typeclasses from haskell and method-syntax-extension. Other languages such as Kotlin have a dedicated language feature for that. Scala never needed that.
However, this power also ask for responsible usage of course. That is a drawback that can't be denied.
To be fair those are powered by two different mechanisms (implicit arguments and implicit conversions) that just so happened to share the same keyword name but are semantically quite different (and have been broken up in Scala 3).
But your overall point is well-taken.
You can call it like that, but in the end it is the same language feature: describing things in a scope as implicit and having the compiler resolve them by certain rules.
What happened in Scala 3 is just that they were named different to make clear when things get defined and when they get used - one without the other is useless though, hence to me it is the same concept or language feature.
Thankfully it won't. Scala 3 deconstructs implicits and discourages (or outright discards) the bad parts: http://dotty.epfl.ch/docs/reference/contextual/motivation.ht...
"Implicits" are useful for the Type class pattern and is available in Scala 3 with an improved syntax.
"Implicits" for implicit conversions is an ugly hack that should be avoided as much as possible and Scala 3 restricts it.
"Implicits" for extension methods is a clever hack, and Scala 3 provides a dedicated syntax for defining extension methods.
`import cats.implicits._`
Done.
And once you start understanding the typeclass hierarchy a little bit, finding the specific syntax and instances comes pretty naturally.
Cats imports bring in "implicit classes", which are a way to extend existing types with new methods, in a way that works even with parametric types in a type-safe way. That's the way to get ad-hoc polymorphism (aka typeclasses) in Scala.
Of course it does. And since Scala 3, it does suggest to you the imports you need for implicits. And IntelliJ does recommend imports even for Scala 2.
Regarding cats, the codebase has been restructured, so that you won't need the implicit imports (or not as much at least): https://meta.plasm.us/posts/2019/09/30/implicit-scope-and-ca... The trick there is that the Type class instances were moved to appropriate companion objects which are searched by the compiler by default and thus the used doesn't need to do any manual imports.