Will Scala ever be enterprise-ready?(alblue.bandlem.com)
alblue.bandlem.com
Will Scala ever be enterprise-ready?
http://alblue.bandlem.com/2013/08/will-scala-ever-be-enterprise-ready.html
107 comments
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.
If you can master Scala and write complex Scala codes, most likely enterprise crud jobs does not interest you.
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.
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.
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.
For some enterprises Scala or even Go are "enterprise ready", for others, it will be decades.
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.
Pretty sure its already in enterprises, perhaps the more cutting edge ones but nonetheless it powers some very large websites.
Twitter thinks so...
No. Next question.
I wonder how the JVM will compare to .NET in 10 years time.
They will both become just compatibility layers implemented on top of node.js.
/s
/s
[deleted]
...because single thread is enough for any task!
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
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.
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.
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.
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.
.minor: Scala does this at a Source level IME.
Which depending on your background may mean everything or nothing at all I guess.
Most Ruby libs would claim to follow semantic versioning. I think it's also fair to say there are a lot more mis-steps with compatibility on that side of the fence but I've not seen this argument used there that I can recall.
I mean, to be fair, your argument was "large enterprises". Which, means Java. And in that regard you're not wrong since binary compatibility there is a given.
Still... As long as you can clone and build the source (it's not like you're buying licenses for UI binary libraries built in Scala after all) I fail to understand why this is a bigger deal than say: String interpolation. Partial Functions. Function Lifting. Type Inference. Type Classes. Tuples. Pattern Matching. The list just goes on and on...
The question isn't "Is Scala ready to be the basis for closed source, licensed libraries" after all? If it were then a "we must maintain a decade of binary compatibility" might have a point. Otherwise it feels like a really hollow criticism. I mean, what actual Scala users out there actually want to see Scala 2.11's features put to death on the altar of binary compatibility?
Which depending on your background may mean everything or nothing at all I guess.
Most Ruby libs would claim to follow semantic versioning. I think it's also fair to say there are a lot more mis-steps with compatibility on that side of the fence but I've not seen this argument used there that I can recall.
I mean, to be fair, your argument was "large enterprises". Which, means Java. And in that regard you're not wrong since binary compatibility there is a given.
Still... As long as you can clone and build the source (it's not like you're buying licenses for UI binary libraries built in Scala after all) I fail to understand why this is a bigger deal than say: String interpolation. Partial Functions. Function Lifting. Type Inference. Type Classes. Tuples. Pattern Matching. The list just goes on and on...
The question isn't "Is Scala ready to be the basis for closed source, licensed libraries" after all? If it were then a "we must maintain a decade of binary compatibility" might have a point. Otherwise it feels like a really hollow criticism. I mean, what actual Scala users out there actually want to see Scala 2.11's features put to death on the altar of binary compatibility?
> I mean, to be fair, your argument was "large enterprises".
> Which, means Java. And in that regard you're not wrong since
> binary compatibility there is a given.
Exactly, and that's what Scala is up against. Java 8 will allow Java 7 compiled libraries to run without changes, and though there's a world of difference between Java 8 and Scala, in practice Java 8 gives developers some new features that they'll find useful and more performant than Scala (parallel collections, no implicit casting/conversions etc.)
It's also worth noting that 'backwardly compatible' and 'new features' aren't in conflict with each other. Java has had new features added (invokedynamic at the JVM, try-with-resources and string switch in the language layer) but they've still remained binary compatible. The problem is that Scala's approach to new features is to break binary compatibility between 2.x and 2.x+1 releases.
Exactly, and that's what Scala is up against. Java 8 will allow Java 7 compiled libraries to run without changes, and though there's a world of difference between Java 8 and Scala, in practice Java 8 gives developers some new features that they'll find useful and more performant than Scala (parallel collections, no implicit casting/conversions etc.)
It's also worth noting that 'backwardly compatible' and 'new features' aren't in conflict with each other. Java has had new features added (invokedynamic at the JVM, try-with-resources and string switch in the language layer) but they've still remained binary compatible. The problem is that Scala's approach to new features is to break binary compatibility between 2.x and 2.x+1 releases.
> 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.
This isn't quite true. I have a library (Breeze) that works with 2.10.3 but not 2.10.2. Something in name mangling changed, I think.
This isn't quite true. I have a library (Breeze) that works with 2.10.3 but not 2.10.2. Something in name mangling changed, I think.
This is most definitely a bug and you you should really report a breaking example to https://issues.scala-lang.org/
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.
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.
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.
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.
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.
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.
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.
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).
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
> 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
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"?
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"?
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.
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.
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.
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.
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.
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.
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.
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
> Why do you think that those doing research inside Typesafe are steering the language in a direction that is user hostile?
Macros come to mind. It's a feature that completely circumvented the SIP (and was later retrofitted into it), which is still heavily controversial inside scala-internals to the point that we're still not sure whether they will ever be officially part of scalac and which will probably never be used by more than a very tiny minority of Scala users.
They took months of work (which could have been put to better use, e.g. IDE support), mostly done with little transparency and which started generating papers for conferences before the project was remotely close to a prototype.
This kind of project would never have seen the light of day if the language was led by a company focused primarily on users and sound engineering.
Macros come to mind. It's a feature that completely circumvented the SIP (and was later retrofitted into it), which is still heavily controversial inside scala-internals to the point that we're still not sure whether they will ever be officially part of scalac and which will probably never be used by more than a very tiny minority of Scala users.
They took months of work (which could have been put to better use, e.g. IDE support), mostly done with little transparency and which started generating papers for conferences before the project was remotely close to a prototype.
This kind of project would never have seen the light of day if the language was led by a company focused primarily on users and sound engineering.
Hi, that's me who's doing macros for Scala. Martin & Adriaan have already commented on my choice of the project and its status within Scala, but I'd like to additionally elaborate on your other points.
Speaking of target audience and usefulness. Even before being officially released, macros have attracted attention of popular community libraries and tools (e.g. SBT, Akka, Play, Slick), and later on we got even more people on board [1]. Therefore, even though not many people are writing macros, a lot of Scala developers are, sometimes even unknowingly, using them.
That's I think is the best thing about macros in Scala - natural integration with other language features, to the extent that people aren't even aware that they are using macros and not regular functions or implicits or whatnot. Surprisingly many features can be empowered this way, giving rise to new and effective ways of solving development challenges [2].
Speaking of the future status of macros. Half a year ago, we had a joint EPFL and TypeSafe meeting where we decided to stabilize a subset of macros (so called blackbox macros [3]) and include it as an official, non-experimental language feature by 2.12. Indeed, at times we have fierce debates on our mailing lists about this or that esoteric macro flavor, but that concerns only my research activities [4], not blackbox macros, which have reach unequivocal approval at scala-internals a long time ago.
This brings me to the next point - transparency of development. For the entire duration of my doctoral studies at EPFL that begun in Sep 2011, we were always open with our plans, welcoming feedback and actively answering questions on the mailing lists and stack overflow. Some of the most successful reflection and macro features are there only because of our close collaboration with the community, and I'm very grateful to everyone who has participated and is participating.
Finally, the thing about generating papers is just untrue. Sure there are people who do their research using macros, but if you take a look at the list of my publications, you'll see that over the two years that I've been a PhD student I have authored zero conference papers. This is the cost of seeing through an implementation of a feature in an official language release, addressing the feedback of early adopters, and then maintaining it as it's being used in production. But anyhow I don't mind how it turned out, because I'm very glad that more and more people are picking up macros and finding them useful.
[1] http://scalamacros.org/paperstalks/2013-06-12-HalfYearInMacr... [2] http://docs.scala-lang.org/overviews/macros/usecases.html [3] http://docs.scala-lang.org/overviews/macros/blackbox-whitebo... [4] http://docs.scala-lang.org/overviews/macros/paradise.html
Speaking of target audience and usefulness. Even before being officially released, macros have attracted attention of popular community libraries and tools (e.g. SBT, Akka, Play, Slick), and later on we got even more people on board [1]. Therefore, even though not many people are writing macros, a lot of Scala developers are, sometimes even unknowingly, using them.
That's I think is the best thing about macros in Scala - natural integration with other language features, to the extent that people aren't even aware that they are using macros and not regular functions or implicits or whatnot. Surprisingly many features can be empowered this way, giving rise to new and effective ways of solving development challenges [2].
Speaking of the future status of macros. Half a year ago, we had a joint EPFL and TypeSafe meeting where we decided to stabilize a subset of macros (so called blackbox macros [3]) and include it as an official, non-experimental language feature by 2.12. Indeed, at times we have fierce debates on our mailing lists about this or that esoteric macro flavor, but that concerns only my research activities [4], not blackbox macros, which have reach unequivocal approval at scala-internals a long time ago.
This brings me to the next point - transparency of development. For the entire duration of my doctoral studies at EPFL that begun in Sep 2011, we were always open with our plans, welcoming feedback and actively answering questions on the mailing lists and stack overflow. Some of the most successful reflection and macro features are there only because of our close collaboration with the community, and I'm very grateful to everyone who has participated and is participating.
Finally, the thing about generating papers is just untrue. Sure there are people who do their research using macros, but if you take a look at the list of my publications, you'll see that over the two years that I've been a PhD student I have authored zero conference papers. This is the cost of seeing through an implementation of a feature in an official language release, addressing the feedback of early adopters, and then maintaining it as it's being used in production. But anyhow I don't mind how it turned out, because I'm very glad that more and more people are picking up macros and finding them useful.
[1] http://scalamacros.org/paperstalks/2013-06-12-HalfYearInMacr... [2] http://docs.scala-lang.org/overviews/macros/usecases.html [3] http://docs.scala-lang.org/overviews/macros/blackbox-whitebo... [4] http://docs.scala-lang.org/overviews/macros/paradise.html
[deleted]
I can personally vouch for the value of Scala macros, which I feel really transform the language. With macros (at least with macro-paradise) I can metaprogram Scala more powerfully than Ruby, while retaining typesafety. Scala + macros is a pretty remarkable language, being very dynamic while also being very safe.
The macros support included in 2.10 is pretty basic and difficult to use, but with annotation macros and quasiquotation in macro-paradise those issues are eliminated.
And who are you to determine what gets priority amongst open-source devs? Does macro support make scala a worse language? Are you upset that an unpaid researcher (not an employee of typesafe) decided to spend time implementing the macro system instead of working on the IDE?
The macros support included in 2.10 is pretty basic and difficult to use, but with annotation macros and quasiquotation in macro-paradise those issues are eliminated.
And who are you to determine what gets priority amongst open-source devs? Does macro support make scala a worse language? Are you upset that an unpaid researcher (not an employee of typesafe) decided to spend time implementing the macro system instead of working on the IDE?
Macros were not done at Typesafe, but by Eugene Burmako, who's a grad student at EPFL. Grad students do new stuff, and they publish about it, IDE improvements are typically not their piece of cake (Typesafe does have a very capable team working on IDEs).
As you imply, macros are labelled experimental, which means that you have to enable them explicitly. Having experimental features is Scala's way of reconciling a vibrant open source community with the stability needed for enterprise use. Needless to say, we do not recommend use of experimental features in enterprises. They are good for playing around with interesting new concepts and sometimes they do lead to something which is a win, such as the beautiful async/await library that will ship in 2.11.
As you imply, macros are labelled experimental, which means that you have to enable them explicitly. Having experimental features is Scala's way of reconciling a vibrant open source community with the stability needed for enterprise use. Needless to say, we do not recommend use of experimental features in enterprises. They are good for playing around with interesting new concepts and sometimes they do lead to something which is a win, such as the beautiful async/await library that will ship in 2.11.
Macros were not developed by Typesafe, though we do try to help out. Also, macros are clearly marked experimental -- a compromise for a language co-developed by researchers (EPFL has invested over a decade in Scala) and industry.
We (Typesafe) are using macros in our own projects, so the small investment in helping out with their development has largely been paid off because they essentially give us a lightweight compiler plugin mechanism. Users need not be aware macros underly, say scala-async.
We (Typesafe) are using macros in our own projects, so the small investment in helping out with their development has largely been paid off because they essentially give us a lightweight compiler plugin mechanism. Users need not be aware macros underly, say scala-async.
[deleted]
Those short cycles are great for small startups doing MVPs. They have absolutely zero benefit (negative benefit, possibly) for large teams working on really large projects.
I'd add one thing to the list of requirements before it is enterprise-ready: faster compile times.
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)
(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)
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).
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).
Only at the file level, and nothing as advanced as state of the art that google has for C++ (but where people are building the same thing anyways). I did tree level incremental compilation in Scala for the presentation compiler, but Martin replaced that with laziness, which obviously isn't the same thing.
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.
For day-to-day coding where you need that flow you should be using an IDE with incremental compilation. Full compiles are for releases or the like.
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.
Not until Set is not a Functor
To be pedantic, you mean Set to not implement map, right?
> 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.
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.
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.
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.
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")
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
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.
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.
Odersky is already working on a Scala successor: http://www.infoq.com/presentations/data-types-issues
That isn't intended to be a Scala successor. That is intended to be integrated in future versions of Scala.
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.
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.
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.
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...).
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.
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.
>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.
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.
> How so? Can you explain how you think Scala isn't sound/typesafe?
Because you can do casts, and it's not pure. It doesn't even enforce immutability. You know what? Forget about enforcing – it doesn't even make mutability or casts hard. Look, Haskell is certainly not my cup of tea. Personally, I don't think the effort of thinking about my program twice (once in terms of logic and once in terms of types) is worth it in most circumstances, and pure functional languages don't support concurrent data structures which is what I deal with the most. But I do recognize Haskell's elegance, and if the elaborate type system is worth it, it's only because it can enforce many guarantees. I mean, the whole point of Haskell is that it supposedly makes safer programs. So you pay for the elaborate types (though some consider it a plus), but you gain safety. With Scala you just pay.
> Uhm, can you explain to me an example of a simple OO type system that is 'just powerful enough'?
Sure. C++, Java, C#. Almost all of the world's software is written in C++ or Java. The question is not which language has "the best type system" (and even if it were, Scala can't make up its mind because it's got three of them). A type system is not an end but a means. Practically everyone who deals with type systems agrees that they come at a cost (and Martin Odersky himself admitted as much). But the cost hopefully buys you something. It arguably buys you better design, and it definitely buys you safety. Well, Scala doesn't give you safety any more than C++ or Java, and as for design, it can't even pick one type system; a cornerstone of great design is that you have to make hard choices.
Because you can do casts, and it's not pure. It doesn't even enforce immutability. You know what? Forget about enforcing – it doesn't even make mutability or casts hard. Look, Haskell is certainly not my cup of tea. Personally, I don't think the effort of thinking about my program twice (once in terms of logic and once in terms of types) is worth it in most circumstances, and pure functional languages don't support concurrent data structures which is what I deal with the most. But I do recognize Haskell's elegance, and if the elaborate type system is worth it, it's only because it can enforce many guarantees. I mean, the whole point of Haskell is that it supposedly makes safer programs. So you pay for the elaborate types (though some consider it a plus), but you gain safety. With Scala you just pay.
> Uhm, can you explain to me an example of a simple OO type system that is 'just powerful enough'?
Sure. C++, Java, C#. Almost all of the world's software is written in C++ or Java. The question is not which language has "the best type system" (and even if it were, Scala can't make up its mind because it's got three of them). A type system is not an end but a means. Practically everyone who deals with type systems agrees that they come at a cost (and Martin Odersky himself admitted as much). But the cost hopefully buys you something. It arguably buys you better design, and it definitely buys you safety. Well, Scala doesn't give you safety any more than C++ or Java, and as for design, it can't even pick one type system; a cornerstone of great design is that you have to make hard choices.
>pure functional languages don't support concurrent data structures which is what I deal with the most
This is false, you were misinformed.
>Sure. C++, Java, C#.
C++ Has a good type system, IMO. The other two are broken. Literally, you can write broken code. Scala has a long list of warts, I just don't think you're listing any of them.
>Well, Scala doesn't give you safety any more than C++ or Java, and as for design, it can't even pick one type system; a cornerstone of great design is that you have to make hard choices.
This is just FUD. Are you telling me Java/C#'s type systems enforce more safety than Scala? Because they don't. They don't get variance right. Do you know what variance is? You ignored that part of my comment.
This is false, you were misinformed.
>Sure. C++, Java, C#.
C++ Has a good type system, IMO. The other two are broken. Literally, you can write broken code. Scala has a long list of warts, I just don't think you're listing any of them.
>Well, Scala doesn't give you safety any more than C++ or Java, and as for design, it can't even pick one type system; a cornerstone of great design is that you have to make hard choices.
This is just FUD. Are you telling me Java/C#'s type systems enforce more safety than Scala? Because they don't. They don't get variance right. Do you know what variance is? You ignored that part of my comment.
> This is false, you were misinformed.
If I'm wrong, I apologize. I am not familiar with any concurrent data structures in a pure functional language, but I'd love to learn of any. I have not encountered a data structure in a functional language that supports more than one concurrent writer (and I don't mean parallel construction of an immutable DS - that's trivial – but concurrent mutation, like in a concurrent B-Tree, concurrent skip-list, or concurrent hash map).
If I'm wrong, I apologize. I am not familiar with any concurrent data structures in a pure functional language, but I'd love to learn of any. I have not encountered a data structure in a functional language that supports more than one concurrent writer (and I don't mean parallel construction of an immutable DS - that's trivial – but concurrent mutation, like in a concurrent B-Tree, concurrent skip-list, or concurrent hash map).
I haven't checked anymore than glancing through the slides but it has the words "concurrent data structures in haskell" at the beginning:
http://www.scribd.com/doc/28336206/Multicore-programming-in-...
http://www.scribd.com/doc/28336206/Multicore-programming-in-...
You are right! Didn't know about MVars. Got some learnin' to do now...
C++ has a good type system? C++ templates are just a copy-paste find-replace-all hack around type-system, they don't typecheck at all at the generic level. There is no notion of type variance nor dependent types. Not to mention many warts inherited from C (like being able to implicitly cast char arrays to booleans). It is IMHO much worse than even Java's (which is also not good).
Yet they are extremely powerful. Whatever their flaws may be, I have worked with your preferred version of templates (C# generics) and, let me tell you, they are inferior in every practical way.
Huh, where did I say my preferred version of templates were C# generics?
As of C++ templates being extremely powerful - I agree. But this is a similar kind of "powerfulness" as C macros are, only little safer. Technically they are still just a fancy macrogenerator working at the AST level instead of lexer level, knowing nothing about the types (you even have to tell it which symbols are the types, because it cannot reason it out from syntax). IMHO it is years behind true generic typesystems like in Haskell, OCaml or Scala and calling it a "type system" is an exaggeration.
As of C++ templates being extremely powerful - I agree. But this is a similar kind of "powerfulness" as C macros are, only little safer. Technically they are still just a fancy macrogenerator working at the AST level instead of lexer level, knowing nothing about the types (you even have to tell it which symbols are the types, because it cannot reason it out from syntax). IMHO it is years behind true generic typesystems like in Haskell, OCaml or Scala and calling it a "type system" is an exaggeration.
> They don't get variance right. Do you know what variance is? You ignored that part of my comment.
This can't be stated enough, and it's a huge problem in Java and C#. Unfortunately, most programmers don't care and simply continue to write broken code.
This can't be stated enough, and it's a huge problem in Java and C#. Unfortunately, most programmers don't care and simply continue to write broken code.
I don't have anything against correct variance, but just to play the devil's advocate, you do know that there are other ways to write correct code than with a "correct" type system, right? AFAIK, none of the safety-critical code running avionics, medical devices, guided missiles and operating systems has been written with a "correct" type system. And people "continue to write broken code" in any language.
Care to elaborate on C# 5 variance issues, please?
I don't see how a case-class is different than a non-case-class from a Type perspective? It was my impression it was just sugar around generating copy, equals, accessors, an Extractor and a companion-object.
I don't see how the sugar makes them a fundamentally different kind of Type system?
And Structural Typing is just Reflection I thought. It's still compile time (which is kinda the point). Which again doesn't feel like an alternative Type system.
But I'm not at all versed in Type theory so maybe I'm just mischaracterizing what a Type is...
I don't see how the sugar makes them a fundamentally different kind of Type system?
And Structural Typing is just Reflection I thought. It's still compile time (which is kinda the point). Which again doesn't feel like an alternative Type system.
But I'm not at all versed in Type theory so maybe I'm just mischaracterizing what a Type is...
> I don't see how the sugar makes them a fundamentally different kind of Type system?
They're not sugar. Their crucial feature is that they can't form an inheritance hierarchy, which doesn't work well in an algebraic type system.
> And Structural Typing is just Reflection I thought... Which again doesn't feel like an alternative Type system.
The point is that you can write (and obviously people have) a big, complex piece of software just with inheritance-based types, or just with algebraic types, or just with duck types. They all serve quite nicely. It is completely unnecessary to put them all in a single language (other than to advance compiler technology), and worse than that: putting them all together takes away their respective advantages and causes a lot of confusion.
They're not sugar. Their crucial feature is that they can't form an inheritance hierarchy, which doesn't work well in an algebraic type system.
> And Structural Typing is just Reflection I thought... Which again doesn't feel like an alternative Type system.
The point is that you can write (and obviously people have) a big, complex piece of software just with inheritance-based types, or just with algebraic types, or just with duck types. They all serve quite nicely. It is completely unnecessary to put them all in a single language (other than to advance compiler technology), and worse than that: putting them all together takes away their respective advantages and causes a lot of confusion.
I don't think you can write idiomatic Scala with any one of those things exclusively. And I don't see why you'd even try. You might as we'll be arguing that the language shouldn't have for-comprehensions, lambdas, pattern matching or keyword arguments the way I see it.
These things (types) do have uses, but not as competing systems in Scala, but Features. I want to write c#'s using() statement, I'm not especially worried about performance, I can't go and add IDisposable to everything because I want to use it with other people's code and I don't feel like writing a Type Class every time I need to work with a new type. Structural typing is a really convenient feature for that.
Case classes are just Scala's version of a data-object. If you didn't have them you'd just be writing your own version, poorly, and forgetting about hash code and equals and all the other stuff until it bit you.
I really don't see a rationale here for removing these other than you find it offensive. I use Scala because of these things.
These things (types) do have uses, but not as competing systems in Scala, but Features. I want to write c#'s using() statement, I'm not especially worried about performance, I can't go and add IDisposable to everything because I want to use it with other people's code and I don't feel like writing a Type Class every time I need to work with a new type. Structural typing is a really convenient feature for that.
Case classes are just Scala's version of a data-object. If you didn't have them you'd just be writing your own version, poorly, and forgetting about hash code and equals and all the other stuff until it bit you.
I really don't see a rationale here for removing these other than you find it offensive. I use Scala because of these things.
Classes are types. And in Scala, case classes are just an awkward take on algebraic data types.
Scala doesn't even come close to Haskell. For one, it does not do anything to capture effects in the types. Apart from being markedly less safe, this also makes things like STM impractical. Additionally, implicits may be more powerful than typeclasses, but they're also easy to mess up: you lose canonicity. In Haskell, if you have a Set a, you know it uses the same ordering of a as any other Set a; in Scala, you lose this guarantee. You also don't have any notion of kinds, which makes quite a bit of otherwise-idiomatic code hard to write. Take a look at this post[1] for more examples and details.
[1]: http://www.reddit.com/r/haskell/comments/1pjjy5/odersky_the_...
If you want a simple yet powerful OO system, take a look at OCaml. It does OO much better than any other statically typed language I've used. The funny thing is, of course, that people don't use OCaml's object system--not because it's bad but because by the time you're using OCaml, you've already realized functional programming is the way to go. Most of the reasons I've heard for not using OCaml's object system apply even more to other OO languages!
OCaml's object types are expressive and, unlike Scala, fully inferable. And they don't mess variance up! You also get a dual sub-typing with polymorphic variants--I don't know if Scala can do anything comparable with case classes.
Scala doesn't even come close to Haskell. For one, it does not do anything to capture effects in the types. Apart from being markedly less safe, this also makes things like STM impractical. Additionally, implicits may be more powerful than typeclasses, but they're also easy to mess up: you lose canonicity. In Haskell, if you have a Set a, you know it uses the same ordering of a as any other Set a; in Scala, you lose this guarantee. You also don't have any notion of kinds, which makes quite a bit of otherwise-idiomatic code hard to write. Take a look at this post[1] for more examples and details.
[1]: http://www.reddit.com/r/haskell/comments/1pjjy5/odersky_the_...
If you want a simple yet powerful OO system, take a look at OCaml. It does OO much better than any other statically typed language I've used. The funny thing is, of course, that people don't use OCaml's object system--not because it's bad but because by the time you're using OCaml, you've already realized functional programming is the way to go. Most of the reasons I've heard for not using OCaml's object system apply even more to other OO languages!
OCaml's object types are expressive and, unlike Scala, fully inferable. And they don't mess variance up! You also get a dual sub-typing with polymorphic variants--I don't know if Scala can do anything comparable with case classes.
>You also don't have any notion of kinds, which makes quite a bit of otherwise-idiomatic code hard to write.
I'm not sure that is true. Otherwise this would not be possible: class MyExample[A[_]](a: A)
I'm not sure that is true. Otherwise this would not be possible: class MyExample[A[_]](a: A)
Yeah, I think that part was a bit inaccurate. The core problem is more like the fact that higher-kinded code is hard to write. You always end up writing in terms of concrete types--you can talk about A[_], but not about A by itself. This becomes a hassle when working with things like monad transformers.
How in the world is this the top upvoted response? All of this is either nitpicking, arguing over the meaning of words when the intended meaning is perfectly clear, stating an opinion without argumentation, and the rest is just plain false.
Enterprise does need scala. You can tell by the way any enterprise java codebase ends up with five different sets of annotations, two almost-compatible AOP systems and a clusterfuck of XML tying it all together.
Yes, scala is more complicated than java, considered in isolation. But you can write a large program in pure scala, rather than the bloated enterprise frameworks you end up with in java.
Yes, scala is more complicated than java, considered in isolation. But you can write a large program in pure scala, rather than the bloated enterprise frameworks you end up with in java.
That's not a language issue but a library issue, and modern Java libraries are not like that at all. Hell, Scala programs use them just as much as Java programs do.
If anything, Java is showing that it can clean up years of cruft (Java EE 7 is pretty neat, and even the JDK is finally being modularize) while maintaining backwards compatibility. This is the kind of thing Enterprise wants and needs.
If anything, Java is showing that it can clean up years of cruft (Java EE 7 is pretty neat, and even the JDK is finally being modularize) while maintaining backwards compatibility. This is the kind of thing Enterprise wants and needs.
>>That's not a language issue but a library issue
What is this, 1985?
Libraries, frameworks and the community etc make the language these days.
What is this, 1985?
Libraries, frameworks and the community etc make the language these days.
I moved from Scala back to Java (not because I like Java so much, but because the current project requires it). And lambdas and traits are not the main features I miss. Much more I miss lazy evaluation, pattern matching, much better type system (variance, type classes, dependent types, even erasure is not that painful) and awesome collection library. None of those things are in Java 8, nor planned in any future version.
While Scala is indeed a bit overly complex (concept-wise), in practice working with both at an "enterprise" I've found it better overall than Java. Also, neither Kotlin nor Java 8 are available in non-beta form yet.
My biggest complaint about Scala isn't the language itself, but the flakiness/immaturity of some of the libraries/frameworks/tools compared to Java.
My biggest complaint about Scala isn't the language itself, but the flakiness/immaturity of some of the libraries/frameworks/tools compared to Java.
>> But seriously, it doesn't offer anything enterprise would want.
The only thing enterprise managers want is a language that can dumb down the art of programming to a level a programmers can be managed like assembly line workers. And that is what Java does exactly, an IDE that can make a novice and expert work at the same levels of productivity, extremely verbose code that gives an illusion of people building something big(even if its down right trivial). And most importantly programming effort can be accounted like a couple of least important replaceable folks down the hierarchy doing some assembling reusable units of material.
Change this scenario, a good technology with merit makes programmers very important and makes managers look like desk clerks.
Enterprise Managers don't care a least about type systems, lambdas, or traits or whatever. Most managers don't have a remote clue what those things are. Can the technology enable them to manage herds of programmers dumbed down enough to be managed like sheep? That is all they care.
The only thing enterprise managers want is a language that can dumb down the art of programming to a level a programmers can be managed like assembly line workers. And that is what Java does exactly, an IDE that can make a novice and expert work at the same levels of productivity, extremely verbose code that gives an illusion of people building something big(even if its down right trivial). And most importantly programming effort can be accounted like a couple of least important replaceable folks down the hierarchy doing some assembling reusable units of material.
Change this scenario, a good technology with merit makes programmers very important and makes managers look like desk clerks.
Enterprise Managers don't care a least about type systems, lambdas, or traits or whatever. Most managers don't have a remote clue what those things are. Can the technology enable them to manage herds of programmers dumbed down enough to be managed like sheep? That is all they care.
No one (well, other than language designers) cares about traits and lambdas per se. People care about maintainability, performance, productivity, runtime diagnosability etc., and "enterprise managers" care about these things a lot. That is why the whole world, almost, switched from C++ to Java faster than it's taken the smallish Python community to switch from 2.7 to 3.0.
I won't go into an argument over verbosity, because Java is indeed verbose (about the same as Go and less than C or C++, that were what many in Enterprise used before). But as to the "assembly workers" kind of thing - it is far more complex than that. First, in no language is a novice as productive as an expert; not in Java, not in C and not in Haskell. Second, lots of enterprise projects are far from trivial. Some projects are so damn big that no matter what language you use, it's gonna take a couple of years, several million LOC, and at least several dozen developers, if not more than a few hundreds. Once that's the case, productivity means something else entirely, and yes, planning for team members coming and going is part of it; I think that in that respect Java hit a sweet spot. Obviously, it could be made better; it could be modernized. Personally, I also believe that the JVM is such a great polyglot platform, that projects should be written in several languages – yes, even in the enterprise.
Not all enterprise managers are stupid, and there are good reasons your bank doesn't run on Ruby or Python. Enterprise software technology changes all the time – yes, some of it is due to excellent sales team, but some of it is based on merit. You wouldn't expect that software technologies that are good for constantly pivoting SV startups would be equally good for running banks; or aircraft carriers. The requirements are just too different. Python has its place, as does Java. It's just not always the same place.
I won't go into an argument over verbosity, because Java is indeed verbose (about the same as Go and less than C or C++, that were what many in Enterprise used before). But as to the "assembly workers" kind of thing - it is far more complex than that. First, in no language is a novice as productive as an expert; not in Java, not in C and not in Haskell. Second, lots of enterprise projects are far from trivial. Some projects are so damn big that no matter what language you use, it's gonna take a couple of years, several million LOC, and at least several dozen developers, if not more than a few hundreds. Once that's the case, productivity means something else entirely, and yes, planning for team members coming and going is part of it; I think that in that respect Java hit a sweet spot. Obviously, it could be made better; it could be modernized. Personally, I also believe that the JVM is such a great polyglot platform, that projects should be written in several languages – yes, even in the enterprise.
Not all enterprise managers are stupid, and there are good reasons your bank doesn't run on Ruby or Python. Enterprise software technology changes all the time – yes, some of it is due to excellent sales team, but some of it is based on merit. You wouldn't expect that software technologies that are good for constantly pivoting SV startups would be equally good for running banks; or aircraft carriers. The requirements are just too different. Python has its place, as does Java. It's just not always the same place.
>it's much harder to integrate Java with Scala than with Clojure or Groovy, let alone Kotlin.
Your kidding right? Scala's Java interop is seamless compared to that of Clojure.
Your kidding right? Scala's Java interop is seamless compared to that of Clojure.
I'm not sure what you mean. Clojure's abstractions (seqs and maps) are completely compatible with Java collections and require no conversion in either direction, while Scala collections do.
You can actually make it automatically convert in both directions with just an import. But it is good practice to do it explicitly.
In my opinion, for a typesafe language, this is a good way to do it.
The conversion, either implicit or explicit, is not free, neither in terms of performance, nor in terms of mental effort. This is not the case with Groovy, Kotlin and Clojure (though Java interoperability in Clojure does require more mental effort than in Groovy and Kotlin).
I would argue that Groovy and Clojure require just as much conversion (I have no idea about Kotlin). Scala and Clojure both require conversion if you want to use idiomatic data structures. I think Groovy is actually worse about this because you get secret implicit conversion to add meta classes and null objects. I've run in to a bunch of difficult to track down bugs where Groovy has forgotten to do these conversions.
[deleted]
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.
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.
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
It's not only Enterprise ready, but is in production in a large number of enterprises in many different sectors.
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.
(For those unaware, modersky is the creator of Scala).
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.
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.
> 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.
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.
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). 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.
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). 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.
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.
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.
And I'm not being flippant here.