Hacker News Reader

Comment by ssmoot | Hacker News Reader

> most of these people have not gone through a Scala version switch, or seen the pain that it can cause, or extrapolated that out thinking what it will do for future releases.

Seriously oversold.

I have been through the 2.9 to 2.10 switch. Anyone's who's used Play over the past year has also (maybe unknowingly) been through that switch since the Play plugin was using SBT 0.12.x (and Scala 2.9.x) even if your code was compiled under Scala 2.10.x.

It was practically painless.

The worst that happens in reality is you have to wait a couple extra months for someone to release a new build of something you depend on (or heaven forbid, clone the source and build it yourself).

Contrast that with waiting years between stable releases and new features with some other popular languages.

I'll take Scala any day. It remind me a lot of the early c# days. And that's a good thing when it comes to really building up a language and what you can do with it.

View on HN

I think your feelings on this depend on the size of your codebase/team. For a smallish project it's no big deal. For something large upgrading can be a significant effort.

Foursquare is still on 2.9.2. We hope to move to 2.10 fairly soon but it's by no means painless.

Fair enough.

But "fairly soon"? 2.10 hasn't even been out a year! Think about that. It's pretty cool IMO. I mean, Scala's community at-large does in months what takes Ruby's years. And with fewer breaking changes, with better tooling to help you make the transition. That's really refreshing.

> The worst that happens in reality is you have to wait a couple extra months for someone to release a new build of something you depend on (or heaven forbid, clone the source and build it yourself).

I think a lot of people reading this (who haven't used Scala, and are used to e.g Ruby and Python) may be confusing the implications of source incompatibility with binary incompatibility.

Python 2 -> Python 3 had (has) source incompatibility, which is a nightmare to deal with, especially because the changes are of a nature that make it difficult to port code automatically and reliability. (Contrast with Go pre-1.0 -> Go 1.0, which had source incompatibility but an automated code transformation tool which, unlike Python's, guaranteed correct code for all the breaking changes introduced).

The issues with Scala's incompatibility are largely along the lines of binary incompatibility, which affects package management (and build tools), but doesn't have as much of an impact on breaking compilation of existing source code, which are the nightmares that people are used to thinking about in the Ruby/Python world.

(Edit: updated in response to dbaupp's comment to clarify the differences between "2to3" and "go fix")

> Python 2 -> Python 3 had (has) source incompatibility, which is a nightmare to deal with, especially because the changes are of a nature that make it difficult to port code automatically and reliability. (Contrast with Go pre-1.0 -> Go 1.0, which had source incompatibility but an automated code transformation tool).

I guess you're aware of this, but Python has the 2to3 tool[1], which does a lot of transformations automatically. (Obviously not all of them, but it's good enough that it's the recommended way[2] to support Python 2 and 3 in one codebase.)

[1]: http://docs.python.org/3.3/library/2to3.html

[2]: http://python3porting.com/2to3.html#running-2to3-on-install

That tool is good but the problem of Python 2 -> 3 wasn't just syntax incompatibility, but API changes that made many libraries hard to migrate until recent.

> The worst that happens in reality is you have to wait a couple extra months for someone to release a new build of something you depend on (or heaven forbid, clone the source and build it yourself).

Sure, if the package is activly maintained and/or open-source, this is true. That is not always the case though, and in my experience it usually isn't in the enterprise space.

Reply on news.ycombinator.com