Why and How we are using Scala at Journi

Last year we started building our web/mobile startup Journi, and I considered 3 different backend languages before finally settling on Scala:

  1. PHP. I didn’t want to continue working with a language that had grown into a monstrosity.
  2. C# .NET. Solid, stable language with functional programming features, but I wanted an open source solution instead, because I found Windows Servers less affordable and more difficult to automate than Linux Servers.
  3. Java. The JVM is as solid and fast as the .NET CLR, but Java was lagging 5-10 years behind C# in language features.

Enter Scala.

Scala_logoI had worked with Scala in 2010 and found it interesting, but at the time it seemed unusable for production. This had changed when I came across Play Framework 2 in 2013 and found that it was exactly what I needed.

I am not a language advocate, so don’t be surprised that I’m not trying to convince anyone to use Scala. But after 18 months of using Scala we found that:

  • Handling collections and options is very natural and readable, as control flow does not depend on exceptions and generally needs fewer tests.
  • Generally I found it easier to understand and write correct code that uses immutable variables and a functional programming style.
  • As the project grows bigger, we can more easily move forward with changes and refactor things. If the project compiles after a lot of renames, deletions, and so on, we have a lot of confidence that the code is still correct.
  • Scala’s Futures API makes it easy to interface with third party API endpoints while dealing with network timings and exceptions.
  • We use a lot of existing Java libraries. Very little work is needed to integrate with third-party services, because of the existing Java ecosystem.
  • Where performance is needed, you can easily get it. Sometimes, the most readable code does not perform as needed. There are a lot of monitoring tools for Scala out there. They can profile your app in production and give you detailed performance characteristics of your methods.

scala_pattern_match_memeThis outweighs the disadvantages:

  • In the beginning, newcomers from Java won’t immediately grasp how to use Options and other monads. Learning functional style of programming takes time, especially knowing when to use which paradigm.
  • You need a fast computer in order to have decent compile times. This is only a problem when checking out new code that has a lot of changes. While developing, the incremental compiler is quite fast.

Sometimes, because there are so many stable Java frameworks and new Scala frameworks, you spend more time evaluating which library to pick for basic things like database access. I’m pretty sure this will improve as the community matures.

I get asked quite often why we chose Scala in the backend, so this blog post serves as a reflection on this topic. Feel free to comment if you have more questions :-)

This entry was posted in Play framework, Scala, Startups. Bookmark the permalink.
  • Wr8rR

    Thanks. I’m thinking about deploying a web application and I’ve found journi the perfect example to follow because I had in mind to use Scala (as I’m learning it and it seems to me the right choice), but I don’t know anything about which database and framework to use. I appreciate your experienced posts, advices and reasons. They helped me to decide which one I will use.

    If you need any support in Journi for free, maybe I can help you. I’m looking forward to improve my abilities in Scala, I learn very fast and I’m eager to do things.
    You can get in touch with me through my mail jorgevc@fastmail.es
    Cheers,

    Jorge Vicente

    • //blog.papauschek.com/ Christian Papauschek

      Thank you for your kind words, always happy to hear the post is helpful :)