As a veteran of a large scala project (which was re-written in go, so I'm not unbiased), no. I was generally not happy.
This was scala 2, so implicit resolution lookup was a big chunk of the problem. There's nothing at the call site that tells you what is happening. But even when it wasn't hidden in a companion object somewhere, it was still difficult because every import change had to be scrutinized as it could cause large changes in behavior (this caused a non-zero number of production issues).
They work well for anything you would use environment variables for, but a chunk of the ecosystem likes to use them for handlers (the signature being a Functor generally), which was painful
> There's nothing at the call site that tells you what is happening.
A decent IDE highlights it at the call site.
It's definitely an abusable feature, but I find it very useful. In most other languages you end up having to have completely invisible parameters (e.g. database session bound to the thread) because it would be too cumbersome to pass them explicitly. In Scala you have a middle ground option between completely explicit and completely invisible.
I'm not sure what you consider a decent scala ide, but it was a problem with IntelliJ in several of our code bases, and I'd have to crawl the implicit resolution path.
I eventually opted to desugaring the scala completely, but we were already on the way out of scala by that point
> it was a problem with IntelliJ in several of our code bases
It shouldn't be, unless you were using macros (always officially experimental) or something - I was always primarily an Eclipse guy but IntelliJ worked well. Did you not get the green underline?
We weren't using macros, but one of our major dependencies was (geotrellis).
Didn't seem to matter how close to geotrellis we were though. That being said, I'm willing to buy that it confused IntelliJ enough that it gave up on entire packages
Either way, we ported a couple of the abstractions from there to go and just used that. The build times plus getting away from sbt have been enough of a win to keep us on go, and that's before we get to the memory reduction on in-memory rasters
yeah that's what i thought, but maybe scala implicit param not being perfect will help finding a better linguistic trait (maybe they should enforce purity on these parameters)
IMO it is perfect, or at least better than anything else that's been found so far.
"Purity" means different things in different contexts. Ultimately you can give programmers more tools, but you can't get away from relying on their good judgement.
Not OP, but I briefly seconded to a team that used Scala at a big tech co and I was often frustrated by this feature specifically. They had a lot of code that consumed implicit parameters that I was trying to call from contexts they were not available.
Then again I guess it's better than a production outage because the thread-local you didn't know was a requirement wasn't available.
