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
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.
"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.
I eventually opted to desugaring the scala completely, but we were already on the way out of scala by that point
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?
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
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.