8 ms·

Will Scala ever be enterprise-ready?

78 points by cryptos 13y ago

AlexanderDhoore 13y ago
I wonder how the JVM will compare to .NET in 10 years time.
- adamnemecek 13y ago
  They will both become just compatibility layers implemented on top of node.js. /s
  - deleted 13y ago
    [deleted]
  - _random_ 13y ago
    ...because single thread is enough for any task!
nonchalance 13y ago
Does scala follow semantic versioning? It sounds like they should still be in the 0.x stage if there are enough breaking changes to merit this discussion
- lmm 13y ago
  It follows semantic versioning at the source level, more or less (there are things like new keywords, but not breaking changes to the semantics of existing functionality). When a new minor version of scala comes out you bump up the number in your build tool and it fetches new versions of your libraries (we've standardized how to represent binary compatibility of libraries) and rebuilds your program. It's really no big deal.
- jkrems 13y ago
  0.x does not mean "unstable" in semantic versioning. If you don't have any stable interface, not using a version would maybe semantic. With semantic versioning they should rather be at Scala 11.x or 23.x (each breaking change bumps the major).
  - nonchalance 13y ago
    http://semver.org/ http://semver.org/ > Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable. major version 0 was specifically designed for this use case
    - ssmoot 13y ago
      The public API at the source level is very stable. I mean, my major touchstone is Ruby-land, and over there there's nothing like it. Even point releases of libraries or the language itself can and will routinely break your code. I've never seen that happen with Scala. Not saying it definitively hasn't, but I certainly haven't experienced it, and that's not because I'm using less of Scala than I did of Ruby... It feels like shifting the goal posts to say that binary compatibility should be a bigger factor in versioning (and it's already represented in the minor version) when you've already arguably got better stability guarantees than many of it's contemporaries. Unless we really are limiting the conversation to Java. But how do you compete with "we never break compatibility at the cost of never evolving"?
- ssmoot 13y ago
  Yes it does. AFAICT it's working well. There are 5 releases in the 2.10.x line and I haven't had a compatibility issue between any of them. The deal is (I think) that Scala is a much quicker evolving language than say Ruby. Ruby 2.0 was rumored to be released the better part of a decade ago (anyone else remember Pickaxe 1.8, pre-Rails, saying that eventually parenthesis would no longer be optional in Ruby 2.0?). Scala has developed new features at a pretty quick pace. By and large this doesn't mean breaking source compatibility. Most source seems to be forwards compatible, or require minimal effort. The reason this comes up at all is because of Package Management. Where Ruby only needs to worry about a parser compatibility level, Scala has to worry about binary compatibility in packaging since it lives in Java's packaging ecosystem. Since Maven doesn't encode a binary version, breaking binary compatibility (say you added a new default argument to a method signature, that wouldn't otherwise break source compatibility, or you introduced a new superclass for a return value) means breaking your packages. SBT gets around this by encoding the binary version (the Scala minor version) in the artifact name. Some day this will all probably get sorted out. It hasn't been much of a pain point for me personally. Most 3rd party binary packages are Java packages, which are binary compatible since Java 5(?). For the few Scala libs you might depend on, you might as likely be using a source dependency from Github, which means you don't need to worry since you're compiling it yourself, or most popular packages will have published versions with a new compiler pretty quickly. The next time this will be an issue is when Scala 2.11.0 is released. And AFAIK that should introduce any breaking changes for source code at this point. So if you want to move to Scala 2.11.0 you either wait for package authors to cross-compile to it, or you build it yourself as a source dependency if you have access to the code.
  - alblue 13y ago
    Just FYI; semantic versioning is split into three numbers: major.minor.micro Changes in .micro are assumed to be interchangeable. Scala does this. Changes in .minor are assumed to be backwardly compatible, but with new features added. Scala does not do this, it requires a recompile. Major versions indicate a completely incompatible change. If Scala were to follow semantic versioning, it would need to coalesce the first two versions together and have e.g. 210 and 211 to indicate that they are not compatible with each other.
- eeperson 13y ago
  Scala kind of follows semantic versioning. If the first 2 numbers are the same then they are binary compatible (at least starting with version 2.9.0). So version 2.9.1 is compatible with 2.9.3. Otherwise they are still source compatible, aside from deprecations, they just need to be recompiled (at least starting with 2.8.0). This article is actually filled with a bunch of mis-information about Scala version compatiblity. For example, the author states: > There has never been a Scala release where it’s been possible to compile and run an older library with a newer version of a program. This is not true at all. There are multiple libraries that support several binary incompatible versions of Scala from the same codebase. Also, as mentioned previously, there are multiple releases of Scala that are binary compatible with each other.
  - alblue 13y ago
    You can't take a library compiled with Scala 2.8 and have it run with Scala 2.10. You can take a library compiled with Java 1.4 and have it run with Java 7. That's the key point that is made here. The fact that version compatibility at the patch level is laughable; that should have been the default, not an additional selling point later. The problem is that it's impossible to create a library (like log4j) and then make it available/support it across different versions. Each time you need to release a build, you have to build different versions - one for 2.9, one for 2.10 - in order to work. At some point that breaks down; one key library in your chain no longer compiles on 2.9, so you have to move everything to 2.10 to do further work. It's the transitive closure for all those libraries and their dependencies that will get you in the end.
    - eeperson 13y ago
      Yes, you can't combine libraries compiled for 2.10 and 2.8. No one disputes this. Yes, this is a problem. How much will vary from project to project. However, while you may think that binary compatibility is 'laughable', to imply that there have been no improvements in this area is disingenuous. The presence of this compatibility contradicts the claims you made in the article. You also gloss over source compatibility. Which, again, contradicts the claims you made in the article.
wheaties 13y ago
I think a lot of what people were ruffled about was his remarks about reinventing the wheel. There are preferred ways of writing code in all languages, some more extreme than others. However, while Scala is backwards compatible with Java, it's not always as nice to use a library which is firmly rooted in Java.
lmm 13y ago
Most of the "enterprises" I know are still on Java 6. So clearly the need for a "big-bang" migration is not enough to turn enterprises off a language. To talk about minor version numbers is to miss the point, I think. Scala 2.10 brought more new features than java 7, and scala 2.11 will bring more new features than java 8. It's just happening faster.
- laureny 13y ago
  That's part of the problem: Scala needs fewer features and more focus in other areas, such as tool support (IDE's mostly) and backward compatibility. The problem is that Scala's leadership is conflicted: you have Typesafe trying to turn it into a product and the researchers inside Typesafe more focused on producing papers for their academic careers, and therefore steering the boat in a direction that conflicts with pleasing new users.
  - ssmoot 13y ago
    I don't think there's any new feature in 2.10.x that I'd want to give up. Scala 2.11 is modularization (meh), Scripting Engine support (cool), REPL improvements (ok), and Async/Await support (YES!). I wouldn't want to lose those in favor of sitting still. I mean, when people talk about "Scala needs fewer features" what is it exactly? XML? Well that's being modularized out in 2.11. Still seems like a pretty weird thing to stake a claim on though. What features exactly need to be stripped? And BTW, the IDE support (in IntelliJ at least) is pretty good. Maybe not amazing, but coming from ST2+Ruby to IntelliJ+Scala it's night and day. Doesn't seem to be nearly the wasteland to me that some comments imply.
  - eeperson 13y ago
    Why do you think that those doing research inside Typesafe are steering the language in a direction that is user hostile? From what I have seen the effort appears to be more focused on simplifying the language in order to make it easier to use: http://www.infoq.com/presentations/data-types-issues http://www.infoq.com/presentations/data-types-issues
    - 13y ago
saosebastiao 13y ago
I'd add one thing to the list of requirements before it is enterprise-ready: faster compile times.
- lmm 13y ago
  You're right, C++ will never be enterprise-ready. (Scala could indeed really do with faster compiles, but I think that's actually less of a problem for enterprises than it is for the agile startup world)
  - seanmcdirmid 13y ago
    A lot of money has been invested in infrastructure to deal with C++ slow compiles and make it more feasible; Google for example has some amazing build reuse and caching tech. There are many other ways of dealing with slow compiles vs. just making compiles go faster; e.g. you could make them more incremental (which is also useful for IDE use).
    - lmm 13y ago
      Scala already has some very good incremental compilation tech, built into its IDE support. For day-to-day coding the compile times aren't an issue (though they can become one if you like to e.g. make releases frequently).
      - harryh 13y ago
        This probably depends on how much code your compiling. For small projects it's not an issue. For larger projects it can be a very very big issue.
      - bcbrown 13y ago
        Ugh, ever since we added scala to our projects, the compile-time has doubled. It's certainly an issue to me. It makes it harder to get into flow when I have to wait several minutes for compilation.
_no__ 13y ago
Not until Set is not a Functor
- gclaramunt 13y ago
  To be pedantic, you mean Set to not implement map, right?
ssmoot 13y ago
> 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.
- chimeracoder 13y ago
  > 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")
  - dbaupp 13y ago
    > 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 http://docs.python.org/3.3/library/2to3.html [2]: http://python3porting.com/2to3.html#running-2to3-on-install http://python3porting.com/2to3.html#running-2to3-on-install
ExpiredLink 13y ago
Odersky is already working on a Scala successor: http://www.infoq.com/presentations/data-types-issues http://www.infoq.com/presentations/data-types-issues
- eeperson 13y ago
  That isn't intended to be a Scala successor. That is intended to be integrated in future versions of Scala.
  - auggierose 13y ago
    lol :-) Sums up what the whole fuss is about. Scala is a great language. It gives me OO + functional in one great package that has no equal out there. Couldn't do without it.
dman 13y ago
As a former lisper I cant but help feel that haskell and scala are the modern lisps. In 10 years all industrial languages will be undeniably influenced by these pioneers but the languages itself wont be the next big thing.
- ssmoot 13y ago
  Maybe. But it feels like Functional programming at least is a thing now. I can't see the next decade's language remaining an imperative bog... I cringed at seeing the following Ruby today: "error#{'s' if errors.size > 1}" :-)
  - codygman 13y ago
    Did you start that paragraph with a "Maybe" on purpose? lol
- lord_quas 13y ago
  Just wondering, how do you feel about clojure?
  - dman 13y ago
    Sadly it came up after I had already shifted to Python so I lack the experience to talk credibly about Clojure.
- Dewie 13y ago
  Haskell seems more united than the lisps, though. There doesn't seem to be a lot of 'dialects'/direct descendants, with the possible exception of languages that try to achieve specific things (Agda, Elm...).
pron 13y ago
Other than the community and leadership issues mentioned in the article, Scala will never be enterprise ready because I can't think of a worse language for the enterprise. Large IT departments working on multi-MLOC codebases need a solid, clear language. Scala was promising back when it was meant to be "a better Java". And you know why people liked it? Mostly because it had lambdas and traits - two features that are in Java 8. Since then, Scala has become a sort of a testbed for new ideas in compiler technology. Consider this – it's basically got three complete type systems: an OO, inheritance based type system, a Haskell-like algebraic type system (sealed traits and case classes), and a duck-typed type system (structural types). Each of these type systems has been enough to write good, complex software, on each own. Scala's got all three, while at the same time missing on all of their advantages. It doesn't have Haskell's type safety and purity (or type inference). It doesn't have OO's simple, highly extensible, and just-powerful-enough type system, because it's so big and complicated, and it doesn't have duck-typing's care-freedom, because it's so heavy. Oh, and it's got macros, too, just for the heck of it. I know some people like it because they have fun writing lisp, Haskell, Java and JavaScript in the same file and have it compiled by just one compiler. Yeah, it's a cool compiler. But seriously, it doesn't offer anything enterprise would want. It doesn't offer safety; it doesn't offer simplicity; it doesn't offer familiarity. It doesn't even offer much compatibility: it's much harder to integrate Java with Scala than with Clojure or Groovy, let alone Kotlin. And I'm willing to bet that almost all large companies that currently employ Scala, do it because of its original promise of being a better Java. But if you're a superset of about 4 language families, than you clearly can't a better Java. For those who want that productivity boost while maintaining familiarity and compatibility, there's Kotlin. And Java 8, of course.
- runT1ME 13y ago
  >And you know why people liked it? Mostly because it had lambdas and traits - two features that are in Java 8. I don't think this is the main reason people like it. Java's lambdas are also inferior to Scala's. >a Haskell-like algebraic type system (sealed traits and case classes) What do case classes and traits have to do with types? >It doesn't have Haskell's type safety How so? Can you explain how you think Scala isn't sound/typesafe? >It doesn't have OO's simple, highly extensible, and just-powerful-enough type system Uhm, can you explain to me an example of a simple OO type system that is 'just powerful enough'? Because most of the ones I know of are broken, and Scala easily has the best OO type system. C#, java, Go, etc. are all either missing generics (lolwut) or completely fucked up variance.
manishsharan 13y ago
For Scala to gain any traction with the enterprise market, it will need strong backing from enterprise middleware vendors. If IBM, HP, Oracle , RedHat and VMWare start shipping IDEs and libraries compatible with Scala and start pushing Scala over Java, only then would the development managers in large enterprises would give Scala a fair shake. And that is unlikely to happen as these vendors have made huge investments in Java that they are not going to cannibalize. Until then it Java or C# only for the enterprise s/w development; the silver lining is that Java 8 is a significant improvement. On a personal note, as a java programmer I do not find Scala worth the learning curve. I am into Clojure for my personal/ hobby/ bootstrap programming because it forces me to think differently about programming and I enjoy that.
modersky 13y ago
The blog post and question is somewhat inflammatory (no wonder it gets upvoted so readily). Scala has been in category "adopt" in Thoughtworks Radar for a while now. http://www.thoughtworks.com/radar http://www.thoughtworks.com/radar It's not only Enterprise ready, but is in production in a large number of enterprises in many different sectors.
- necubi 13y ago
  (For those unaware, modersky is the creator of Scala).
- alblue 13y ago
  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-enterprise-ready.html 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.
adriaanm 13y ago
Smooth upgrades between major Scala releases is one of our[1] two top priorities (the other being compiler performance). I disagree that "nothing" has happened since 2.8 to improve Scala's enterprise readiness (the Scala team at Typesafe does just that). Binary compatibility is one (desirable) way of making upgrades smoother (but certainly no panacea). We haven't reached the point yet where we're willing to freeze the whole library across major releases, but we're working towards this. In Scala 2.11.x, we've slimmed down the library (by deprecating more aggressively and modularizing), so as to reduce the core to something that we're comfortable enforcing binary compatibility for. In the mean time, we're working on mitigating the upgrade pain with tooling and "community outreach". We're working with the developers of core Scala projects to assist them in cross-building their projects, and we're investing in tooling to automate this. With every 2.11 milestone we're working to get the eco-system in shape for the final 2.11.0 release, so that your dependencies will be available when you upgrade. We're also working on gaining engineering experience in enforcing full backwards and forwards binary compatible, albeit only between minor releases of Scala 2.10.x (enforced with https://github.com/typesafehub/migration-manager https://github.com/typesafehub/migration-manager). This means code compiled against Scala 2.10.x is guaranteed to run on a Scala 2.10.y run time (you're free to pick x -- a different one for each dependency, even -- and y). Scala 2.10 gets a bugfix release every 3 months, and a lot of the features we're developing for 2.11 (as modules) will be available for 2.10 as well. Happy to hear your thoughts and experiences in upgrading! Several of our clients and other big Scala users have reported successful upgrades from 2.9 to 2.10, though others are still happily running on 2.9. Doesn't that make us more enterprisey? [1] I'm the Scala tech lead at Typesafe.
ffk 13y ago
I think this is the wrong question to ask. It's clearly enterprise ready considering enterprises are actively using it in their critical infrastructure. A better question is "Will scala ever have major release backwards compatibility as a feature." This isn't to discredit the author's viewpoint. I strongly agree with many of the assertions he makes. Backwards compatibility is a major problem. Back to backwards compatibility (wee, puns), I think a major part of it is not due to ABI changes. The JVM has very well defined entry and exit points to deal with this. The problem seems to stem more with the libraries. As long as the libraries keep changing at a fast rate, the scala cmomunity will never achieve backwards compatibility at the level this author wants to achieve. Until typesafe makes a strong commitment to put APIs through a sunsetting lifecycle with deprecation, it will continue to be a problem. Fortunately, they have made a commitment to not make breaking changes in minor releases. E.g. 2.10.0 compiled applications should continue to work with all release 2.10.* runtimes.
voidlogic 13y ago
Enterprise ready is such a useless term because the readiness is dependent on the particular enterprise asking the question. For some enterprises Scala or even Go are "enterprise ready", for others, it will be decades.
kailuowang 13y ago
Scala has the potential to become an enterprise useful language because people can write a simple script to monitor how many mutable states appears in the codebase.
dxbydt 13y ago
Will Scala ever be enterprise-ready? I don't know. Will enterprise ever be Scala-ready ? No. And I'm not being flippant here.
brucefancher 13y ago
No. Next question.
samlavery 13y ago
Scala is a fine scotch, but at a very young age. It's version 2.10.3, everything is still changing fairly rapidly. All it needs to be adopted in a more widespread manner is to improve it's approachability. Even for engineers who've been programming for years, Scala is hard to grok. The vast deviations in style don't help. I'm betting it's going to take over the world in a few years, especially as it expands it foothold in the Big Data space.
volune 13y ago
Twitter thinks so...
jemeshsu 13y ago
Scala will be enterprise-ready when there are readily available affordable Scala programmers. If you can master Scala and write complex Scala codes, most likely enterprise crud jobs does not interest you.
stormcrowsx 13y ago
Pretty sure its already in enterprises, perhaps the more cutting edge ones but nonetheless it powers some very large websites.

78 points by cryptos 13y ago

AlexanderDhoore 13y ago

I wonder how the JVM will compare to .NET in 10 years time.

adamnemecek 13y ago
They will both become just compatibility layers implemented on top of node.js. /s
- deleted 13y ago
  [deleted]
- _random_ 13y ago
  ...because single thread is enough for any task!

nonchalance 13y ago

Does scala follow semantic versioning? It sounds like they should still be in the 0.x stage if there are enough breaking changes to merit this discussion

lmm 13y ago
It follows semantic versioning at the source level, more or less (there are things like new keywords, but not breaking changes to the semantics of existing functionality). When a new minor version of scala comes out you bump up the number in your build tool and it fetches new versions of your libraries (we've standardized how to represent binary compatibility of libraries) and rebuilds your program. It's really no big deal.
jkrems 13y ago
0.x does not mean "unstable" in semantic versioning. If you don't have any stable interface, not using a version would maybe semantic. With semantic versioning they should rather be at Scala 11.x or 23.x (each breaking change bumps the major).
- nonchalance 13y ago
  http://semver.org/ http://semver.org/ > Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable. major version 0 was specifically designed for this use case
  - ssmoot 13y ago
    The public API at the source level is very stable. I mean, my major touchstone is Ruby-land, and over there there's nothing like it. Even point releases of libraries or the language itself can and will routinely break your code. I've never seen that happen with Scala. Not saying it definitively hasn't, but I certainly haven't experienced it, and that's not because I'm using less of Scala than I did of Ruby... It feels like shifting the goal posts to say that binary compatibility should be a bigger factor in versioning (and it's already represented in the minor version) when you've already arguably got better stability guarantees than many of it's contemporaries. Unless we really are limiting the conversation to Java. But how do you compete with "we never break compatibility at the cost of never evolving"?
ssmoot 13y ago
Yes it does. AFAICT it's working well. There are 5 releases in the 2.10.x line and I haven't had a compatibility issue between any of them. The deal is (I think) that Scala is a much quicker evolving language than say Ruby. Ruby 2.0 was rumored to be released the better part of a decade ago (anyone else remember Pickaxe 1.8, pre-Rails, saying that eventually parenthesis would no longer be optional in Ruby 2.0?). Scala has developed new features at a pretty quick pace. By and large this doesn't mean breaking source compatibility. Most source seems to be forwards compatible, or require minimal effort. The reason this comes up at all is because of Package Management. Where Ruby only needs to worry about a parser compatibility level, Scala has to worry about binary compatibility in packaging since it lives in Java's packaging ecosystem. Since Maven doesn't encode a binary version, breaking binary compatibility (say you added a new default argument to a method signature, that wouldn't otherwise break source compatibility, or you introduced a new superclass for a return value) means breaking your packages. SBT gets around this by encoding the binary version (the Scala minor version) in the artifact name. Some day this will all probably get sorted out. It hasn't been much of a pain point for me personally. Most 3rd party binary packages are Java packages, which are binary compatible since Java 5(?). For the few Scala libs you might depend on, you might as likely be using a source dependency from Github, which means you don't need to worry since you're compiling it yourself, or most popular packages will have published versions with a new compiler pretty quickly. The next time this will be an issue is when Scala 2.11.0 is released. And AFAIK that should introduce any breaking changes for source code at this point. So if you want to move to Scala 2.11.0 you either wait for package authors to cross-compile to it, or you build it yourself as a source dependency if you have access to the code.
- alblue 13y ago
  Just FYI; semantic versioning is split into three numbers: major.minor.micro Changes in .micro are assumed to be interchangeable. Scala does this. Changes in .minor are assumed to be backwardly compatible, but with new features added. Scala does not do this, it requires a recompile. Major versions indicate a completely incompatible change. If Scala were to follow semantic versioning, it would need to coalesce the first two versions together and have e.g. 210 and 211 to indicate that they are not compatible with each other.
eeperson 13y ago
Scala kind of follows semantic versioning. If the first 2 numbers are the same then they are binary compatible (at least starting with version 2.9.0). So version 2.9.1 is compatible with 2.9.3. Otherwise they are still source compatible, aside from deprecations, they just need to be recompiled (at least starting with 2.8.0). This article is actually filled with a bunch of mis-information about Scala version compatiblity. For example, the author states: > There has never been a Scala release where it’s been possible to compile and run an older library with a newer version of a program. This is not true at all. There are multiple libraries that support several binary incompatible versions of Scala from the same codebase. Also, as mentioned previously, there are multiple releases of Scala that are binary compatible with each other.
- alblue 13y ago
  You can't take a library compiled with Scala 2.8 and have it run with Scala 2.10. You can take a library compiled with Java 1.4 and have it run with Java 7. That's the key point that is made here. The fact that version compatibility at the patch level is laughable; that should have been the default, not an additional selling point later. The problem is that it's impossible to create a library (like log4j) and then make it available/support it across different versions. Each time you need to release a build, you have to build different versions - one for 2.9, one for 2.10 - in order to work. At some point that breaks down; one key library in your chain no longer compiles on 2.9, so you have to move everything to 2.10 to do further work. It's the transitive closure for all those libraries and their dependencies that will get you in the end.
  - eeperson 13y ago
    Yes, you can't combine libraries compiled for 2.10 and 2.8. No one disputes this. Yes, this is a problem. How much will vary from project to project. However, while you may think that binary compatibility is 'laughable', to imply that there have been no improvements in this area is disingenuous. The presence of this compatibility contradicts the claims you made in the article. You also gloss over source compatibility. Which, again, contradicts the claims you made in the article.

wheaties 13y ago

I think a lot of what people were ruffled about was his remarks about reinventing the wheel. There are preferred ways of writing code in all languages, some more extreme than others. However, while Scala is backwards compatible with Java, it's not always as nice to use a library which is firmly rooted in Java.

lmm 13y ago

Most of the "enterprises" I know are still on Java 6. So clearly the need for a "big-bang" migration is not enough to turn enterprises off a language. To talk about minor version numbers is to miss the point, I think. Scala 2.10 brought more new features than java 7, and scala 2.11 will bring more new features than java 8. It's just happening faster.

laureny 13y ago
That's part of the problem: Scala needs fewer features and more focus in other areas, such as tool support (IDE's mostly) and backward compatibility. The problem is that Scala's leadership is conflicted: you have Typesafe trying to turn it into a product and the researchers inside Typesafe more focused on producing papers for their academic careers, and therefore steering the boat in a direction that conflicts with pleasing new users.
- ssmoot 13y ago
  I don't think there's any new feature in 2.10.x that I'd want to give up. Scala 2.11 is modularization (meh), Scripting Engine support (cool), REPL improvements (ok), and Async/Await support (YES!). I wouldn't want to lose those in favor of sitting still. I mean, when people talk about "Scala needs fewer features" what is it exactly? XML? Well that's being modularized out in 2.11. Still seems like a pretty weird thing to stake a claim on though. What features exactly need to be stripped? And BTW, the IDE support (in IntelliJ at least) is pretty good. Maybe not amazing, but coming from ST2+Ruby to IntelliJ+Scala it's night and day. Doesn't seem to be nearly the wasteland to me that some comments imply.
- eeperson 13y ago
  Why do you think that those doing research inside Typesafe are steering the language in a direction that is user hostile? From what I have seen the effort appears to be more focused on simplifying the language in order to make it easier to use: http://www.infoq.com/presentations/data-types-issues http://www.infoq.com/presentations/data-types-issues
  - 13y ago

saosebastiao 13y ago

I'd add one thing to the list of requirements before it is enterprise-ready: faster compile times.

lmm 13y ago
You're right, C++ will never be enterprise-ready. (Scala could indeed really do with faster compiles, but I think that's actually less of a problem for enterprises than it is for the agile startup world)
- seanmcdirmid 13y ago
  A lot of money has been invested in infrastructure to deal with C++ slow compiles and make it more feasible; Google for example has some amazing build reuse and caching tech. There are many other ways of dealing with slow compiles vs. just making compiles go faster; e.g. you could make them more incremental (which is also useful for IDE use).
  - lmm 13y ago
    Scala already has some very good incremental compilation tech, built into its IDE support. For day-to-day coding the compile times aren't an issue (though they can become one if you like to e.g. make releases frequently).
    - harryh 13y ago
      This probably depends on how much code your compiling. For small projects it's not an issue. For larger projects it can be a very very big issue.
    - bcbrown 13y ago
      Ugh, ever since we added scala to our projects, the compile-time has doubled. It's certainly an issue to me. It makes it harder to get into flow when I have to wait several minutes for compilation.

_no__ 13y ago

Not until Set is not a Functor

gclaramunt 13y ago
To be pedantic, you mean Set to not implement map, right?

ssmoot 13y ago

> 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.

chimeracoder 13y ago
> 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")
- dbaupp 13y ago
  > 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 http://docs.python.org/3.3/library/2to3.html [2]: http://python3porting.com/2to3.html#running-2to3-on-install http://python3porting.com/2to3.html#running-2to3-on-install

ExpiredLink 13y ago

Odersky is already working on a Scala successor: http://www.infoq.com/presentations/data-types-issues http://www.infoq.com/presentations/data-types-issues

eeperson 13y ago
That isn't intended to be a Scala successor. That is intended to be integrated in future versions of Scala.
- auggierose 13y ago
  lol :-) Sums up what the whole fuss is about. Scala is a great language. It gives me OO + functional in one great package that has no equal out there. Couldn't do without it.

dman 13y ago

As a former lisper I cant but help feel that haskell and scala are the modern lisps. In 10 years all industrial languages will be undeniably influenced by these pioneers but the languages itself wont be the next big thing.

ssmoot 13y ago
Maybe. But it feels like Functional programming at least is a thing now. I can't see the next decade's language remaining an imperative bog... I cringed at seeing the following Ruby today: "error#{'s' if errors.size > 1}" :-)
- codygman 13y ago
  Did you start that paragraph with a "Maybe" on purpose? lol
lord_quas 13y ago
Just wondering, how do you feel about clojure?
- dman 13y ago
  Sadly it came up after I had already shifted to Python so I lack the experience to talk credibly about Clojure.
Dewie 13y ago
Haskell seems more united than the lisps, though. There doesn't seem to be a lot of 'dialects'/direct descendants, with the possible exception of languages that try to achieve specific things (Agda, Elm...).

pron 13y ago

Other than the community and leadership issues mentioned in the article, Scala will never be enterprise ready because I can't think of a worse language for the enterprise. Large IT departments working on multi-MLOC codebases need a solid, clear language. Scala was promising back when it was meant to be "a better Java". And you know why people liked it? Mostly because it had lambdas and traits - two features that are in Java 8. Since then, Scala has become a sort of a testbed for new ideas in compiler technology. Consider this – it's basically got three complete type systems: an OO, inheritance based type system, a Haskell-like algebraic type system (sealed traits and case classes), and a duck-typed type system (structural types). Each of these type systems has been enough to write good, complex software, on each own. Scala's got all three, while at the same time missing on all of their advantages. It doesn't have Haskell's type safety and purity (or type inference). It doesn't have OO's simple, highly extensible, and just-powerful-enough type system, because it's so big and complicated, and it doesn't have duck-typing's care-freedom, because it's so heavy. Oh, and it's got macros, too, just for the heck of it. I know some people like it because they have fun writing lisp, Haskell, Java and JavaScript in the same file and have it compiled by just one compiler. Yeah, it's a cool compiler. But seriously, it doesn't offer anything enterprise would want. It doesn't offer safety; it doesn't offer simplicity; it doesn't offer familiarity. It doesn't even offer much compatibility: it's much harder to integrate Java with Scala than with Clojure or Groovy, let alone Kotlin. And I'm willing to bet that almost all large companies that currently employ Scala, do it because of its original promise of being a better Java. But if you're a superset of about 4 language families, than you clearly can't a better Java. For those who want that productivity boost while maintaining familiarity and compatibility, there's Kotlin. And Java 8, of course.

runT1ME 13y ago
>And you know why people liked it? Mostly because it had lambdas and traits - two features that are in Java 8. I don't think this is the main reason people like it. Java's lambdas are also inferior to Scala's. >a Haskell-like algebraic type system (sealed traits and case classes) What do case classes and traits have to do with types? >It doesn't have Haskell's type safety How so? Can you explain how you think Scala isn't sound/typesafe? >It doesn't have OO's simple, highly extensible, and just-powerful-enough type system Uhm, can you explain to me an example of a simple OO type system that is 'just powerful enough'? Because most of the ones I know of are broken, and Scala easily has the best OO type system. C#, java, Go, etc. are all either missing generics (lolwut) or completely fucked up variance.

manishsharan 13y ago

For Scala to gain any traction with the enterprise market, it will need strong backing from enterprise middleware vendors. If IBM, HP, Oracle , RedHat and VMWare start shipping IDEs and libraries compatible with Scala and start pushing Scala over Java, only then would the development managers in large enterprises would give Scala a fair shake. And that is unlikely to happen as these vendors have made huge investments in Java that they are not going to cannibalize. Until then it Java or C# only for the enterprise s/w development; the silver lining is that Java 8 is a significant improvement. On a personal note, as a java programmer I do not find Scala worth the learning curve. I am into Clojure for my personal/ hobby/ bootstrap programming because it forces me to think differently about programming and I enjoy that.

modersky 13y ago

The blog post and question is somewhat inflammatory (no wonder it gets upvoted so readily). Scala has been in category "adopt" in Thoughtworks Radar for a while now. http://www.thoughtworks.com/radar http://www.thoughtworks.com/radar It's not only Enterprise ready, but is in production in a large number of enterprises in many different sectors.

necubi 13y ago
(For those unaware, modersky is the creator of Scala).
alblue 13y ago
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-enterprise-ready.html 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.

adriaanm 13y ago

Smooth upgrades between major Scala releases is one of our[1] two top priorities (the other being compiler performance). I disagree that "nothing" has happened since 2.8 to improve Scala's enterprise readiness (the Scala team at Typesafe does just that). Binary compatibility is one (desirable) way of making upgrades smoother (but certainly no panacea). We haven't reached the point yet where we're willing to freeze the whole library across major releases, but we're working towards this. In Scala 2.11.x, we've slimmed down the library (by deprecating more aggressively and modularizing), so as to reduce the core to something that we're comfortable enforcing binary compatibility for. In the mean time, we're working on mitigating the upgrade pain with tooling and "community outreach". We're working with the developers of core Scala projects to assist them in cross-building their projects, and we're investing in tooling to automate this. With every 2.11 milestone we're working to get the eco-system in shape for the final 2.11.0 release, so that your dependencies will be available when you upgrade. We're also working on gaining engineering experience in enforcing full backwards and forwards binary compatible, albeit only between minor releases of Scala 2.10.x (enforced with https://github.com/typesafehub/migration-manager https://github.com/typesafehub/migration-manager). This means code compiled against Scala 2.10.x is guaranteed to run on a Scala 2.10.y run time (you're free to pick x -- a different one for each dependency, even -- and y). Scala 2.10 gets a bugfix release every 3 months, and a lot of the features we're developing for 2.11 (as modules) will be available for 2.10 as well. Happy to hear your thoughts and experiences in upgrading! Several of our clients and other big Scala users have reported successful upgrades from 2.9 to 2.10, though others are still happily running on 2.9. Doesn't that make us more enterprisey? [1] I'm the Scala tech lead at Typesafe.

ffk 13y ago

I think this is the wrong question to ask. It's clearly enterprise ready considering enterprises are actively using it in their critical infrastructure. A better question is "Will scala ever have major release backwards compatibility as a feature." This isn't to discredit the author's viewpoint. I strongly agree with many of the assertions he makes. Backwards compatibility is a major problem. Back to backwards compatibility (wee, puns), I think a major part of it is not due to ABI changes. The JVM has very well defined entry and exit points to deal with this. The problem seems to stem more with the libraries. As long as the libraries keep changing at a fast rate, the scala cmomunity will never achieve backwards compatibility at the level this author wants to achieve. Until typesafe makes a strong commitment to put APIs through a sunsetting lifecycle with deprecation, it will continue to be a problem. Fortunately, they have made a commitment to not make breaking changes in minor releases. E.g. 2.10.0 compiled applications should continue to work with all release 2.10.* runtimes.

voidlogic 13y ago

Enterprise ready is such a useless term because the readiness is dependent on the particular enterprise asking the question. For some enterprises Scala or even Go are "enterprise ready", for others, it will be decades.

kailuowang 13y ago

Scala has the potential to become an enterprise useful language because people can write a simple script to monitor how many mutable states appears in the codebase.

dxbydt 13y ago

Will Scala ever be enterprise-ready? I don't know. Will enterprise ever be Scala-ready ? No. And I'm not being flippant here.

brucefancher 13y ago

No. Next question.

samlavery 13y ago

Scala is a fine scotch, but at a very young age. It's version 2.10.3, everything is still changing fairly rapidly. All it needs to be adopted in a more widespread manner is to improve it's approachability. Even for engineers who've been programming for years, Scala is hard to grok. The vast deviations in style don't help. I'm betting it's going to take over the world in a few years, especially as it expands it foothold in the Big Data space.

volune 13y ago

Twitter thinks so...

jemeshsu 13y ago

Scala will be enterprise-ready when there are readily available affordable Scala programmers. If you can master Scala and write complex Scala codes, most likely enterprise crud jobs does not interest you.

stormcrowsx 13y ago

Pretty sure its already in enterprises, perhaps the more cutting edge ones but nonetheless it powers some very large websites.