Scala has been gaining steady acceptance as a statically-typed JVM language with a significant library that is also ready for production use. Earlier versions of Scala have already pushed beyond Java's language features. The latest Scala version, 2.8, which was released today, adds a large number of enhancements, and features:
Redesigned collection library: The collection library has undergone a complete overhaul for Scala 2.8, offering a more coherent and efficient design, while maintaining virtually complete compatibility with existing sources.
Enhanced actors: New Reactors provide more lightweight, purely event-based actors with optional, implicit sender identification. Support for actors with daemon-style semantics was added. Actors can be configured to use the efficient JSR166y fork/join pool, resulting in significant performance improvements on 1.6 JVMs. Schedulers are now pluggable and easier to customize.
New array implementation, manifests for polymorphic arrays:
Handling of arrays has been simplified and optimized in Scala 2.8. The previous compiler magic has been replaced by a more systematic and predictable implementation in terms of implicit conversions.
Type specialization: Scala 2.8 adds specialized type parameters, which enable the compiler to generate transparently multiple versions of a given definition, and to use the most specific version whenever the static type information at a call site allows it.
Named and default arguments: Named arguments improve the readability of method calls with many arguments. Default arguments reduce code duplication, and enable "copy" methods for case classes, useful to generate quickly modified copies of case classes.
Packages can now contain besides classes and objects also methods, fields or type aliases. These are added to a package by declaring a package object.
Support for continuations: Continuations are supported by a compiler plugin, which is now supported as part of the main distribution.
What do you think of the new features in Scala 2.8?
Huray! It's out! Congratulations to everybody involved.
It's interesting that the change that I am expecting most from isn't listed, which is stability. It has been said a couple of times already, but 2.8 really is 3.0, and this time, I really do expect 2.8 based libraries to be compatible with future versions of Scala, for some years to come.
(Being an old Sun employee, I do sort of appreciate the implicit reference to Sun's confusing versioning schemes though.)
Scala looks really modern and impressive. The one thing I hope for Scala is that it is not perceived as yet-another-JVM-language and Martin Odersky seems to have confirmed that the .NET implementation of Scala, which was stalled, will keep track again.
This would in fact open a niche for Scala, namely building robust base level components ( algos + datastructures ) which can be used within all major enterprise environments. Application stacks built upon them will follow in particular when I interpret the mood of the youngsters right, who are hot on functional programming and computing science stuff.
Scala is right now my only candidate for a language which might grow big, based on its merits and not because of accidental product success ( iPhone + ObjectiveC ) or other environmental conditions.
I wonder how much interest in Scala is generated by it being perceived as a hybrid JVM language with decent Java-like performance, compared to the more scripting-oriented languages like Groovy & JRuby. If so, I wonder whether the new Groovy++ enhancements will bite into Scala's mindshare.
> I wonder how much interest in Scala is generated by it > being perceived as a hybrid JVM language with decent > Java-like performance, compared to the more > scripting-oriented languages like Groovy & JRuby. If so, I > wonder whether the new Groovy++ enhancements will bite > into Scala's mindshare.
Scala provides all the benefits of static typing while eliminating a lot of the costs often associated with it (redundant declarations, etc.) While performance is a benefit of static typing, it is not the only one. It's arguably not even the most important.
Personally, I feel that dynamic languages and static languages are both crucial tools in a developers toolbox. I'm not convinced that we have to choose to always use one or the other.
> > I wonder how much interest in Scala is generated by it > > being perceived as a hybrid JVM language with decent > > Java-like performance, compared to the more > > scripting-oriented languages like Groovy & JRuby. If so, > I > > wonder whether the new Groovy++ enhancements will bite > > into Scala's mindshare. > > Scala provides all the benefits of static typing while > eliminating a lot of the costs often associated with it > (redundant declarations, etc.) This is true, but is also true of Groovy++.
> While performance is a > benefit of static typing, it is not the only one. It's > arguably not even the most important. Agreed, and one of them is uptake by the existing Java community. I would be willing to bet that your average Java programmer will find switching to Groovy much easier than Scala.
> > Personally, I feel that dynamic languages and static > languages are both crucial tools in a developers toolbox. > I'm not convinced that we have to choose to always use > e one or the other.
I understand, but I was really interested in people's thoughts on the static typing in Groovy++ and its resulting performance improvements. AIUI, it matches Scala. So, if interest in Scala was coming from some who were only after a high-performance hybrid JVM language, might they not be tempted to switch to Groovy++ instead? I'm really just after the Scala fan's view on Groovy++ which, AFAICS, covers almost identical ground in terms of target audience/functionality/speed etc.
> > Scala provides all the benefits of static typing while > > eliminating a lot of the costs often associated with it > > (redundant declarations, etc.) > > This is true, but is also true of Groovy++.
Ah. Frankly I wasn't aware of it until you brought it up.
> > Scala provides all the benefits of static typing while > > eliminating a lot of the costs often associated with it > > (redundant declarations, etc.) > This is true, but is also true of Groovy++.
The one difference that I can see is that Groovy++ allows dynamic code to be mixed with static code. This could be seen as an advantage and I'm not sure exactly how I feel about it. There is a distinct downside to this, however. The big benefit of fully static code is that creates a kind of road-map of the application. This map is extremely useful for supporting an existing application. But this map depends on a chain of static calls. Any dynamic calls break the links and make it much harder to understand the application. Casts do the same to a somewhat lesser extent.
The big advantage I see of Scala is that it provides a lot of features that help the developer avoid using dynamic calls.
I understand the concern about Scala, I've had similar concerns myself. I think that there may be a place for both. Scala probably is a better fit for expert developers while Groovy++ might make more sense in organizations where development is not the primary focus. Unfortunately, I don't get to make these decisions, having lost my world dictator status in a recent coup ;) We'll have to see what the market decides.
> If so, I > wonder whether the new Groovy++ enhancements will bite > into Scala's mindshare.
If Scala 2.8 doesn't take off in a significant way, then it'll probably always remain a niche language for the JVM. Tooling support could improve its prospects, but I think that most management would consider it too much of a risk, too academic, too much of a moving target.
Groovy++ would be a much more natural fit for your average Java developer, but it's so new that it would be years before it would gain any traction.
It will take a big player to get behind one of these alternative languages before they ever take off.