But yes, annoying legacy means that companies can make money without having to improve (or maybe only recompile) yesterday’s code and without their devs having to learn new things. It also allowes to cram code using different versions of the language together without thinking about it. I can immediately find arguments against those ways of thinking but this is not ontopic here.

http://www.scala-lang.org/node/1658

That list is somewhat outdated already. Things have been moving pretty fast lately, so there are many large enterprises, in particular from the financial sector, that are not yet on this list.

1.) Well see above what the post triggered

2.)
“Scala 2.8.1 is out, no binary incompatibility, fixing more than a hundred small issues, and production ready.”

What about 2.9, 3.0?

3.) “the community is growing, while the Java language that never broke anything in 15 years will take at least 2 more years to be in a state almost decent enough to compete with Scala.”

Not sure what you mean with competition. Though this should not became a Java vs. Scala post, Java makes billions of dollars for companies each year, Scala has … well Novell and foursquare.

For instance:

(defn dosomething [^String x]
… some code …)

unfit for serious development based on one big problematic release?

Scala 2.8.1 is out, no binary incompatibility, fixing more than a hundred small issues, and production ready.

the community is growing, while the Java language that never broke anything in 15 years will take at least 2 more years to be in a state almost decent enough to compete with Scala.

I think you owe the Scala community a serious re-evaluation of your comments.

Check out Digital Mars D version 2. It has all these things – though for enough libraries one has to include C libs, and C++ libs that are usable from C. It is lacking solid 64bit support but that’s firming up.

@Det: Demanding things on other people blogs is not the way to go – or looking at it differently: Everyone can demand whatever he likes, my country is free. Best Stephan

while 2.8.0 has been a bumpy ride, it is correct that you are upset about not being able to use pre-release software in production, yes? ;)

You can certainly argue my experiences,I probably should have said that the only thing I care is high performance server side web applications – not Swing etc. (My Swing/SWT experience is more than 5 years old).

But as Swing is dead for many many years, as is essentially Java on the Desktop (because SWT is much worse), it might be a bad choice to use Java for desktops.

But I agree Sun should have said so that they have no interest in Java desktop applications instead of “supporting” Swing.

“I have run Scala in production mode. But with significantly higher problems in the environment than with e.g. Java (1.0, 1.1, 1.2, 1.3, 1.4, 1.5 and 1.6).”

and in response to Alex:
“Enterprise would be for me, if a language vendor / community fixes bugs in older versions (as Sun does quite remarkably).”

This in my opinion is extremely painting in pink, like you paint in black about Scala.

It absolutely ignores what you can observe if following Sun’s (now Oracle’s) Bug database. And it does not match our own experience with Java, for my team especially in the Swing area.

Bugs, even serious ones, are not fixed for a long time. Complaints from the user base are ignored. So called “fixes” or “improvements” introduce even more serious bugs due to bad regression testing.
I only want to mention one here, which recently costed us a good bunch of hard debugging time and customer related support effort (all of it expressed in money): That suddenly SwingWorker used a “thread pool” of only one(!) thread (Bug-id: 6880336) what resulted in serious concurrency and repainting problems in our customer installations.

Took a while to trace it down to SwingWorker and to find that the issue was already known for three(!) update releases.
This is not the only case where we had to handle things ourselves by overriding Sun’s implementation, what is extremely complicated due to Sun’s tendency to make everything private, even for non-security-related parts.

I remember e.g. also changes in inlining behaviour of the compiler which broke our app initialisation code and some of such things more. And regarding the libraries: When Java 5 came out and we were eager to use Generics to improve type safety and clean up messy code, we were in a relase hell regarding Appserver, libraries and tools as well. Some supported it good, some bad, some didn’t. So we had to wait, synchronize, test, migrate. Not done in a fingersnip, as you implicitly pretend.

“Adapting to a moving target is hard to achieve.” is despite all announcements and efforts from Sun even true for Java.

It is *not* milk and honey.
And regarding the big user base of Java and the many LOCs of serious production code written in it, this situation is unbearable and one should really start writing a blog post titled “Java unfit for serious development – Sun people eager to write PR stuff on webpages, but unwilling to fix bugs and support the community” (Very sorry, but simply could not resist).

http://alblue.bandlem.com/2009/10/scala-is-still-not-enterprise-ready.html

The problems are really a lack of maturity in the release engineering management of the project and a dogmatic approach to releasing it as 2.8 “because we already used that term in our previous discussions”

At that point, I realised that Scala was dead; even if the body is still twitching. Yes, people name the same four companies who ace used it again and again, but the reality is that the majority of developers don’t use minority languages and Scala is doing all it can to be unattractive to enterprise users. Until the releases get sorted, it will remain a blacklisted language in many more environments than in the few who have built their castles on quicksand.

A little more resources dedicated to keeping the IDE’s etc. working would go a long way to making Scala a success.

contributors are welcome.

You state several times in your responses that “I haven’t seen an official announcement/statement that…”. This is true, much of what happens within Scala is still announced and planned via the mailing lists. Sometimes there isn’t a single mail covering a particular feature, instead there’s an entire online debate/discussion.

Is it not the case then that your main implicit criticism is the lack of some co-ordinating PR group, tasked (amongst other things) with handling press releases for Scala?

While it’s true that such an arrangement would go a long way in resolving the concerns of many decision makers, I don’t think it’s fair or reasonable to judge a programming language primarily on the quality of marketing. To do so puts *all* open source development at something of a disadvantage.

@Stephan
_

As a member of the Scala community, I feel compelled to add a comment to the already really long list :-).

I felt that your post title was an unfortunate generalization. I mean, I can feel your pain. I understand that having to upgrade to Scala RC because you need to follow the changes from libraries you use is a pain.

But the trouble with your post title is that it gives *everyone* the impression that the *whole* Scala language is unfit for serious development (especially when it gets retweeted all over).

However, from the comments and examples around, it is obvious to me that there *are* serious developments based on Scala. So I think that your title is really misleading for Scala newcomers and people observing Scala from far.

Then I was unhappy when reading your statement about “developers and community are unwilling”. As part of the community I’ve been religiously maintaining 2 branches of my open-source project and providing adequate releases as soon as a RC was out. Writing this was a bit unfair to people like me and to others who are devoting so much of their time trying to maintain/improve things.

That being said, the difficulty is real. The state of tooling in Scala 2.7.7 is not on par with Java. Many interesting projects started when 2.8.0 was in the works and chose to stick to that version instead of maintaining 2 branches. So, at the moment, it is not possible to get the best of the libraries, tools and language around and that’s frustrating.

I hope that, as a community, we’ll learn a good lesson in term of release scoping. I guess that Scala 2.8.0 could have been released with a narrower scope. Maybe type specialization, named/default arguments could have been left out until the next release?

One interesting thing you write is “There is no alternative”. That’s very true and not surprising, “Programming is hard” isn’t it? The kind of features that are developed in Scala are certainly difficult to get right. I wish good luck to anyone wanting to create a similar (OO/functional, statically compiled) language on the JVM. Opposite to you what you wrote, I find that most of the developers and community are deeply involved and willing to discuss and solve issues. And they do so with very limited resources sometimes. We need to encourage them and salute their efforts. Look at what Miles Sabin has done with the Eclipse plugin for example. The situation is not perfect but an incredible lot of work has been done. So “There is no alternative” because the objective is ambitious and this is why we should put all our positive energy towards it.

My last point is about the community response to your post. I think that some twitter messages were too hard against you as if there was nothing to complain about! On the other hand, lots of other commenters were balanced in their reaction to your post, acknowledging some of the issues you describe. Then I really appreciate Martin’s comment. He has answered directly to your concerns, with no fuss.

That should be the inspiration for all of us. Learning from our mistakes, keep being focused and positive to provide a fun, sound, complete Scala language/ecosystem. Please support us, help us improve and keep insisting on the word “love” in “tough love” :-)

Eric.

PS: very sorry for the long comment, I didn’t have enough time to make it shorter,…

thanks for your reply.

For 1 + 2: I’m not jumping voluntarily into 2.8, but if everyone jumps into 2.8 I have to jump into too. I would have wished libraries supported 2.7.x with bug fixes until 2.8 is out and keep a 2.8 branch to check their code against the 2.8 release.

For 3: Good to know.

For 4: Good to know too. Perhaps some form of statement or vision would be fine for the Scala org page. Scala is at the edge of getting a mainstream choice for new projects. I would be very sad if the ecosphere and the core team blew it.

Best
Stephan

Wow, what a controversial posting, and what an avalanche of reposes. Let me just
clarify some points.

1. 2.8 is a difficult release, on the order of Python 3 vs the 2.x series. We are almost there.

2. RCs are by definition bleeding edge, and unfit for serious development. Wait until 2.8 final is out — I expect that to happen within the week.

3. “Scala’s developers are interested in language research and writing papers, not in making a language for real development.” That one you got totally wrong. In fact I am about to take a leave from university and found a startup to do commercial Scala support. I am taking some of the key Scala developers with me.

4. Binary compatibility: Yes, it’s a tricky issue. I have said in the past that we will address this issue for releases from 2.8 onwards. And that’s still the plan.

As for your updates: Who in the community says “everything is just fine?” And who in the community has personally attacked you other than me calling you an emo for writing an EMOtionally charged blog post that attacks the entire Scala community’s motives (“unwilling”).

As a member of the community, I make a general apologize for the personal attacks. However, you really did bring it on yourself. Your post takes a very hard line on some controversial subjects without making any strongly compelling arguments. What did you expect would happen?

The only substantive thing in your post buried a bit amongst the accusations, and it is the unfortunate fact that an unnamed library chose to defer bugfixes to a version which only compiles against an unstable release candidate of Scala 2.8. This library absolutely deserves to be called out, because this is behavior is shameful. However, instead of putting the blame where it belongs, you railed against Scala in general, the community at large, and the compiler team specifically. Again, what were you expecting the response would be?

When you dish out unfounded personal attacks against the community, don’t be surprised if they respond in kind.

I do not consider “unwilling” strong language, how would you describe it? There is no official or community response to the 2.8 issues and a roadmap for stableness in the future. If you listen to James e.g. there isn’t the acknowledgement that there is a problem. And I did use “unwilling” compared to “unhelpful” or “unskilled”.

And as said in other posts, there is a fine balance between making statements that are to broad (“the community”) and statements that are insignificant (“today at 15:23 the sun did shine in the middle of Berlin” – whoo, so what?). Perhaps my comments fell on the wrong side.

And for “unfit”: Perhaps I’m not that good with choosing English words due to my limited English vocabulary, but a language that – from my point of view, this is a blog, rememeber? – doesn’t work as a tool because it breaks – ouch this sounds like a German sentence that is too long – isn’t it unfit?

You code is online?

Now I can not speak for everybody but I do not think “the community” disagreed with your main issue which was binary incompatibility between releases. So, no, not everything is fine, far from it but as with every technology choice, there is a tradeoff, and some argued that for them scala is still a good fit.

And there was another argument, as far as I could see, which was against complaining about pre-release software while you yourself used a fairly strong language to describe your own conclusion “unfit for serious development”, “the community is unwilling” etc. So I presume the stronger reaction was party triggered by your own strong statements.

Personally, I would encourage you to stick around and try to help us to make things better. (and hopefully things will get much better after 2.8 is finally released)

As with every new tech, early adopters will suffer. If you don’t accept that, maybe you should wait a few years before switching?

So, basically you’re right, but I don’t see this as a problem just yet.

On the other hand, I sure would appreciate it if scala-lang.org had a bit more up-to-date information on what’s going on with Scala. And moving to a DVCS like git wouldn’t hurt either, imho.

Some further comment from http://fantom.org/sidewalk/topic/1101 :
…
A common first reaction to Fantom is “nothing really new or novel”. Its an interesting comment because this is by design. Fantom is not an academic language designed to experiment with novel programming language features. Rather we set out to build a pragmatic language which would elegantly solve the problems software engineers face on a daily basis. You might say that Fantom is deliberately designed to be a boring language.
…

- Nikhil

The contributions from the commercial world are increasing, but strong influence requires more than bug reports and occassional patches.

I think Daniel Spiewak nicely made the comparison of ruby and Scala. But Scala 2.8 is moving faster than ruby. Which might be ok (obviously not for you), as it has less user base. But it is usually easier to keep bytecode forward compatibility than source code forward compatibility, as bytecodes tend to be more stable (obviously not the case of current Scala).

Having that said, I think Scala will have the opportunity, in the future, to be more forward compatible than Ruby, unless they adopt something bytecode files, like Python’s pyc.

I haven’t seen their code. I haven’t seen their problems. I have run Scala in production mode. But with significantly higher problems in the environment than with e.g. Java (1.0, 1.1, 1.2, 1.3, 1.4, 1.5 and 1.6).

“The whole business about those seemingly endless 2.8.0.RCx was to give a chance to the eco system to adjust before the release.”

Adapting to a moving target is hard to achieve.

“But it can definitely be done.”

Sure. With either enough time, money or patience. And as long as you’re not forced due to a crucial feature or bug into version hell.

Worked with 2.7.5 for quite some time without problems.

Yes, but it’s not 0.5, it’s 2.8.0. And it’s not 2.8.0-alpha1 but 2.8.0-RC*

“Martin repeatedly said that 2.8 was going to be the last binary incompatible release. It remains to be seen whether that turns out to be true or not.”

Yes we will see, I generally believe actions more than words. And official words on a project page more than words in casual discussions.

@Erik: “There has been substantial debate on this topic on multiple occasions. The general consensus seemed to be there was no good solution. 2.8 was long advertised before people realized it was such a huge departure from 2.7.”

As said above, it’s never to late to change. And I fear it will be the same next time. There might be some discussion on mailing lists, conferences etc. but I would like to see an offical statement about the future for handling those situations.

“But my general point is that most of this is happening in public for a long time now. No one using Scala seriously should be in the least bit surprised, because if you use a technology seriously you should be paying attention to its evolution, and trying to influence that evolution when it is going astray.”

I’m not suprised.

And it’s not that I wrote that post on the first occasion when I had troubles. Indeed I had troubles – though not as massive – with 2.7 before, and also when trying to get Akka to work before this one happened. So it’s more like a pattern. So no, I’m not surprised.

“[...] and trying to influence that evolution when it is going astray.”

Bingo, hence the post ;-)

You generalize quite aggressively from your unpleasant upgrade experience that Scala is unfit for serious use. This is factually inaccurate as substantial applications are running production code with Scala (twitter, linkedin, foursquare, The Guardian). And we are just talking about the companies that care to disclose what they are using.

“The developers are interested in language research and writing papers, not in making a language for real development”. I see it quite differently. I think the core team is trying very hard to balance bringing new features yet having a language that can be used for real development. The whole business about those seemingly endless 2.8.0.RCx was to give a chance to the eco system to adjust before the release.

Of course, Scala adoption is still small comparatively speaking and 2.8.0 final has not yet been released. So you have to be mindful of that if you want to use it for serious development.

But it can definitely be done. I have used 2.8.0.Beta1 quite successfully for work to perform XML processing on 600MB+ files where Scala was a great fit because of its XML literals and capability as well as leveraging Java XML ecosystem. This is deployed in a production environment.

I’ve very hopeful that as Scala gains wider adoption, it will have a rich ecosystem (plugins, IDE and editor support, books, libraries, …) and a bigger industry support.

“Scala is perfectly fit for *serious* development. Maybe you are not fit for Scala?”

This might always be the case, but isn’t very satisfying as an explaination, as it can explain everything.

yes, scala 3.0 would have been more accurate but I do not think your problems are really tied to the version number per se and personally I do no think the situation would have been any better if scala 2.8 had been called 3.0 (ie binary incompatibility would have been equally annoying)

>But you need to do develop before production if you use something new.

Yes, that is true, however, if you are working against pre-released software, then unfortunately things can break more frequently.

>As commented above, I do not think this is a 2.8 issue (hence the title) but a Scala issue. And although you do not use it in production, you need to get it going if you plan to release later your production code with 2.8. And if your main branch lands in incompatibility hell, you’re stuck fro some time.

the binary compatibility issue is not tied to 2.8 per se, so yes, in that sense it’s a generic problem. And also, If you are using two libraries where both have only 2.8 RCX versions, then yes, it can be very painful until 2.8 finally comes out (which should happen really soon now btw)

Martin repeatedly said that 2.8 was going to be the last binary incompatible release. It remains to be seen whether that turns out to be true or not.

Ruby doesn’t have a 2.0 release. The latest version is 1.9.1, which was a long time coming and introduced non-trivial breaking changes. As a result, most everyone uses 1.8.7. Does this sound familiar? Your point about Scala versions (2.8 vs 3.0) is valid, and I agree with it whole-heartedly, but Ruby has been doing the exact same thing as Scala in this regard. Bad example.

2.7.7 is serving us well in production, and we are standing back to let the dust settle before jumping to 2.8.

Anyone using Scala seriously, or even considering using Scala serious, should be actively following its development.

1. Is untrue, but many do care about writing papers. Scala needs more contributors who are more concerned with day-to-day software development.

2. There has been substantial debate on this topic on multiple occasions. The general consensus seemed to be there was no good solution. 2.8 was long advertised before people realized it was such a huge departure from 2.7. Also, there some members of the community who feel 3.0 should be more feature complete and stable. There’s still a lot missing from the standard library. There are still a lot of unsolved problems.

3. Is untrue. This topic has received substantial discussion and thought, but binary compatibility in Scala is hard because of the way traits work. Making a small change in any Scala code base can break binary compatibility. Someday there may be a solution, but it will probably require that paper-generating type work that you complain about in #1.

4. In this statement you imply that they shouldn’t make changes that they see fit. I don’t think that’s what you mean. What you mean is that they make changes without significant consideration. I there are parts of the library where that is true but in most parts it is not true.

5. The RCs for 2.8 started too soon. You don’t make up for one mistake by making another.

But my general point is that most of this is happening in public for a long time now. No one using Scala seriously should be in the least bit surprised, because if you use a technology seriously you should be paying attention to its evolution, and trying to influence that evolution when it is going astray.

Scala is unfit for serious development by those who aren’t prepared to make a serious investment in Scala.

See my comment above about communication and perception.

With a Rails 3.0, Python 3000 or Ruby 2.0 communication approach, perhaps library authors wouldn’t have jumped into it so soon or with their main branch.

“3-5 These points seem to mix a few things.”

Might be, I’m incoherent, illogical and annoying from time to time.

“I always advice *against* using it in production just yet.”

I wouldn’t use Play in production right now, as I do not know how it behaves or how it scales (Flow through exceptions and one-thread especially). But you need to do develop before production if you use something new.

“I would strongly advice against writing production code in 2.8 yet (since it’s not released)”

As commented above, I do not think this is a 2.8 issue (hence the title) but a Scala issue. And although you do not use it in production, you need to get it going if you plan to release later your production code with 2.8. And if your main branch lands in incompatibility hell, you’re stuck fro some time.

If the Scala developers would try to make it 100% backwards compatible, it would be nice for you if you have a lot of existing Scala code.

However, it would also mean that Scala can’t develop as quickly as it does and that a lot of deprecated cruft would accumulate in the Scala library.

One of the reasons that the development of Java goes so slow now is because every new version must be 100% compatible with everything since Java 1.0 – this makes it very hard or impossible to add new features to the language. The Java library is also bloated with old deprecated junk that can’t be removed.

I’d rather have the Scala developers make Scala good and lean than heavy with deprecated stuff and holding back development because of compatibility concerns.

And the version numbering… does it really matter that much that it’s called 2.8 instead of 3.0?

And don’t complain about the instability in pre-release versions. Just wait a few weeks for the final 2.8 to be out if you want a stable version for serious development.

As for me, I’m happily making money out of Scala projects for clients. As always you should assess the impact before upgrading – and don’t bet the farm on an unreleased product. I found moving from 2.7 to 2.8 very easy to tell you the truth.

I think some people here have forgotten the early days of Java, and just how bad it was to work with when it was at Scala’s current level of evolution. In the absence of multi-million dollar corporate backing, and taking into account the challenges of wrangling an open source language, the Scala project team are doing an superb job in my opinion.

No risk, no fun.

Be honest: How much professional development is done with languages, libraries or tools which undergo breaking changes from time to time?
The job to be done then is called Migration!

This is not always avoidable, as desirable as it might be. I can tell as a framework developer for an ERP size app, that the requirement for strict backward compatibility can extremely hinder necessary steps in evolution, not resulting in better versions but even more hacks and weirdnesses just to squeeze new requirements in without breaking things or touching anyone.

(And Java itsself may count as an example here).

Regarding the fact that Scala is currently just on the way to leave its teenage state, I would give it all the time and growing pains it needs to get a clean and stable 2.8 which (when final!) can be marketed.

“I’m more interested in getting things done than in language features.”

If you’re not interested in language features, then why even talk about 2.8 ? Why not stay with 2.7.7 final? or with Java btw?

Once again: 2.8 is not released yet!
And I work with 2.8 because I _am_ interested in the language features which _will_ help me getting things done better _tomorrow_ .

And the EPFL people _are_ aware that Scala is currently still in a research mode, and bringing it to the broad mass is a _todo_ .
They say it themselves, so I can absolutely not understand this lamentation here.

A Scala foundation was in the talk and will some day see the light like it was for many other languages which even started as one-man-show.

Regarding “making money” again: As you are an experienced professional you should already know that companies can make money with much worse tools than Scala, and there seem to be companies which already have enough positive experience with it despite its current state.
(BTW: In my ten years of Java experience I cursed often enough about that ecosystem too, because it made things too complicated to simply let me focus on creating production code).

So in the end, following the discussion here and your statement about loving Scala on one hand, all that remains is a more or less implicit: “I don’t like the people”.

And to be honest: If I would have known that before I would not have bothered opening the link to this page. I expected a debate about the usability of Scala and its concepts, not lamentations about some folks.

1) I agree with this point (I do not know anybody in the Scala community who does not). This is a serious problem and it scares the hell out of me that I still do not know for sure whether this is going to be the last time when it happens.

2) Personally, I do not think the version number matters that much, I would have been OK with either version number.

3-5 These points seem to mix a few things. As for the language: yes, scala 2.8 has changed a few times within RC-s and it was annoying (but also kind of expected in a developer branch) and yes, 2.8 breaks compatibility on both source and binary level (this was not necessary expected, however, it was communicated) and yes, some of the APIs disappeared without any warning period(the jcl package etc.)

As far as the big libraries are concerned (lift, scalatest,spec,sbt,akka),however, I did not really see the bad API handling you mentioned though. These projects usually have 2.7 and 2.8 branches, so you should build your production code against 2.7 version and switch to 2.8 when you think you can. Most developers are using RC-s not because they are obsessed with cutting edge but because they want to prepare for the new version as well. So I strongly disagree with your generic comment about the community ie “developers and the community is unwilling”.

Now as far as the project I am involved with(ie play-scala) is concerned: I always advice *against* using it in production just yet. Why? because it’s built against a developer branch of play (which is subject to change) and it’s built against a developer branch of scala(which is also subject to change) plus because it’s a preview, we are tweaking our own APIs. In our case we could not use 2.7 because play needed the incremental compiler introduced in 2.8 and package objects (also introduced in 2.8) to provide proper API-s for both scala and java versions. So yes, in our case it is bleeding edge and you will bleed but this is not the case for most well-known scala libraries is my point.

>I would not bet millions of euros on a exploratory language, but YMMV

I would strongly advice against writing production code in 2.8 yet (since it’s not released) but personally I think 2.7 is mature enough. As for betting millions of euros: there is some risk involved in introducing any new tech, so you have to identify the pros and cons and make your own decision.

1. “But, such stuff is more commonly pursued via libraries and compiler plugins nowadays[...]”

Rapid or completly changing libraries are not the solution, they are probably an even bigger problem than additional language features. So this is the wrong direction from the point of stability.

2. ” It was not a happy choice, but sticking with 2.8 was seen as the lesser of two evils.”

As proven, this was not the case. So they need to think about their decisions deeper next time. And commit in public to a different model in the future. But reading Scala org there has been no public announcement.

5. ” The “Fresh Scala” initiative, to run a nightly build of several important 3rd party projects against trunk versions of the compiler”

This illustrates the problem, same as Eclipse tried to solve this without success. This is not a solution this is playing with symptome.

“The ability of SBT (Simple Build Tool) to cross-compile source code against multiple versions of the Scala library and release different jars for each.”

Same here. This illustrates they do not want to change something fundamental, but live with the current model but make it possible to live with their choices. This is the wrong direction!

“Mostly because 2.8 was too long in the making, and is so far ahead of 2.7. It was originally conceived as just a reworking of the collections library, but then became so much more…”

You see the point? No planning, wild development, throwing new features on a train wreck,…. then read the title of the post again.

“The delay in releasing 2.8 is widely acknowledged as a failure,[...]”

Could you point to an official announcement on the Scala site?

“For reference, subversion experienced almost the same issues in the run-up to their 1.5 release, and made a process change following that.”

Nowhere the same level. We had 1.4, 1.5, 1.6 with some minor glitches.

“1. The developers are interested in language research and writing papers, not in making a language for real development”

This is only partly true. Scala has a strong legacy in being used to showcase academic concepts, and it’s definitely seen a good vehicle for future work of this nature. But, such stuff is more commonly pursued via libraries and compiler plugins nowadays – Compiler plugins were added as a feature with the explicit goal of moving such risky work away from the core language.

“2. The version hell that is 2.8 – calling this version 2.8.0 is deceptive. As Python (3000) or Ruby (2.0) this should have been a major version called 3.0″

Most definitely, and Martin Odersky himself would be the first person to agree with you.

Unfortunately, when the actual breaking change occurred, there was far too much published material in the world referring to the upcoming 2.8 release. It was not a happy choice, but sticking with 2.8 was seen as the lesser of two evils.

“4. The developers do not care about binary compatibility, deprecated, soft migration or API compatibility. Things are changed on a whim – from one RC to the next, and they change major parts of the language/libraries in point releases”

“5. They remove and add classes just as they see fit”

These are just different ways of saying the same thing. In truth, everybody is concerned about binary compatibility, and it’s widely considered to be Scala’s largest flaw. EPFL has a couple of suggested postgrad research tasks devoted to this exact issue. Many of us are also pursuing various ways to mitigate the problem until a better solution is found.

These include, but are not limited to:

- The “Fresh Scala” initiative, to run a nightly build of several important 3rd party projects against trunk versions of the compiler – and publish them all to Maven if (and only if) they ALL pass unit tests.

- The Incubator and Greenhouse, to allow new ideas a longer maturation and testing phase before deciding if they belong in the core library.

- The ability of SBT (Simple Build Tool) to cross-compile source code against multiple versions of the Scala library and release different jars for each.

Nor are things changed on a whim. The only acceptance criteria now for a bug to be fixed in a 2.8 release candidate is “is it a regression against 2.7.7?” All other issues are being pushed to 2.8.1 or beyond.

“6. The community loves cutting edge. Instead of fixing bugs they upgrade to all new released RCs – so have you. It’s called cutting edge for a reason: You’ll cut yourself. And it’s called bleeding edge because you will bleed.”

Mostly because 2.8 was too long in the making, and is so far ahead of 2.7. It was originally conceived as just a reworking of the collections library, but then became so much more…

The delay in releasing 2.8 is widely acknowledged as a failure, and there are efforts in the community to move to a more structured release schedule that will mitigate this sort of thing in future releases.

For reference, subversion experienced almost the same issues in the run-up to their 1.5 release, and made a process change following that. It’s considered fit for serious development nowadays (though I do remember a couple of people having doubts back when it was happening)

Java has it’s JCK (https://jck.dev.java.net/) and OpenJDK Developers’ Guideline (http://blogs.sun.com/darcy/resource/OpenJDK_Developers_Guide/OpenJdkDevelopersGuide.html) this has to be done for Scala at some point in time.

Then we need to divorce. I would not bet millions of euros on a exploratory language, but YMMV.

I think this is the right mindset for Scala. It’s exploratory language.

It has the best productivity in some areas. That is the reason it is actually used for serious stuff. This feedback is essential, otherwise you have a chicken and egg problem on the one hand you have old/tested/unproductive languages and on the other hand you have ivory tower languages than aren’t tested in the real world.

I really do too.

I’ve experienced exactly the same things with the 2.8.0 RCs: Libraries compiled against certain RC versions won’t work with others, IDE plugins also require certain RC versions, lots of class hierarchies changes behind the curtain… .

Moreover, compare with javac, scalac is really slow, compilation reminds me of C++ ;)

The sad thing is, I really like Scala the language. So far, I haven’t really found any ugly spots, usually things turn out to be quite elegant.

Probably its time to take the lessons learned and start a new project from scratch, this time focusing on a cleaner development environment.

If a early adapter and a awesome developer like you face issue in dealing with, think of the average ones, this kind of breaking changes needs a serious attention from scala community.

If Scala needs to be adapted by average developers then tooling support, backward compatible APIs and issues like this has to be taken very seriously.

Disclaimer: Im a big fan of scala as well.

The leastest JDK 5 release was 5 years ago, had mostly minor features on the surface and is backwards compatible.

Scala released are more frequent, change a lot at the surface, introduce a lot of language features, break source and binary compatiblity.

You have to pick which mode of platform evolution does fit to your project.

Btw, updating from Java 6 to 7 will be more like from 1.4 to 5 than 5 to 6. Java was very static since Java 5 was released.

And the issue was there before 2.8.

@Benoît: But you have very little problems coming from the language in Java – mixing 1.4, 1.5 and 1.6 code is a non-issue, tools help a lot.

“It is clearly the good time, and the last time for Scala to break the compatibility to produce a good language without the old pans…”

The attitude doesn’t change, so the problems won’t change either. It will be the same next time, because of “urgent changes” – only this one more time.

@Ulf: +1

F# is a wonderful creation and fits your criteria better than C#… but it is sadly still tied to the .NET platform for execution.

What I don’t understand is, if you want to do serious development, why do you even use release candidates? Why not just wait for the final release and then upgrade?

– Mirko

The more pointed variation on the subject is “Scala is more compatible with Java than with yesterday’s Scala”.

Reminds me a of the C++ of old, the difference is that the Java background now is shining with a level of perfection in compatibility that was unheard of in the days when C++ introduced new levels of incompatibility that variants of C did not have.

I am a Java dev for a long time too. And the binary backward compatibility of Java across the version is just one of the big mistakes of Sun.

Because of the backward compatibility, generics are not complete, autoboxing is just something you have to think of, but don’t use, and a lot of dev are still using Vectors !!!

The choice not to be compatible between 2.7 and 2.8 has clearly been annouced.

It should have been called 3.0, you are right. But it would have been disturbing for Java dev, wich are used to have major language upgrading with a minor version upgrade (thank you Sun, you know: 1.5, 1.7, …).

It is clearly the good time, and the last time for Scala to break the compatibility to produce a good language without the old pans…

Hope things will get better when 2.8 final is released (these incompatibilities between version frighten off development effort…).