Scala is Unfit for Serious Development

And the IDEA plugins freezes all the time for seconds (sometimes even have to kill IDEA). Is there any usable IDE plugin? SBT rocks, however.

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

I can’t let you say these things in that way.

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…

Someone would eventually have to say it out loud.

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.

Hi

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

“Would love to use C# if not for Microsoft”…

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

Will be interesting to see what happens after 2.8 with regards to stability. Wouldn’t surprise me if someone attempted to fork Scala and keep the feature-set more static..

You should correct your title to “Scala 2.8 is Unfit for Serious Development”. This not news. It’s not released yet. Would you expect to have a stable OpenJDK 7 now (we should have feature freeze by now as far as I do remember)?

Everything has it’s price.

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.

What ever the language, How good it is, how many feature it no one bother’s it if its not stable. To be a mainstream language it has to be used by the “average” developers not by researchers.

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.

Hello Stephan,

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.

> There is a reasearch paper? Whoops, now it’s a language feature.

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.

> millions of euros
Or you could devote some work to actually making this better.

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.

80% valid concern, 20% FUD. I’m seeing exactly the same issue, but have a different opinion of it:

“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)

They have spoken of the problem in recent talks, and there seems to be a plans for two development paths. One stable, and one rapidly changing for research. It might not help on external library stability, since many of us are mostly interested in exploring new stuff. :)

Exploratory features are great, but should be relegated to compiler plugins. From there they can eventually graduate if they provide enough general benefit.

Awww… C’mon!
First, as pointed out, the title would me more accurate if it was “Scala 2.8 RCs unfit for serious development”
I don’t see LinkedIn, Twitter or Foursquare having problems with making money with Scala ;)
Regarding your points:
1 – I think is unfair, the goal of Scala was to make a language for “the real world” and not for academics. We can try to second-guess that, but it won’t be a very solid argument.
2 – Everybody agrees that 2.8 is not the right label, but the cat is already out of the bag and the ship has sailed :D
3 – I think is related to #2, I don’t think that breaks between RCs are a big deal. Otherwise, I think is a problem already acknowledged by Martin, he said this will be the last breaking version…
4 – I’ll do the same in my projects :) This is a breaking release and is painful… I’ll chalk it up to growing pains
5 – You can do serious development and make money in the cutting edge, and the previous versions are pretty solid (IMHO) but yes, the community loves cutting edge, otherwise they would’ve stayed in Java (or COBOL!)

Hi Stephan,

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.

“I would not bet millions of euros on a exploratory language,”

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.

I think anyone working seriously with Scala knows that 2,8 is a major move forward. If they scrubbed out the 2.8 label and replaced it with 3.0, I don’t see that it is going to help many, except perhaps Scala newbies.

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.

There are pros and cons with regard to compatibility.

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.

I don’t think your assertion that the Scala community doesn’t care about such issues is fair. It does care. I think it cares deeply. But caring deeply about something doesn’t mean you know what to do about it.

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.

It’s kind of your choice to go bleeding edge, isn’t it?

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

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

Most of what I want to say in reply to this post has already been said, either by myself on Twitter, or by other commenters. So the only thing left to me is a minor quibble about your version numbers point… :-)

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.

Did you consider Groovy++?

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

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.

stephan,

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.

Nice post, better comments, even better twitter response.

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.

@stephan
I think influence right now is best accomplished through contributions to the code, documentation, and infrastructure (build process, testing – these are substantial weaknesses in Scala development right now). The direction of open source communities tends to be driven by the interests of the dominant contributors. Right now, at least to my knowledge, all the primary contributors are either academics or dot com millionaires who have found a new passion (ok, I think there’s only one of those, but he produces enough code for several).

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

Stephan, you may want to check out the Fantom language ( http://fantom.org .)

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

You have no idea how much effort you are casually dismissing when you claim to have specific knowledge of what the developers don’t care about. The only person about whom you said anything meaningful in this post was yourself. And it was unflattering.

I think it’s great that Scala is still evolving fast. But I guess that it will become more stable when it matures further. It’s unfair to say it will be unstable forever, you can’t possibly know that.

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.

While I agree Scala language version numbers are rather unclear about release types; I find it weird that you want to write production code on bleeding edge releases of Scala, knowing that it will bleed. Expecting the magic, are we?

>Update 2: Community response as expected: Everything is fine, personal attacks, move on. How sad.

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)

“I haven’t seen their code”. Some of the code is available on github:
http://github.com/twitter
http://github.com/steppenwells/open-platform-content-api-scala-client

You code is online?

@stephan

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.

Wow, the grammar in my previous comment is absolutely dreadful! Moral of the story: when composing a comment in a non-linear fashion, be sure to proof-read from start to finish *before* clicking “Submit”. :-)

My rebuttal http://james-iry.blogspot.com/2010/07/code-monkeyisms-post-is-unfit-for.html

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

Stefan,

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.

Hi 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,…

@Martin
3. yeeeeeeeeeeeeeeeeeeeeeeeeeeeeeessss!!!!

@Stephan
_

One further observation

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.

@kevin, that’s a good point, I just started a community site to address this PR issue. http://scalascoop.tumblr.com/

contributors are welcome.

I feel your pain. I just want to learn the language and use my preferred development environment (NetBeans). But it wont work!

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

None of these arguments are really new – I wrote about them at length before.

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.

[...] Scala is Unfit for Serious Development controversial, interesting [...]

Stephan, one thing I really do *not* buy:

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

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? ;)

[...] da beschwert sich Stephan Schmidt, dass Scala (noch) nicht „produktionstauglich“ wäre: Scala is Unfit for Serious Development. Das zieht natürlich Kreise, z.B. bringt JAXenter einen Artikel darüber – und die [...]

Stephan,
which libraries? How were you forced?
Become specific.

2.8 final is out. Can we all go back to work now ;-)

I think there’s been enough hurt getting 2.8 out that there will be big improvements for 3.0. I watched the roadmap video from the Scala-days and was re-assured that the next phase of maturity is coming. Subsequent releases will probably be smaller (a good thing) so although the comparison will be harder, life will be easier for compiler and library writers alike.

[...] Scala is unfit for serious development [...]

[...] e mudanças na estratégia de Collections para aumentar a compatibilidade com o Java), muito se especulou sobre a estabilidade da linguagem e muitas discussões acirradas (vejam os tweets entre @jboner e [...]

No working IDE, no stability, no clue – Scala is unfit for production, I could not agree more. Excellent post.