Comment by alblue | Hacker News Reader

Comment by alblue | Hacker News Reader

Parent Full thread

It's not inflammatory for the sake of it; the point is I wrote about this four years ago:

http://alblue.bandlem.com/2009/10/scala-is-still-not-enterpr...

and there has been very little change since that 2009 post and the 2013 post to show any kind of serious movements on these issues. For single teams based on small projects the ability to up and move all your tools (IDEs, build train, library dependencies) really isn't a problem; but if you're dealing with hundreds or thousands of users and tens of thousands of libraries, you simply can't do an all-in-one upgrade.

And no, 2.10.x and 2.10.y being compatible isn't something to crow about; it should have been the default. The fact that you can't compile or test code in Eclipse with the Typesafe developed Scala IDE plugin for anything other than that exact version is one reason why developers are moving to IntelliJ's Scala development tools.

Ironically the problem is that the Scala IDE is written in Scala, whereas the IntelliJ tool is written in Kotlin, and Kotlin doesn't have compatibility problems (plus, it shells out to the specific compiler instead of Eclipse's Scala tools which embed their own).

Yes, teams at the Guardian are using Scala - but only in teams of less than ten people, and where they don't need to share libraries across multiple users and clients. That still doesn't make it enterprise ready.

Sadly I feel that Rod Johnson's keynote presentation at ScalaDays - which pointed out the same things as this post, and was the trigger - is being ignored. Unfortunately Typesafe are also ignoring this advice, and until that changes we won't see Scala being adopted in large enterprises.

Scala had a chance back in the late 2000s to be the next Java. Now - even with Java 8 having been delayed so much - it's probably too little, too late.

From the article:

> This self-limiting process means that Scala will never truly die out; at any point, there are still more people who are new to Scala than people who have been burnt by it, so there’s always a fresh supply of people willing to believe that it can’t happen to them. The same is true of smokers, of course.

If that's not inflammatory for the sake of it I don't know what is.

> And no, 2.10.x and 2.10.y being compatible isn't something to crow about; it should have been the default.

The moving of the of the goalposts isn't helping your case that your not being inflammatory for the sake of it.

Few people are going to state that Scala doesn't have any problems. However, if you want to raise issues about the language, at least argue fairly and don't insult the users and developers of said language in the process.

I spent a long time trying to get the issue raised back in 2009.

http://alblue.bandlem.com/2009/08/modularity-for-scala.html http://alblue.bandlem.com/2009/09/draft-scala-modularity-req...

Key to both of these was 'real' backward compatibility (i.e. the compatibility between versions like 2.8 and 2.9, not the patch level compatibility that exists at the moment).

I'm not moving the goalposts here; the issue is that having 2.8.x compatible with 2.9.y (or 2.9.x with 2.10.y etc) is a key point where Scala has failed, and continues to fail.

Until this is fixed, Scala won't be enterprise ready.

Rod's point (from his Scala days keynote) is that in 5 years Scala has a chance of being 'the' language, but only if it gets the backward compatibility issues sorted between 2.x and 2.x+1.

My point was I made exactly the same argument almost 5 years ago and nothing has changed, and since the past is the best predictor of future performance it is a safe bet that in 5 years time Scala won't have solved that problem, and thus won't be applicable for large enterprises.

This isn't a rant against users of Scala, it's a critique of the development plans that doesn't see this is a problem, or is happy to use Scala as an experimental playground that isn't likely to get widespread usage in enterprise.

If you can fit all your organisation's development teams in a single conference room, these problems are never going to apply to you, since you can just mandate that everyone switches at a particular date. But for organisations with hundreds or thousands of developers such an all-in-one switch isn't feasible.

Reply on news.ycombinator.com