Erlang: The coding language that finance forgot (2022) • Hacker News Board

Re: Erlang: The coding language that finance forgot (2022)

#151

Post by innocentoldguy » Sat, Feb 04, 2023, 12:42 PM UTC

freedomben wrote: post #109

innocentoldguy wrote: post #94

Earlier quoted context omitted.

The company I currently work for switched from Java to Elixir/Erlang because developer productivity was so much higher. Being able to turn around features and fixes in a fraction of the time has been quite valuable for us.

I would love to hear more about this if you're willing! Java shops (In my experience) have been the most unlikely to switch shops there are. Some questions: What pain were you feeling? Who came up with the idea/proposal to switch and how did they deliver it? Was it hard to get people on board? How difficult was it for people to learn Elixir? Did people take to it quickly and/or were there people who had a hard time?…

Hello, freedomben. I'm back from my business trip, so here are my answers to your questions, as promised.

> 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.

Re: Erlang: The coding language that finance forgot (2022)

#152

Post by 59nadir » Sun, Feb 05, 2023, 5:20 PM UTC

vineyardmike wrote: post #150

59nadir wrote: post #149

Earlier quoted context omitted.

I will put in a good word for PureScript for the beam with `purerl`. It's my go-to for writing BEAM code nowadays. Notably PureScript tooling including LSP, package management, etc., just works, so you are able to just get to work in internalizing the way OTP and other Erlangy things are expressed in a statically typed, pure language with much better facilities for functional code than any other BEAM language. https:…

What sort of things do you write with it? You don’t use it professionally do you?

I'm writing proof-of-concept applications in it for our company currently. Our core technology is Erlang (and Elixir), so the jump isn't comparatively as ridiculous as a Java shop suddenly writing PureScript on the BEAM. I trust code written in PureScript far more than I do code written in Elixir and there are already at least 2 companies using `purerl` in production with the majority of their code in PureScript.

With that said, I've been writing Elixir since 2015 and have worked with Erlang & Elixir since a couple of years after that (+ Haskell), so I'm both much more likely to use niche languages and I'm also well versed in using the BEAM. PureScript with `purerl` actually matches Erlang much better than Elixir does, since Elixir spends half the language and standard library trying to not be Erlang, so I find that it's a better match than Elixir even as a citizen of the BEAM, and the type safety is something I've wanted on the BEAM since I first wrote production BEAM code.

All in all I've been blown away by how solid `purerl` is. The runtime is Erlang, the language is excellent; it's what I dreamed about Haskell being but couldn't quite get.

Re: Erlang: The coding language that finance forgot (2022)

#153

Post by worthless-trash » Mon, Feb 06, 2023, 3:54 AM UTC

toast0 wrote: post #108

mrkeen wrote: post #21

Earlier quoted context omitted.

> swap in a new process Very technologically cool, but I'd much rather inject the new functionality into the source code. From there it can it make its way through the unit tests, integration tests, deployment, health/readiness checks, and if all that passes then I'll allow it to be called.

> Very technologically cool, but I'd much rather inject the new functionality into the source code. From there it can it make its way through the unit tests, integration tests, deployment, health/readiness checks, and if all that passes then I'll allow it to be called. 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…

There was that.. interview with a witch. I was a little enamoured by her.

https://aphyr.com/posts/341-hexing-the-technical-interview

Re: Erlang: The coding language that finance forgot (2022)

#154

Post by holsee » Tue, Feb 07, 2023, 11:33 AM UTC

weatherlight wrote: post #128

holsee wrote: post #68

Earlier quoted context omitted.

Sounds like a good old foldl may or may not have brightened up your day (with the "functional style" you mentioned) e.g. Pipeline = fun(Functions, Initial) -> lists:foldl( fun(Function, Acc) -> Function(Acc) end, Initial, Functions ), Initial = SomeFunc(), Pipeline = [Func0, Func1, Func2, Func3], Result = Pipeline(Pipeline, Initial). At a certain point I grew to not mind the punctuations `; , .` I often miss language…

seems more complicated than the following elixir code. Val |> SomeFunc() |> Func2() |> Func3()

I agree, or a nice `with` clause.

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

Re: Erlang: The coding language that finance forgot (2022)

#155

Post by eggy » Tue, Feb 14, 2023, 11:05 PM UTC

qohen wrote: post #135

eggy wrote: post #106

Earlier quoted context omitted.

The one big use case was RabbitMQ in a messaging app, not HFT. I doubt Elixir even with Nx can compete with low-level HFT code. Python DL/ML code libraries are just wrappers around C too. Maybe if BeamAsm and Nx are used Elixir could be used for more numerical or not just distributed applications. I've programmed in Python and Julia, and when I worked at an engineering (mechanical, entertainment engineering) company,…

Given your love for Lisp, and your knowledge of Erlang, perhaps Robert Virding's Lisp Flavored Erlang (LFE) might be of interest? http://lfe.io -- among other things, the site has tutorials and some edits of Lisp books (e.g. SICP) rewritten to use LFE. (And, from what I've heard, LFE is being used in financial apps, though perhaps more along the lines of expert-systems than regular financial apps? (Sadly, my knowledg…

I delved into LFE, and I was a proponent when Elixir was just catching on, but Elixir's momentum just washed it away. I believe Elixir earned it, but I think it had a heavy kickstart from all of the Ruby programmers who took to it. And they say syntax doesn't matter ;)

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!