

Scala is Unfit for Serious Development - tszming
http://codemonkeyism.com/scala-unfit-development/

======
hdeshev
I started learnimg Scala in the midst of the "2.7 vs. 2.8" turmoil and all I
can say is that it wasn't just fairies and unicorns. Hopefully that's gone now
and everything I use seems to work with Scala 2.8. All I can say is that I
love the language and I keep using it. It's fit for super-serious development.

I sometimes think the problems came from library authors that jumped to Scala
2.8 too soon. Kudos to the Lift framework guys for maintaining builds that
work both with Scala 2.7 and 2.8!

------
joshhart
Whatever, this hasn't stopped me from writing LinkedIn's distributed social
graph engine in it.

------
melling
This article is several months old. Are people happy with the 2.8 release? Is
now a good time to adopt Scala and to start using Scala in production?

~~~
wheaties
Go out and start using it. Sure 2.8 was a major upgrade but everything
improved with that update for the better. Martin's reply is key. He's
completely behind making the language a real success.

~~~
gtani
2.8.1 was mostly a bugfix release. <http://www.scala-lang.org/node/8102>

------
stupidsignup
I am happy with 2.8, I use it to develop another programming language :-) I am
careful though to depend not too heavily on Scala libraries, because of
surprises I have experienced in that area, too. But honestly: there is just no
other programming language as mature as Scala while being as productive (until
my new programming language is finished, that is :-))

------
endtime
>Would love to use C# if it’s not from MS.

I find it hard to take someone with an opinion like this seriously.
C#/.NET/CLR is a fantastic platform, and if it does what you want (and Mono is
sufficient for your cross-platform needs) then that's all that should matter.

------
CCs
We are using 2.8.0 in production and so far it is OK. Porting old 2.7.x code
to 2.8 is painful, but new code works as advertised.

Still pain: the only working IDE is Emacs+ENSIME, documentation is scarce,
learning curve is very steep.

On the other hand it will force you to hire only top developers, which is a
good thing. :)

I'm still not sure if I shouldn't pick C++0x instead (really). I wish there
was a C++ port of Lift.

~~~
srnm
<http://www.scala-ide.org> has come a long way and can be usable and useful. I
recommend a clean install of eclipse 3.5.2 with the latest recommended build
of scala-ide. Try things out without installing additional plugins except your
favorite version control support. I like the refactoring and code reformatting
support!

I've recently started using the IntelliJ EAP X builds for a personal project
in Scala and find it usable and useful too.

The maven-scala-plugin is solid and will let you switch between IntelliJ and
Eclipse relatively easily. I don't use the maven eclipse plugin but instead
"mvn eclipse:eclipse" from the command line whenever the pom changes. Using a
pom-based build is useful in a production environment especially if you are
using/providing components from/for others. IntelliJ has maven support built-
in and seems to work well.

I've only pushed the IDEs to ~40 source files. Things might start breaking as
the projects get bigger.

Things are definitely better than they were a year ago and thanks to both the
scala-ide and IntelliJ people!

~~~
gtani
Haven't used IDEA/scala plugin in a few weeks, but i did have to mess with
heap and other config options per:

<http://news.ycombinator.com/item?id=1438408>

<http://www.assembla.com/wiki/show/snapimpact/IDEA_9CE_Tip>

[http://leshazlewood.com/2007/08/01/intellij-idea-on-mac-
os-x...](http://leshazlewood.com/2007/08/01/intellij-idea-on-mac-os-x-setting-
java-vm-options/)

------
eddieplan9
Offtopic, but is it just me or the author's taste of font is very unique.

~~~
tptacek
The kerning on 'il', 'll', and 'li' in "calling", "will", "compatibility", and
(ow) "unwilling" was painful.

------
lhnn
This sentiment is how I felt about Grails a while back.

I think the big issue is versioning. Learn it! A.B.C

Changes in C denote bugfixes, small changes, etc.

Changes in B denote feature additions/deprecations, non-API breaking changes,
etc.

Changes in A denote major architecture changes and/or backwards
incompatibility.

THUS:

Everything with "A.x.x" is compatible with previous versions of A.x.x.

Everything with "A.B.x" is compatible with everything else of A.B.x.

As the author stated, Scala 2.8 should have been Scala 3.0. It seems to me the
author is less peeved about the change itself, than the confusion caused by
not using version numbers the way many people expect, i.e. with meaning.

~~~
xiongchiamiov
If you like this a bit more formalized, take a look at Semantic Versioning (
<http://semver.org/> ).

That's one of my primary issues with Ruby.

