The benefits of functional language enforcements in context of highly concurrent, scalable and maintenable software

Chat / Discussions
1

It seems that people are very fired when it comes to discussions about static typing, namely these 2 topics received a lot of interaction:

  1. Type system updates: moving from research into development
  2. https://elixirforum.com/t/discussion-on-the-benefits-of-static-typing/56874 (this is actually offtopic from the first thread, but don’t tell anyone)

One of the prominent conclusion was that enforcement of something (in that instance types) in a language is a good thing.

Now we can all agree that immutability is thing that makes concurrency and distribution a 100 times easier, as there are strong guarantees that data passed around will not be mutated, however this is not a feature, but subtraction of feature from the language just as types are enforcement to specify types for everything.

If we agree that enforcement is a great thing, as it brings a lot of guarantees to the table, how comes the usage of functional languages is not the norm? For example haskell not only enforces types, immutability but also there are no side effects in the language, all effects are managed, another enforcement that is very powerful and can bring guarantees to the table.

From my personal understanding, here a few things that stop adoption of functional languages at large scale:

  1. Steep learning/relearning of new base concepts and a new style of programming, this is especially true for people used to OOP and mutable code style, I found that new people coming to development find functional approach much more easier and natural to understand;
  2. The misconception that immutable languages are not efficient because they cannot mutate state, this great talk shows that this doesn’t have to be the case: "Outperforming Imperative with Pure Functional Languages" by Richard Feldman - YouTube;
  3. People thinking in designing software in terms of Classes/Objects and not data flow/transformation, witch has to be the biggest stopper, as people cannot leave the OOP behind.

I am sure that there are people here who worked in a pure functional language in production and can tell their findings/conclusion on this, because as much as we love elixir, it partially a functional language that cannot be classified as a full-fledged functional language.

PS: When we talk about performance, I would like to point that the comparisons are made in regard to high-level languages, languages like c/zig/rust are out of the question as they are targeted at low-level things.

2

Some of my thoughts and this is not exhaustive…

In some respects Erlang/Elixir is kind of object oriented when we consider processes. Processes as objects hide their state and respond to messages, they also run in a isolated execution context from other “objects as processes”.

The value proposition for me in Elixir/Erlang was scalability and fault tolerance using a concurrency model that didn’t expose threads, mutuxes, critical sections, semaphores or condition variables. It provided a paradigm that was free of race conditions with a sane approach to serialisable state management through process isolation and inter process messaging built into the core of the language.

Those things and supervision trees/process monitors with guaranteed notification all work together to provide distributed fault tolerance, scalability and mostly lock free execution within a single process/object context.

How many other languages were designed with these realisations?

When I consider OO systems you basically have a complex global mesh of object references and multiple threads of execution crawling all over it and mutating it in parallel. It is no wonder the number of possible edge cases is so much higher and the determinism and reliability of the resulting systems are so much lower.

Object state management in OO was never fully thought through from a concurrency perspective IMO.

Erlang did approach things differently with cheap isolated processes managing state, userland scheduling and process monitors which is why latency is very predictable and we get scalability and resilience with very little effort.

It is also not enough to bolt on immutability on a language where it is not enshrined from inception. The ecosystem is not able to support the developer being immutable everywhere because the standard libraries and community packages don’t fully adopt the paradigm.

When Jose came along and gave Erlang a modern fresh face he dramatically improved the usability and approachbility of the language IMO.

Elixir code can also be a thing of beauty with the functional Create |> Reduce |> Convert (CRC) pipeline paradigm which many other languages would have you writing the steps inside out.

In my view Elixir provides the sweet spot of what I care about from a expressibility, testability, scalability and reliability perspective. I can build solid systems without requiring lots of other tools and supporting components that I would need using other languages.

When I consider the full end to end costs of developing, maintaining and operating a robust service over time, Elixir is the most cost effective technology I have used.

The kind of developers I want on my team can pick it up quickly and appreciate the features that make it a killer solution once you’re live. Even if Elixir is not the most popular language, that is fine by me, the competitive advantage it offers is what actually matters.

3 Likes