
Scala 2.8.0 final - fogus
http://www.scala-lang.org/node/7009
======
joevandyk
Someone needs to write an intro to scala that assumes no prior java
experience. I know Ruby, C, C++ and others on a *nix quite well, but I have no
clue about anything Java-related. This is a problem when I'm trying to figure
out how to deploy a self-contained scala application.

~~~
sreque
I googled for an answer to your problem and found this: <http://www.scala-
lang.org/node/1305>.

The link basically recommends that you learn Java first :). For better or for
worse, Scala relies a ton on Java, and no one has created Scala-specific tools
to simplify some of these things you can already do with existing Java tools.

If you want to create a self-contained jar, the following URL has people
discussing how to do this with SBT and Maven: <http://www.scala-
lang.org/node/6750>. I wouldn't wish the curse of Maven on anyone, let alone
someone who hasn't been force-fed it by the Java community for a while, so I'd
recommend trying to learn sbt and then port the solution posted in the above
link to your own sbt project. I really wish the solution were simpler, but
Java tools have always focused more on server-side web deployment and have
always been weaker in the area of client-side deployment.

~~~
ant5
* I wouldn't wish the curse of Maven on anyone, let alone someone who hasn't been force-fed it by the Java community for a while, so I'd recommend trying to learn sbt and then port the solution posted in the above link to your own sbt project. I really wish the solution were simpler, but Java tools have always focused more on server-side web deployment and have always been weaker in the area of client-side deployment.*

I've only ever used maven for Scala projects, but I've come across this
sentiment a few times -- it always strikes me as odd, given that I have very
few significant maven complaints.

It has all sorts of great tools for automatically fetching dependencies, and
doing "the right thing" via some fairly simple conventions. It's really easy
to wire up something like tomcat:run to run a war in-place -- or your own
custom self-contained code.

I also really like being able to have a local maven repository where we can
store our own build products (and declare dependencies against them); server
software like Artifactory makes this very nice:
<http://www.jfrog.org/products.php>

Maven isn't wonderful, but build tools never are. I don't understand why you
would hate it. Why do you hate it?

~~~
sreque
I agree with most of what you said. I like the idea of Maven's dependency
management and repositories. It's also nice to have a lot of plugins to take
care of common build system use cases for you. I just happen to hate the rest
of it. Fortunately, I can get the best of both worlds. Buildr, Gradle, Ivy,
and sbt can all work with maven repositories. So I can take the best of Maven,
a.k.a, the one and only really good thing about it, and use it with better
build tools!

Now, as to why I hate maven, these several-year-old posts explain it better
than I do.

[http://labnotes.org/2007/05/03/buildr-or-when-ruby-is-
faster...](http://labnotes.org/2007/05/03/buildr-or-when-ruby-is-faster-than-
java/)

[http://labnotes.org/2007/04/18/introducing-buildr-or-how-
we-...](http://labnotes.org/2007/04/18/introducing-buildr-or-how-we-cured-our-
maven-blues/)

And of course on StackOverflow Daniel Spiewak gives an excellent example of
how Maven just falls flat.

[http://stackoverflow.com/questions/1015525/why-use-buildr-
in...](http://stackoverflow.com/questions/1015525/why-use-buildr-instead-of-
ant-or-maven)

Really, it boils down to the fact that I believe that the philosophy of the
Maven creators about build systems is fundamentally flawed. They say "when you
want to script you know you're doing something wrong". I say, I'm a mature
programmer, so give me a mature tool that enables me to get my job done.

Case in point. For a simple side project I was using JAXB to create an xsd
from java classes. JAXB wanted me to maintain a flat text file listing all of
the classes I wanted included in the xsd. I knew for a fact that every single
java file inside a particular directory (recursively, of course) needed to be
included in that xsd.

If I were using Maven, I would properly just resign myself to the fact that
there is no JAXB Maven plugin to do what I want. I would therefore just
manually update the file every time I added, deleted, or renamed a java class
in this directory, which turned out to be very frequently during development.
I certainly wouldn't feel it would be worth the herculean effort of writing a
maven plugin and figuring out how to wire the file dependencies together so
that the required tasks only run when needed.

Fortunately, I was using buildr, and 50 or so lines of scripting code later I
had a perfectly efficient and automated solution to my problem. Now this was
for a simple side project. Imagine a real product created by a real company.
Do you really think that company won't ever have any custom build needs that
go beyond the provided maven plugins?

Why waste your time with a limiting, clunky, slow, XML-based build system when
you can use one that is designed better from the core and therefore easier to
use, more flexible, more maintainable, and, best of all, faster because
developers can afford to spend more time to wire things together efficiently?

------
ant5
Scala isn't perfect, but it's a great language to have on the JVM.

However, the lack of API and ABI compatibility is a really big failure. I
can't believe that they're shipping what is supposed to be stable software and
we can't rely on our code to continue running, much less building.

We had to do a fair bit of work to fix our projects' 2.8 compatibility issues,
and it's causing us all sorts of grief in terms of having to do lock-step
upgrades of all libraries from 2.7 to 2.8.

~~~
joshhart
Would you rather Java? Where everything is shit because of backwards
compatibility?

They've put a hell of a lot of work into making everything as compatible as
possible with 2.7. At some point you need to say, enough is enough, we're
going to upgrade out and people will have to make minor changes to their
source code to get the new features. They had 7 release candidates, so they've
made a commitment to quality and given people time to upgrade leisurely.

~~~
ant5
_Would you rather Java?_

Is that a real question or were you just setting up your false dichotomy via
some well-placed rhetoric?

 _Where everything is shit because of backwards compatibility?_

Oh, so that's why Java is so bad? Because it has some stagnant corners in
which they're maintaining backwards compatibility? That's silly.

Backwards compatibility isn't holding back Java the language, or even Java the
VM. Bad design decisions and an almost knee-jerk opposition to _any_ forward
progress holds Java back. You don't have to break compatibility to implement
closures, you just have to herd cats until you can get people to agree on a
proposal and implement it.

 _They've put a hell of a lot of work into making everything as compatible as
possible with 2.7_

But it's not actually compatible. And it may not be again in the future. And
it's really easy to introduce binary incompatibility due to the implementation
of traits.

If you look at other production programming environments, from C# to
Objective-C, the maintainers bend over backwards to maintain binary and API
compatibility across releases because it's bloody expensive to upgrade
everything in lock-step, force all your customers to upgrade, wait for all
your vendors to upgrade, and move the entire ecosystem to a new version in one
gigantic step.

 _At some point you need to say, enough is enough, we're going to upgrade out
and people will have to make minor changes to their source code to get the new
features. They had 7 release candidates, so they've made a commitment to
quality and given people time to upgrade leisurely._

Upgrade leisurely? To a release-candidate quality language release? Are you
joking? Even if we wanted to upgrade to an RC release (and we didn't!), we'd
had to wait for the libraries we depend on to be updated too (and wait for
time to block development while we upgrade all internal components in lock-
step).

~~~
andrew1
That's an excellent response, and I'd mostly agree with you.

I'd only add two things; firstly, I got the impression at Scala Days and from
mailing list discussions that there was a little bit of a feeling that 2.8 was
the last chance to fix some design choices that the designers didn't like.
That Scala is big enough and well used enough now that they're not going to
get away with the same behaviour for 2.9 or 3.0 and that there will be a lot
more concern for compatibility in future. Whether it happens remains to be
seen I suppose.

Secondly (although you might disagree with this), there are no glaring
problems with 2.7 so there's no need to rush to upgrade to 2.8, there
shouldn't really be a problem with waiting 3-6 months for your dependent
components to release (stable) 2.8 versions. I think that we're lucky that we
don't depend on many external libraries so we'll be upgrading pretty soon, but
it wouldn't be the end of the world if we had to wait a few months.

------
frio
Does anyone know if there are any plans to update Odersky's "Programming in
Scala" book? I'm intending to buy it in order to learn Scala, but if there's a
second edition pending I'd rather hold off.

Alternatively, if someone knows a better community that could field this
question, I'd really appreciate being pointed in that direction. One thing
I've not really grokked about Scala is where to go to ask such things!

~~~
jorgeortiz85
AFAIK, there are no plans to update "Programming in Scala". But most (if not
all) code examples from PinS should work with Scala 2.8.

The scala-user mailing list (<http://listes.epfl.ch/doc_en.cgi?liste=scala-
user>) is the best place to ask (and get answers for) newbie Scala questions.
Using the "scala" tag on StackOverflow also produces good results.

~~~
frio
Thanks for that. I've been using StackOverflow for a few simple questions, but
I'll check out the mailing list too!

------
aschobel
Fantastic, is this release safe to run in production?

I recall there being a few missteps w/ earlier releases. Actors in 2.7.4
didn't seem to be thoroughly vetted.

~~~
jorgeortiz85
Scala 2.8.0 went through a very long RC process (7 RCs over the course of
several months) to try to prevent a repeat of 2.7.4.

------
gtani
Martin Odersky's plans:

[http://codemonkeyism.com/scala-unfit-
development/#comment-30...](http://codemonkeyism.com/scala-unfit-
development/#comment-305659)

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

