Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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


Oh SBT is awful and I can see why drags down the reputation of the whole language. I stick to Maven and I don't understand why other people don't do the same.


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.


thanks a lot for your answer




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: