4 ms·

We used Scala in production at my previous job. It was great for the most part, but upgrading from 2.9 to 2.10 was a massive, massive pain. I think I spent near

We used Scala in production at my previous job. It was great for the most part, but upgrading from 2.9 to 2.10 was a massive, massive pain. I think I spent nearly a week on the refactor. We didn't even have that much code (relatively speaking); the majority of the time was spent on finding substitutes for the libraries which were irreparably broken, and rewriting client code against the new API. That's pretty damning, but we could have avoided the upgrade if the team had better communication, so I see this also partly as a human issue. That being said, I would be willing to use it again. I didn't have an issue with compilation speed, and the size/flexibility of the language wasn't really a problem; we wrote in what I believe is the idiomatic Scala style (immutable objects, FP). Going back to Java now, I SORELY miss lightweight lambda expressions, pattern matching, native Option type (that people actually use), and the emphasis on immutability.

trailfox 13y ago
Version compatibility is definitely a pain point, but as painful as that is I'd still pick that over using regular Java.
happy_dino 13y ago
Can you give some details what caused the issues in your the 2.9 -> 2.10 migration?
- rybosome 13y ago
  To be honest, I don't remember the technical specifics...too much time has passed. It wasn't so much that a breaking feature change required rewriting code as it was that a single failure propagated. One component written in Scala on which my project depended was upgraded to 2.10, and a backwards-incompatible change in case classes broke the ability to serialize/deserialize objects between my project and the other component. Upgrading my project to 2.10, several of the dependencies no longer compiled. I don't remember which ones specifically, but I believe one of them was a JSON library. We had to find libraries that fulfilled the same roles, then rewrite the code that used those libraries against the new APIs. It wasn't horrible in the sense of there being a nasty, hard-to-detect runtime bug, rather that it required basically redoing all of the "glue code" with respect to libraries. This wasn't painful enough to scare me away from Scala in the future, though it does make me leery of using Scala libraries from anything but top-tier vendors. That is, I'd use a library from Twitter, FourSquare, TypeSafe, Akka, etc. but never again from anything not widely known.

trailfox 13y ago

Version compatibility is definitely a pain point, but as painful as that is I'd still pick that over using regular Java.

happy_dino 13y ago

Can you give some details what caused the issues in your the 2.9 -> 2.10 migration?

rybosome 13y ago
To be honest, I don't remember the technical specifics...too much time has passed. It wasn't so much that a breaking feature change required rewriting code as it was that a single failure propagated. One component written in Scala on which my project depended was upgraded to 2.10, and a backwards-incompatible change in case classes broke the ability to serialize/deserialize objects between my project and the other component. Upgrading my project to 2.10, several of the dependencies no longer compiled. I don't remember which ones specifically, but I believe one of them was a JSON library. We had to find libraries that fulfilled the same roles, then rewrite the code that used those libraries against the new APIs. It wasn't horrible in the sense of there being a nasty, hard-to-detect runtime bug, rather that it required basically redoing all of the "glue code" with respect to libraries. This wasn't painful enough to scare me away from Scala in the future, though it does make me leery of using Scala libraries from anything but top-tier vendors. That is, I'd use a library from Twitter, FourSquare, TypeSafe, Akka, etc. but never again from anything not widely known.