Some days ago, I had the privilege of attending the Functional Scala 2023 conference (London) in person, together with some of my colleagues from Hivemind.

Being a Scala enthusiast for almost a decade now, I enjoyed the conference talks very much, trying to learn all about the new features, libraries, frameworks and the most advanced techniques of the language. I had the chance to meet, listen and interact with well-known people from the Scala world and also attend the John De Goes training on advanced Scala. For me, it was like a dream come true.

All talks had a unique focus and the variety of the subjects selected for the conference were very vast but, in this particular article, I will comment on some of the talks that helped to acquire some unique views and a deeper understanding on some of the concepts of the Scala language and, more generally, of the functional programming community.

The Hivemind talks about LLMs (by Erik Schmiegelow) and about Apache Flink (by Vitor Leal) have their own articles, so I will select the following talks for commenting briefly on them:

• “A Year With Scala-CLI As Our Build-Tool” by Alexis Hernández

• “The Ubiquity Of Functional Programming Concepts In Latest Tech” by Afsal Thaj

• “What Scala Can Learn from Rust” by John De Goes

A Year With Scala-CLI As Our Build-Tool by Alexis Hernández

I had the chance to meet and talk with Alexis in person before the talk, and he told me about his company Wiringbits (https://wiringbits.net/) in Mexico, which specialises in Scala technologies.

I have had contact with Alexis previously on the Internet, where he sent me important information about Scala benchmarks, interesting tools and repositories to explore.

During this talk, Alexis asked the audience “How many of you have Scala pipelines that take more than 15 or 20 minutes to finish?”, and a good part of the audience raised their hand. After that he asked: “How many of you use Scala CLI?”, and only a few raised their hands.

Scala CLI is a command line interface program created by Virtus Lab, but as they disclaimed in their website “we do not call Scala CLI a build tool”. They say that there are other build tools like Maven, Gradle, SBT and such, and that the Scala CLI “doesn't aim at supporting multi-module projects”.

However, Alexis told the audience about the experience of migrating a lot of Scala projects into using Scala CLI as their build tool, and improving the building and deploying time of their pipelines from around 20 minutes to almost 2 or 3, or even 1 minute to finish.

Alexis’ presentation slides can be found in this Google Doc, where there is a reference to a sample multi-module project built with Scala CLI. A related Alexis’ article can be found here, and the sample project is here, in case you want to skip the slides.

I have made myself a local test and the project works fine, showing a good template for starting new projects or migrating existing projects into using this technology.

Although created for “simple projects” Scala CLI really deserves a try if it improves compilation times so much!

Alexis also commented on other options of the Scala CLI, like for example to generate Docker containers from Scala projects and compile to standalone applications. He also mentioned one of the Wiringbits products where they successfully use Scala CLI, codepreview.io

.

The Ubiquity Of Functional Programming Concepts In Latest Tech by Afsal Thaj

One of my favourite talks of the conference was definitely this one, by Afsal Thaj, one of the contributors of Golem at Ziverge Inc.

In this talk, Afsal showed first an example of how a simple programming bug could finish in a spaceship crash.

Afsal showed examples of known problems and explained why we should go back again on the basics, the fundamentals, concentrating on basic building blocks in programming languages, such as using functions and function composition.

For example, for 3 different problems implemented using for loops, after abstracting and understanding the process, we could solve it very simply using functional programming concepts, like the function “sequence”, present in many frameworks and libraries for different types:

def sequence[A](input: List[F[A]]): F[List[A]]

The concept of sequence, for me, was very hard to acquire for the first time, but after you practise and use it in real projects, it is a very simple concept to understand: given a list of effects, after applying the function, you obtain only one effect, with the list inside. For example, if the type constructor “F” (the effect) is bound to the type constructor “Option”, and the type “A” is bound to the type “Int”:

val maybeList: Option[List[Int]] = sequence(List(None, Some(1), None, Some(3), Some(4)))

Where we could expect the result of being something like:

maybeList = Some(List(1,3,4))

The same pattern applies for other types and effects, but the benefit of using this function “sequence” is that it gives you power of abstraction, and you reuse code written for library authors, giving you confidence that the code is indeed correct.

After this introduction, Afsal showed other examples of functional programming concepts in frameworks like React, where all is based on pure functions and combining or composing components to obtain more complex components. React is maybe the most popular frontend framework. React also adopted Typescript, another example of a language that implemented many FP concepts, like strong types, effect systems, generics, and higher-order functions among others. 

Afsal went again in showing more examples of FP concepts in the Rust programming language, Java, Python, Google AI JAX library, and Web Assembly.

Java 21 has recently adopted many FP concepts like pattern matching, immutable data structures, etc., but the Scala community has 10 years of experience using these Java 21 features.

The talk was very interesting and inspiring, and invited me to think on the benefits of focusing on the important concepts and processes involved in the FP paradigm, that are present everywhere in modern technologies, as presented here. 

Not only for Scala devs, but also if you are a Java, Python, Rust or React / Typescript programmer, you will find value in learning FP concepts and techniques in your career.

What Scala Can Learn from Rust by John De Goes

In this talk, John clearly explains the popularity and increasing adoption of Rust, going through its weaknesses and strengths. In any of these cases, the Scala community has lessons to learn, if they want to succeed in the business world.

Among the weaknesses, Rust has the following:

Macros:

Rust: Very bad model for AST and macro language API,

Scala has 4 different ways of expressing the same: inlines, quotes, mirrors, reflection

Asynchronous computations

Rust: Very limited “await / async “ syntax

Scala: Has numerous ways of dealing with Async computations: Futures, ZIO & Cats fibres, for comprehensions, scala async, Loom, etc.

Build files:

Rust: Very simple and limited, but good for tooling

Scala: More powerful, but at the same time tooling is not so good

Among the strengths of Rust:

More opinionated

Balance between mathematical based and the pragmatic solutions

Compiler errors: A whole team dedicated to have very clear and helpful compiler errors

Build tool: cargo is a joy to use, not a pain, is very friendly

IDE: The JetBrains IDE, Rust Rover is very stable and rock solid, opposed to IntelliJ IDEA Scala Plugin or Metals, that are not so stable

Multiplatform: The Rust compiler is multiplatform. The Scala native library is not part of the compiler

Interop compatibility: Different decisions with respect to Rust / C vs. Scala / JVM compatibility. In Rust you have to be explicit if you want to interop with C

Stability: Rust has 105 versions, and all of them are backward compatible for 8 years since 2015. This helps the investors, library authors, and adopters (like Facebook, Twitter X, Google and Microsoft) to trust in the platform and the tooling to improve over the years. Also, the videos and educational material stay relevant.

Winning value proposition: Rust is very clear in its goals, it is meant to be highly performant and memory safe (also have stability and great tooling). Scala does not have a clear North, which makes people with different interests to go in different directions and change the language very often. Also the tooling is not so stable.

This is basically the contents and conclusions of this interesting closing keynote of the conference by John, and it shows clearly that the Scala community needs to learn some lessons from Rust language and tooling. From Rust weaknesses, Scala can learn some pragmatism and being a more opinionated language. From its strengths, Scala can learn to be a more industry focused and commercial viable language.

My personal conclusion to this talk is that we are part of the Scala community, and our feedback and opinions matter, and we should learn how to attract people from other communities, being inclusive and welcoming to newcomers. We must evolve the language and improve tooling, mimicking successful features and strengths of other languages like Rust, that have clear goals set and a winning value for adoption.

Acknowledgements

I would like to thank Hivemind Technologies

again, for making my participation in the conference possible and to Ziverge

for the great conference organisation.