Erlang: The coding language that finance forgot (2022)

> What pain were you feeling?

The turn-around time for refactoring, adding new features, changing API endpoints, etc. was taking too long in Java.

> Who came up with the idea/proposal to switch and how did they deliver it?

The engineering team, staff engineers, and the VP of Engineering recognized the productivity issues and decided to experiment with other languages to see if a switch would result in quicker turn-around times.

First, we came up with a long list of objective metrics we could use to test various languages against each other.

Next, we made a list of languages we wanted to test (e.g., Java, Elixir, Go, Clojure, etc.).

Then, we defined a test program, including a REST API, that we would build to compare the languages.

Finally, we broke up into small teams, assigned each team a language to test, and spent about a week writing our test program in a variety of languages.

Once we were done, we had a retrospective and scored our experiences with each language we tested using the list of objective metrics we had created.

In the end, Elixir won.

> Was it hard to get people on board?

It wasn't hard to convince the team we should switch to Elixir. The team's own test data revealed that.

> How difficult was it for people to learn Elixir?

It wasn't too bad. Most of our engineers grasped it quickly. I think two factors made the switch successful:

1. Two of us already had professional Elixir experience and could mentor other team members.

2. The company purchased team licenses for the Pragmatic Studio's Elixir courses, which were invaluable.

> Did people take to it quickly and/or were there people who had a hard time?

Most of our engineers were able to pick up Elixir quickly. Some of the backend data engineers took longer though, just because they didn't have to work with it every day.

> How long did the transition take to complete?

We completed the rewrites of all our products in less than a year.

I hope this was useful. Let me know if you have any other questions.

It is my understanding LFE makes a lot of compromises as a list in trying to work nicely with the Erlang VM (BEAM). I really wish Gleam kept the more Haskelly/ML syntax instead of shooting for the popularity contest by becoming more Algol or C-like. Slim Whitman allegedly sold more records than the Beatles, but I would rather listen to the Beatles!

Erlang, actually; and they're still using it -- here's a paper-abstract[0] from Sept.2022 (and video of a talk[1]) about their open-source "EqWAlizer" tool[2] for statically-typing Erlang (as-is).

(EqWAlizer was discussed on an Erlang-related podcast[3], including its relationship to Dialyzer -- the original Erlang type-checking tool -- and it was briefly discussed on HN[4]).

[0] https://dl.acm.org/doi/10.1145/3546186.3552537

[1] https://www.youtube.com/watch?v=do9f2FKsKxM

[2] https://github.com/WhatsApp/eqwalizer

[3] https://www.beamrad.io/35

[4] https://news.ycombinator.com/item?id=32330284

https://dl.acm.org/doi/abs/10.1145/1238844.1238850 -- canonical link and has a video of the related talk (streamable and downloadable).

(Sadly, without ACM membership, the paper itself is paywalled; there are copies of it online though, e.g. https://www.labouseur.com/courses/erlang/history-of-erlang-a... ).

What do you mean by "symbolic significance for brackets?"

https://github.com/llaisdy/beam_languages

See you down the rabbit hole!

You can do that, but you won't get the new behavior on the existing connections, only for new connections. Some http servers will also curtail keep-alive requests while draining the old server processes, so you still get to pay the cost of reestablishing long lived connections, if your use case includes those.

Additionally: testing, performance profiling, and debugging are natively supported.

Recommend reading:

"Designing Elixir Systems with OTP: Write Highly Scalable, Self-Healing Software with Layers" ( James Edward Gray, II, Bruce A. Tate)

Swapping in a new process and injecting the new functionality into the source code are not mutually exclusive. You can do both!

Erlang programmers are not idiots who would swap in new processes live without writing the source code for it and testing it. They write the code, the unit tests, the integration tests, deployment, health/readiness checks, and if all that passes then the deployment tools take care of swapping in the new process with zero downtime.

Generally, you do make the changes in source code, compile it, do all your pre-flight checks, and then hotload it. Honestly, sometimes the pre-flight check is just 'does it compile', but that's philisophical; you can put whatever process in place you want. But from my experience, it's much nicer to upgrade in place than start new, move traffic, drain old (not always in exactly that order). Sometimes, it's not realistic to avoid starting new and moving traffic, but it's nice when you can.

Most people aren't patching the VM bytecode by hand (to my knowledge).

Yeah, but I specified "best features" and "important features", not "all features".

Maybe homoiconicity simply isn't that important to developers?

For example, I can guarantee you that, right now in todays development climate, there is no team anywhere that is going to allow code which has Lisp-like self-modifiying ASTs to pass code review[1].

So why would Javascript, C#, Java, etc developers bother to a) request those features, and b) implement those requests? They aren't going to use the feature anyway, no matter how powerful.

[1] Except those places who already use Lisp, because they presumably already understand it, and those teams are tiny.

No crazy enforced OOP with a gazillion classes and inheritance, no non-sense design patterns just because the language enforces you to use OOP for everything, an amazing type system, no null pointer exceptions, great compiler error messages and so on...

Of course there are problems, like any other language, but it is crazy how it as a systems programming language is so good at expressing domain logic.

Java has a much bigger ecosystem, but judging JUST by the language design, I'd pick Rust over Java without thinking twice.

Jose Valim goes on as to why he made that design decision from the following: https://groups.google.com/g/elixir-lang-talk/c/w83lKZs4YS8/m...

    I will post the same answer from before: I like the explicitness of pattern 
    matching. In Elixir, as soon as I see ^foo, I know I am matching. If there is 
    no ^, I know the previous value regardless if it there is one or not, will be 
    discarded. If pattern matching is not explicit, I always need to know if a 
    variable was previously defined or not to know what is going to happen. To me 
    this behaviour is non negotiable. In my experience, it is more likely to run 
    into accidental matches than into accidental rebindings.

    Another possible limitation to the suggestion above can be related to macros. 
    Let's suppose you have a macro that stores a value in a hygienic variable:

    defmacro do_something(a, b) do
      quote do
        var!(hello, Hygienic) = calculate_something(unquote(a), unquote(b))
      end
    end

    Someone may call this macro multiple times but we always care about the last 
    value 
    of hello. If we make a distinction in between being assigned once and then 
    multiple times, the macro simply won't work. Or the macro developer would need to 
    work around this behaviour by inspecting the environment or we would need to 
    provide some sort of functionality that does it for you. Maybe this behaviour 
    could be built-in in var! or maybe we'd need to introduce something like:

    defmacro do_something(a, b) do
      quote do
        set!(hello, Hygienic) = calculate_something(unquote(a), unquote(b))
      end
    end

    We can see how this is getting complex:

    1. Use = to define variables
    2. Use ^ for pattern matching
    3. Use := for rebinding
    4. Use set! in macros when you don't care if a variable was previously defined or not

    It is also interesting to point out that the := operator won't work for rebinding 
    inside clauses. For example, how would you make the rebinding below explicit?

    x = true
    case false do
      x -> :ok
    end

    Of course, there are interesting consequences for making a distinction in between 
    defining and rebinding a variable by introducing something like the := operator. 
    We could have better control of the scope to provide better warnings or even make 
    it easier to implement imperative for loops:

    x = 0

    for i <- 1..5 do
      x := x + i
    end

    x #=> 15

    But the fact Elixir have different ways for variables to be introduced in the 
    scope, adding more rules can make the overall system very complex.

When strict simplicity is not the ultimately goal dare I say leaning into the monads is the way...