Nearly a year-and-a-half ago, Boundless Learning made the decision to use Scala as our backend language for three reasons:
Functional Programming & Static Typing
To some programmers, valuing type-systems and functional-style feels like religion, so while this point deserves a few blog posts of its own, I’ll share a few high-level thoughts:
Functional programming aligns nicely with unit-testing, debugging, concurrency, complex algorithms, etc. (Great overview here). Further, mutable state in code leads to having to hold more meta-state in your brain as a programmer, which is yet another opportunity for bugs beyond the difficulty of just communicating your intent in the first place. Scala takes a highly reasonable approach to immutability: the predominant design and style of both the language and its core libraries leverages immutable data-structures and patterns, but when ‘forced’ (by complexity or schedule) a Scala programmer can easily use mutable structures instead (although, in our experience, we have yet to do this more than once).
Type-systems have been vilified, in large part because they can make code unreadable & force people to ‘think’. On the first point I agree, there’s a lot of ceremony involved in appeasing most type-checkers (List<> this, HashMap<> that). However, this isn’t the fault of static-typing, this is the fault of lazy or sloppy language design. Scala provides partial type-inference which reduces the amount of ‘ceremony’ to just function argument types, which is a fantastic place to leave type-based documentation (For those of you familiar with ML, having NO type information can be painfully disorienting). Even with type-ceremony removed from most places in the code, some programmers have a hatred of type-checkers, “I know what I’m doing, just let me do it!” they cry. I find this ironic; as programmers we build tools to make us more efficient. If the type checker throws you an error, you have an error in your logic, which means you haven’t clarified your intent properly. This is immensely useful. Those who think they know better than the compiler are doomed to long debugging session & mindless unit test writing. Excessive unit tests hurt agility, they create immense amounts of ‘refactor-drag’. A strong type system is the ultimate in frictionless first-line-of-defense testing.
The Java Ecosystem
Java has been around 16 years now. It has powered the biggest enterprise systems for over a decade, battle-hardening the libraries, the JVM itself, and creating one of the most robust library ecosystems in software. Since Scala compiles to the JVM, and interops cleanly with Java, Scala deployments have access to over a decades worth of platform, tooling, and support investment. That’s an awfully tall set of shoulders to stand on. If there were any risk in choosing Scala, we knew we’d have a more than reasonable fall-back, and when Scala delivered, we had an immense amount of leverage relative to other cutting-edge language choices.
The Hiring Paradox
The best programmers are the curious ones, the ones that continually learn, evolve and experiment. This type of A-player is naturally drawn to seek out new challenges, and push themselves outside of their comfort zone, and grow in the craft. 8 years ago, these folks started experimenting with Ruby, 5 years ago it was Python, 2 years ago Node.js, and now is the time of Scala. Our choice of Scala has given us the opportunity to speak at meetups, unearth extremely smart & talented programmers who are attracted not just to our mission to revolutionize education, but also to the forward-looking tech-stack we’ve chosen to do it with.
All in all, our experience with Scala has been very rewarding. We’ve built some wonderful systems, contributed to existing open-source Scala projects, and will be releasing our own unique contributions in the weeks to follow.
In our next post, we’ll cover how we help on-board new developers into the Scala language.