Imagine a bacon-wrapped Ferrari. Still not better than our free technical reports.
See all our reports

Scala: Sink or Swim? Part 2

Disclaimer: According to British scientists, the author is descended from apes.

In Part 1 of Scala: Sink or Swim? we looked at some things you should ignore in the Scala ecosystem when you are starting to adopt Scala. I think it was important getting that out of the way first — if you discover these things as you’re learning, thinking that’s idiomatic Scala, they might scare you off, and you would be missing out, in my opinion.

In this post we’ll look at some more things that are not quite perfect in Scala land, but that you must simply live with, at least for now. Finally, in Part 3 of this series, we’ll peek at some language features that form a simpler subset of Scala, but still make learning and using Scala worthwhile.

Things you must live with

Any language has some annoying warts — you just learn to live with them. I think it’s a good rule of thumb to avoid the things mentioned in the previous posts at least initially, and decide whether you want to use them after becoming comfortable with the language. Or maybe you already are on good terms with some of them — I’m not trying to change your mind about that. If not though, keep in mind that these things are also part of the Scala community in it’s diversity, and ignoring them completely might not work as well when you find that, for example, some of the Scala answers on StackOverflow or on the mailing lists are of the opposite mindset.

But you should totally be able to coexist with the “deep end” of Scala and still write good code that is not too foreign even to Java developers. There are many libraries in Java that I can’t stand or that are internally divided into so many layers of abstraction that they are extremely hard to debug or understand, but that doesn’t take away from the value of Java itself.

The same is true for Scala, but as a newer and less popular language than Java, there just isn’t a comparable number of libraries that are really solid.

Comparatively, Scala is still in the early days where Java would’ve had EJB 2 and Struts 1 as the pinnacle of web development. The language is still that young, but perhaps this comparison isn’t quite right — I don’t think Scala ever really had as big of a blunder as EJB 2, and web development with Scala is not necessarily behind or ahead of web development with Java.

But there’s still a lot of exploration and mapping of the territory going on. In the Java world, most people would not blame the Java language for EJB 2. They would just stay clear of that single part of it. But with Scala, some folks are quick to blame the language or the community and ecosystem as a whole for any particular misgivings.

And the Java world still hasn’t reached a consensus on the eternal question: which web framework to use? And it never will, because no single framework is particularly amazing, for one reason or another. Different variables weigh into that choice each time.

So, I’ve done my best to narrow down the main unavoidable issues into 4 areas:

  1. Binary Compatibility
  2. A good IDE is pretty much a requirement for understanding some code
  3. Compiler speed in conjunction with IDE use patterns can slow you down
  4. Scala is still evolving and getting new experimental features

1. Binary compatibility

This is perhaps the biggest issue with Scala. Libraries compiled with one version will not necessarily work with the next or previous versions, so they need to be recompiled with each version upgrade. SBT can do this (compile against multiple Scala versions), and I think that has been one of the main contributors to its relative popularity.

If some libraries don’t recompile, they will hold back users from moving to newer Scala versions, or alternatively force users to use source dependencies or even resort to forking. But things have been getting better even on the binary compatibility front.

2. Need an IDE to understand some code

Some would likely disagree, but I think you definitely need an IDE for developing Scala code, and maybe even more so for reading code written by others. It is not as easy as in Java to immediately see what a particular line of code does, due to more constructs being available (such as implicit conversions and type inference). An IDE that lets you jump to declarations and shows types when you hover over something with an inferred type is essential in understanding some Scala code.

Thankfully, the Scala IDE for Eclipse is quite good since version 2.0, and I hear the IDEA plug-in might be even better.

3. Compiler speed

This is the largest issue that remains with tooling IMHO — when you have a project with thousands of lines of code and use Build Automatically in Eclipse, you might end up in situations where changing a single line + saving will result in half a minute of waiting. Compiler speed is also something that is being worked on.

4. Scala is still evolving

New features will be added to next versions of the language, potentially including value classes (yay!), control structure syntax improvements and even compile time meta-programming. This can seem kind of scary, especially the last bit, which is also known as… oh man, I don’t even want to say that word (macros). In reality, that change will likely be optionally enabled and not exposed to most users.

Plus, there already are a many features in the language that you shouldn’t use without good cause, as mentioned earlier. Josh Suereth pointed out some more in a comment to a previous post, such as vals/vars in traits (due to issues with initialization order). I just hope that library authors are not too eager to jump at the chance of experimenting with every new feature where they could do without. Of course, that doesn’t go for everything — some libraries may really benefit from these language evolutions.

There is even a new proposal for disabling some language features by default, which generated a huge comment thread on the mailing list. Seems that many expert users think it is too much of an inconvenience to have to enable those features everywhere they need them. I don’t have a particularly strong opinion on the matter, but I’m not totally against the idea that some devices for shooting yourself in the foot should have safety locks.

As a bonus, the best comment from that thread:

Don’t worry. Loops will be optimized in 2.10.
Cheers
– Martin

This is about the for loops vs. while loops issue I mentioned briefly in the last post. It will be great to see this being improved finally.

Update: some more developments on the mailing list. It seems the main reason for the proposal is a longer term direction for Scala that has the potential to unify some of the hairier features of the type system into a simpler set of rules.

Conclusion

There are some issues everyone in the community must live with when they use Scala. In my opinion, it is not too much, considering the power you are getting from the language.

I previously alluded to a division in the community (and my earlier post probably didn’t help it). Some people with functional programming background seem condescending at times, and probably think that the OO guys don’t care enough about writing better code. Many potential Scala programmers with OO backgrounds care about creating large code bases that are maintainable by any able team member or new hire for years to come. And until the functional side has proven to the wider community that programs written in the functional and more abstract way are as maintainable, their voice will not be taken too seriously by the larger group.

It’ll be interesting to see whether the functional/theoretical and OO/pragmatic side can achieve a more symbiotic co-existence and further bridge the functional / OO gap, or whether the groups will diverge even more. In any case, I think it helps if you know about this division when you start with Scala. Get comfortable with the basic language features, and then decide whether you and/or your team wants to keep avoiding the other side, or start expanding your horizons further.

Keeping in mind that I’m more of OO background, I think what the Scala community needs most at the moment to make Scala an even better Java alternative is to bring in more pragmatic programmers who would write solid libraries that don’t overuse symbols, avoid some of the more complex type system features, maybe even stay more imperative than functional (while still preferring immutability), and don’t go overboard with the type safety.

It doesn’t mean the more pure/functional/type-theoretical/experimental/research side of Scala should go away — they should all be able to co-exist in some kind of symbiosis.

I think this has been happening and will continue.

Look for more in Part 3…

In Scala: Sink or Swim? Part 3, I finally get the all the great things about Scala, and why I even started playing around with this interesting language in the first place.

Thanks for tuning in! If you have any questions, post them in comments or drop an email to erkki@zeroturnaround.com. In the next and final part we’ll take a brief look at the Scala features that are probably the reasons Java programmers should learn Scala in the first place. These form a subset of the language that is actually relatively simple, but still quite powerful.

  • Erik

    Hi Erkki,

    Re #2: I don’t know what this does:

    Project.evaluateTask(/*args skipped*/)

    That, however, has nothing to do with Scala. The rest of it apparently returns an Array of URLs:

    .get.toEither.right.get.map(_.data.toURI.toURL).toArray

    What’s the problem exactly? Are you suggesting a Java equivalent would be more readable somehow? There’s no state here, so there’s nothing difficult to follow going on here; particularly nothing inherent to Scala. I don’t see the point in your example, other than possibly ‘you have to know what Either is before you can use it’.

  • Guest

    Another great overview, thanks. I know you’re trying to be neutral, but the overall feeling I get from your first two installments is that there is not enough positive to Scala to make the jump.

    Currently investigating Kotlin, which seems to offer most of the benefits of Scala with a lot less baggage.

  • Erkki Lindpere

    Good point, I was trying to add an example at the last minute and didn’t think it through. I’ll remove it.

  • Erkki Lindpere

    I agree that Kotlin seems to offer many of the same benefits. But I find it unlikely that languages that are so similar to Scala, and almost form a subset of it (sorry if I’m being unfair to Kotlin, I’ve not studied it thoroughly), will achieve the same kind of popularity.

    In my opinion, there is enough reason to make the jump to Scala (or at least give it a try), and the 3rd part will be more about that.

  • Erik

    You’d be doing yourself a great disservice as a programmer if you didn’t have a good look at what Scala is really about. I initially came to Scala looking for something that could do what Java could, but with less rough edges and with a few perks. Now, I understand how it’s fundamentally different in many important ways. If you’re not afraid to take another critical look at how you’ve been doing things, Scala can be a huge eye-opener. And if you have a CS degree, you can finally put all that Haskell knowledge that they used to pester you with to good use (if you want).

  • Erik

    You’re a scholar and a gentleman. ;)

    After reading the IDE bit again, I find myself wondering whether you’re suggesting that, by and large, Scala codebases are in greater need of an IDE than Java ones are? I don’t think I agree with that. Sure, things like finding implicit function application can be very helpful, but navigating your average Java codebase isn’t exactly a walk in the park now, is it? I’d argue that there’s much less code surface and much less ceremony and convoluted code structuring in Scala. Not that I’d want to do without my trusty IDEA to begin with — I love my ‘go to class/symbol’ and syntax and error highlighting — but as long we’re comparing Java and Scala…

  • Richard Wallace

    FWIW, there isn’t a single Java library worth using.

  • Erkki Lindpere

     Since you put it that way, INWA :)

  • Wow… “functional/theoretical and OO/pragmatic” – that is very faaaar stretched. Are you to imply that functional programming is not pragmatic? That Lisp, the language of first commercial Web product, is in any way less pragmatic or practical than Smalltalk? Or vice versa?

  • Erkki Lindpere

    Ok, that might have been a bit hyperbolic, and I’m not implying that. It’s just that to me the functional side of the Scala community seems enamoured with theoretical stuff and trying to push the language to its limits as opposed to just getting things done. This might be a perception issue on my side.

  • Nicholas Sterling

    “… inconvenience to have to enable those features everywhere they need them.”

    I’m sure you know this, but for the benefit of those just looking at Scala: you can enable particular features everywhere with a compiler switch, e.g. -language:implicitConversions. It’s trivial to add such switches to scalacOptions in your SBT build, making features considered “normal fare” by a project team immediately available to all modules with no import.