The following is a somewhat opinionated style guide targeted at people primarily with Java background who want to benefit from using the mainstream (also known as Future-based) Scala stack and do so while optimizing their reward to effort ratio. This guide will be well suited for teams that need a reasonable set of simple guidelines to follow, especially at the beginning, until everyone develops good intuition for Scala.

When people talk about their experience with Scala, they often say that it is possible to use Scala as a better Java. And indeed, many companies, especially the ones that adopted Scala around 2008-2009, didn't want to give up the familiar tooling and simply integrated Scala into existing workflows based on Maven. At that time, calling Scala an improved version of Java was questionable but at least justifiable. However, it's no longer the case. For the most part, contemporary Scala shops don't use Maven as a build tool, don't use Spring as a DI container and rarely, if ever, resort to classical design patterns. What do they use then?

Most experts agree that monads are the killer feature of category theory. However, it seems that beginners still have hard time grasping this concept. So, I decided to write up a post explaining what's wrong with most monad tutorials and explore their usage in Scala.

Every once in a while, someone publishes an article comparing support for functional programming in Scala and in other more mainstream languages like Java or C#. These articles usually make some valid points, but quite often, they miss the big picture. I decided to write down my thoughts on the subject, so in this article, we will discuss how functional programming is supported in Java 8, Kotlin and Scala in comparison to Haskell.

Last time, while discussing the Scala ecosystem, I said that ScalaZ often provides great alternatives to the standard library classes. In this post, we will look at ScalaZ disjunctions, which offer an alternative to Either and Try.

The Scala ecosystem has been a topic of debates for years. Is it good or bad? Is it too small or too complicated? I think that the problem here stems from the fact that Scala as a programming language appeals to different categories of developers. Moreover, there is a common belief that Scala can be used either as "a better Java" or as "a Haskell for the JVM". In my opinion, this statement holds some truth, but it is a dangerous simplification which may lead to wrong conclusions.

About once a week, someone on the Scala subreddit asks for advice on how to learn Scala. The answers are usually varied, some people suggest starting with Runar's book, others with the Coursera course. In my experience, most newbies eventually succeed in grasping the language, but it doesn't mean they learn a new skill set in the most efficient way possible.

Recently, there's been an influx of low-quality blog posts about alleged Scala unpopularity. Usually these articles involve distorting the facts and manipulating the numbers and can be easily debunked. On the other hand, for an outsider or newbie even this kind of logic may look reasonable and believable. I decided to carry out my own analysis to collect all relevant data in one place.

In the previous part of this series, we added Scaldi to our sample application. This time we are going to start using a database access library called ScalikeJDBC.

The recent news about Typesafe renaming generated a lot of buzz on the Internet. Some comments were to the point, but many seemed irrelevant, so I decided to write down and share my own thoughts about it. As I'm not an insider, this is a purely speculative post, but it still interesting to know what other people think.

Scaldi is a lightweight dependency injection framework for Scala. In Play, it provides a more Scala-like approach to injecting dependencies than the out of the box solution based on Google Guice.