12 ms·

Erlang: The coding language that finance forgot (2022)

182 points by mindcrime 4y ago

qsort 4y ago
Who exactly claims Erlang is dead? The referenced article is SEO-infected garbage that also claims Haskell and Perl are dead.
- okaleniuk 4y ago
  Well, it's 21 century, nothing dies anymore but people. But you have to admit that it's not booming the way it deserves. I wrote in Erlang a decade ago and I thought that in ten years, surely, it will eat the world. Erlang got too many things right. However, as people from other domains started employing its principles, Erlang's value diminished. E. g., if we now write supervisors in Python that run servers, event handlers and FSMs written in C++, and the system works fine, we don't really need Erlang.
  - worthless-trash 4y ago
    Then you need 4 languages and each of them has slightly broken interactions. Hell is the code we write.
- Lio 4y ago
  It's only a word but the very fact the article refers to Erlang as a "coding language" and not a "programming language" is enough to give it a cheap, amateurish feel from the start IMHO. I'd just ignore it as low quality click bait if I were you.
  - rob74 4y ago
    That sounded odd to me too, but not being a native speaker, I was asking myself "is that how they call a programming language nowadays if they want to sound cool?". Guess not...
  - freedomben 4y ago
    It may indicate that it was written by someone who is relatively young. The teenagers I know (including my own) all say "coding", never say "programming". I suspect the latter sounds "old" to them. Since the young tend to be amateurs, I whole heartedly agree that it sounds amateurish. It probably is, and we're probably getting old.
    - topaz0 4y ago
      "coding", sure -- I say that all the time too. But "coding language" is something I have never heard.
- ivanhoe 4y ago
  Erlang and Haskell were never really the mainstream so not much changed for them, but Perl was "the language" at one point in time. It was everywhere, and now it's basically in the same box as Cobol - people who use it are 99% maintaining some old script. Very few young people choose to learn it nowadays, and the development got super slow due to the lack of developers. Perl 7 sounded great on paper, but I doubt it will get released anytime soon. So if not dead yet, Perl is definitely dying a slow death...
  - hestefisk 4y ago
    use Perl;
- deleted 4y ago
  [deleted]
okaleniuk 4y ago
Erlang is designed to accommodate principles for building reliable systems in the presence of software errors, and in such capacity it is definitely a worthy instrument. It is one of the few concurrency oriented programming languages in the world. But as Joe Armstrong himself pointed out in his dissertation: "indeed concurrent programs can be written in languages which are not themselves concurrent". You can write concurrent programs in Python if you want. Or even shell. As soon as you can spawn a process and send it a message - you're good. And this explains why Erlang hasn't conquered the world. As soon as it has established the principles, as soon as it proved them feasible in practice, it has made itself redundant. The lessons we learned from Erlang were larger than Erlang itself.
- bsder 4y ago
  I strongly disagree that we learned much of anything. For example: hot upgrading. The fact that an Erlang process can tail call itself means that you can swap in a new process with the same signature at the tail call of the old process. Nobody else does this that I know of. I can go on further. The whole set of behaviors encoded by the OTP libraries is also something that nobody else seems to do. Erlang's bit syntax is possibly the best out there even today. I guess pattern matching finally made it to other languages. I would think that's probably about it from Erlang (pattern matching isn't exclusive to Erlang but it was one of the earlier languages with it). None of the other programming languages seem to have learned much of anything from Erlang--and that's kind of sad.
  - saurik 4y ago
    Erlang was originally either implemented in Prolog or was even a library / extension for Prolog, and its pattern matching functionality is just "because it was all Prolog and the developers were using Prolog", so it isn't really fair to give Erlang any credit at all for that as it wasn't even independently designed.
  - medo-bear 4y ago
    > For example: hot upgrading. The fact that an Erlang process can tail call itself means that you can swap in a new process with the same signature at the tail call of the old process. Nobody else does this that I know of common lisp is in a league of its own when it comes to hot reloading and debugging
not_me_ever 4y ago
We didn't forget it. We burned it with fire, and then buried it. Most of us still of nightmares of it. Some didn't survive. :(
- sunshinerag 4y ago
  Care to share one of the nightmare
anonyfox 4y ago
I really love Elixir (and somewhat Erlang) and all the mental models and how developing in the ecosystem feels like, especially with phoenix/liveview. Having said that, nowadays anything that can't really run on AWS Lambda is a nonstarter in any company tech discussions, no matter how cool/productive it is. The operational benefits of serverless are simply too great especially when trying to scale up.
- dgb23 4y ago
  I don’t quite understand this. Doesn’t the BEAM runtime also have operational benefits over “lambdas”? Also not every application or component thereof wants stateless servers? What about live collaboration, game servers or just generally holding stuff in memory for perf reasons.
  - mikl 4y ago
    Yeah, one could easily argue the opposite: The excellent scaling characteristics of the BEAM means that there’s no need to use extreme performance compromises like AWS Lambda. You can scale an Erlang or Elixir application extremely far by just giving it more compute resources.
- dmpk2k 4y ago
  You are vastly overestimating the importance of AWS Lambda, even in web tech circles.
- MrBuddyCasino 4y ago
  This has it backwards - lambda is only suitable for the cloud equivalent of shell scripts, anything more complex and it becomes an unmaintainable rats nest that cannot be debugged.
  - bongobingo1 4y ago
    Just hook up Amazon™®© X™®©-Ray™®© into Amazon™®© Redshift™®© then use Amazon™®© Athena™®©! Simple!
Joel_Mckay 4y ago
Erlang/Elixir + OTP is unique, and for those that don't understand the use-cases its a mystery why. The article is an obvious troll, as popularity is not an indication of utility. =)
mikl 4y ago
The reason Erlang (and Elixir) are interesting are not the languages themselves (although Elixir is a very nice language in my opinion), but the runtime behind them, BEAM. The BEAM is the brainchild of the excellent engineers at Ericsson, the product of decades of R&D into building performant, scalable and reliable software for their telephony products. It scales like a dream, runs your application on all available cores with no trouble at all, handles massive amounts of concurrent requests without breaking a sweat. The programming techniques it enables with projects like Phoenix LiveView are unique and powerful.
- gjvc 4y ago
  Does "BEAM" mean anything / is an acronym?
  - glenngillen 4y ago
    Originally “Bogdan's Erlang Abstract Machine”, but then the subsequent maintainer was named Björn so you could sub that in too.
    - sodapopcan 4y ago
      And the predecessor to BEAM was JAM (Joe’s) which is a bit of a shame we didn’t end up with that acronym… or not, I guess.
    - frou_dh 4y ago
      IIRC Joe Armstrong said he was puzzled why people latched on to the term "BEAM" so much, and he preferred that it was simply referred to as the Erlang VM.
      - andsoitis 4y ago
        Beam, with one syllable, is more convenient to say out loud than Erlang VM. It also sounds cooler.
        4y ago
MattPalmer1086 4y ago
Well, I can't speak for all finance firms, but ours uses Erlang. Admittedly it's not used a lot, and Java and C++ are more widely used these days.
- jjallen 4y ago
  Do you think Rust will replace these over time? What are the blockers for this? Is Rust perceived as a "better" language by those in your profession but of cours e you can't rewrite everything every 5-10 years? Would finance apps be written in Rust today if all of the C++/Java applications weren't already written?
  - vitorsr 4y ago
    I cannot name a single high-quality scientific computing and numerical algorithms Rust library that is not a thin layer over established C and C++ libraries.
  - brettdong 4y ago
    I haven’t heard any major stock and derivatives exchange providing connectivity SDK or documentation in Rust but there is always plenty of them in C/C++.
    - jjallen 4y ago
      This is true. Though I see some market data providers offering Go ones.
  - antonvs 4y ago
    I’m a big fan of Rust, and am currently working on a major Rust project, but I don’t think it’s currently a viable replacement for most Java apps, nor is it really intended to be. If anything Go is closer to fitting that bill, if only because of its traditional garbage collection. Applications written in Java by definition aren’t too concerned with memory management, and Rust is objectively a step backwards for them. Rust is a more credible replacement for C++, but there I think it will be fighting inertia. Many C++ devs are actively against changing languages. I’ve also seen people “writing C++ in Rust”, using unsafe everywhere so they don’t have to figure out how to design their code to fit Rust’s model. You then end up with a kind of worst of both worlds.
haspok 4y ago
Maybe the title would have been better like this: "PROLOG: The coding language that finance forgot." Erlang (the language) is rooted in Prolog, and many of its best traits can be traced back to this fact. That everything is a pattern, and you can pattern match pretty much anything is rarely found in other languages, for example. Elixir made a mistake in my opinion when it went with a Ruby-like syntax. Also, there are those kinds of problems where in Prolog you can express and solve them in a few lines, in other languages you struggle a lot (and at the end you just reimplement half of the backtracing engine anyway - see Greenspun's tenth rule). Why it is not more commonly used in banking / finance is one of the greatest mysteries of life.
- codesnik 4y ago
  backtracking isn't hard to implement, though. Depth-first search is more or less what it is. But erlang lost most of the prolog ancestry, backtracking isn't there, for example. BEAM has a lot of concurrency neatness though, hard to reimplement or even mimic in languages not specifically tailored for from ground up.
- brightball 4y ago
  Elixirs syntax is only Ruby like in that it’s very readable IMO. Any similarity with Ruby stops there.
  - adenozine 4y ago
    Well sure but you could be more clear. Block parameters, implicit parentheses for certain method/function calls, uppercase significance, symbolic significance for brackets.
    - amalgamated_inc 4y ago
      Elixir doesn't have blocks as a separate concept like Ruby. The "blocks" are just syntax sugar for passing keyword lists of code to macros. What do you mean by "symbolic significance for brackets?"
loftsy 4y ago
I've written some Erlang and found the syntax awkward. One example of this is that variables can only be bound once. This means you end up writing: Val = SomeFunc() Val1 = Func2(Val) Val2 = Func3(Val1) Yes I know you can use the functional style to minimise having to do this but you still end up seeing this pattern in real code. Kubernetes has done a good job of replacing OTP. That said I think Erlang is still an interesting language to learn just because of how different it is.
- codesnik 4y ago
  I personally don't find this binding once behaviour problematic in any way, but Elixir specifically addresses this (it creates another variable with the same name, though)
  - holsee 4y ago
    I wish they didn't tbh, it makes me sad. Not allowing rebinding does provide a little bit of encouragement towards factoring things better, but I have seen manys a `X1` `X2` in my time :(
    - weatherlight 4y ago
      its a bit of a smell, but good elixir code doesn't have to worry about rebinding for bindings in the same scope. 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/rFeb3Env-6YJ 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.
oleks 4y ago
What does finance have to do with distributed systems? Finance is much more about mathematical modelling, which is an utter pain in a dynamically typed language with nothing but library support for state management.
- capableweb 4y ago
  Downtime is death, and performance is important. Distributed systems usually can help you avoid some of the types of downtime, and can help you manage throughput, although straight up latency tends to be become slightly worse.
- eminent101 4y ago
  Finance companies were doing distributed systems even before Internet existed. Yes, finance has a lot of numerical work but it has a lot more data pipeline work. The reason for this is to move market data from one geographical location to another. To make profitable investments, finance companies need accurate market data from all over the world available and processed at its datacenters as quickly as possible. For this reason in the early 1980s finance companies were laying down their own cables and writing their own link layer protocols to move data from one location to another. Now in the 21st century this has only got more intense. There is much more competition in this space. So finance companies that can make distributed systems right and reliable stand a good chance to the most money from the markets.
- mardifoufs 4y ago
  Finance is a huge field. I'd say the need for mathematical modelling, in one form or another, is pretty universal no matter what you do in Finance. But there are also tons of other stuff you might need on top of that depending on what specific field of finance you work in. Distributed systems can provide the data that your model relies on, or even the platform where the model itself needs to run on.
danielam 4y ago
For completeness, TD Securities is/was using Erlang for an in-house GED trading platform.
- qohen 4y ago
  To save others the Googling: GED == Global Equity Derivatives.
4pkjai 4y ago
I wonder if rust will end up as a coding language finance forgets.
aynyc 4y ago
Erlang isn't dying but not many people care for it in capital market. Looks at the traits of Erlang, it's designed for telecom environment which is almost opposite of capital market. 1. Fault tolerance is almost all hardware driven. Capital market participants spent billions of dollar building reliable private networks. 2. Distributed in trading doesn't mean what FAANG are doing. Trading systems for example usually run 2 hot-warm systems with real-time replication commits, that's about it. They don't run horizontally scaled systems because network time would kill their performance. In my experience, I haven't heard anyone asking for hot swap code and high availability (outside of trading hours). Are there shops out there that run Erlang? Sure, but most companies don't care about Erlang simply because its value isn't better than Java/C/C++.
- jonhohle 4y ago
  Funny anecdote about one of the FAANGs: before the idea of service meshes and Consul and Envoy a similar idea was being rolled out to transparently proxy, encrypt, and authenticate traffic between services. The initial implementation was on erlang and didn’t cause any operational issues for our team, from what I remember. The project was moved to another team who decided for version 2 to rewrite in Java (high made sense from an integration perspective). Unfortunately, they hadn’t tested at scale along with whatever it was servicing and as it was being rolled out it quickly ballooned in memory causing systems to swap and fall over. They eventually got it working, but the rollout was less than ideal and unfortunately an erlang project that affected a significant amount of traffic without notice was deprecated.
  - weatherlight 4y ago
    Everyone always talks/jokes about, "Rewrite it in Rust," think about all the business applications over the years that had been rewritten to Java, just because. Usually under the guise of, "Kids coming out of college will have an easier time wrapping their heads around Java," than some other lang. In my time as an engineer, I've seen quite a few Scala and Clojure apps, get rewritten in this manner. This is all antidotal, of course.
    - 4y ago
college_physics 4y ago
Finance means different things to different people. Are we talking about trading "finance" (including high frequency trading), investment banking "spreadsheet" finance, consumer or corporate "database" finance or maybe even (the horror, the horror) "defi" cryptofinance? What is true is that finance in almost all its guises is a world apart in terms of information technology. Closed and proprietary, ultra expensive and arcane, highly regulated etc., it is an information technology branch that evolved separately and it shows. Whether that will remain so is an interesting question. So called "fintech" has been a thing for a while. E.g. whatsapp is famously built on erlang, so if Meta wants to turn it into a super-app (the "Asian way") you will have a de-facto application in "consumer" mobile/payments finance.
- djtango 4y ago
  Wasn't WeChat built in Erlang as well?
  - jjtheblunt 4y ago
    I think WhatsApp was Elixir
    - qohen 4y ago
      I think WhatsApp was Elixir 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 https://dl.acm.org/doi/10.1145/3546186.3552537 [1] https://www.youtube.com/watch?v=do9f2FKsKxM https://www.youtube.com/watch?v=do9f2FKsKxM [2] https://github.com/WhatsApp/eqwalizer https://github.com/WhatsApp/eqwalizer [3] https://www.beamrad.io/35 https://www.beamrad.io/35 [4] https://news.ycombinator.com/item?id=32330284 https://news.ycombinator.com/item?id=32330284
      - 4y ago
innocentoldguy 4y ago
I've worked for two fintech companies (Divvy and Mastercard) that use Elixir. It is excellent language to solve finance-related problems due to its ability to supervise code and recover from unexpected issues.
djtango 4y ago
I heard on the grapevine once that Goldman Sachs have a proprietary distributed database built in Erlang. Can neither substantiate nor deny but did make me wonder about all the hidden proprietary tech out in the world...
- jelkand 4y ago
  Most of the hidden proprietary tech at Goldman Sachs was built in the early 90s, so a bit less sexy than Erlang. Impressive in its own right though.
- Terretta 4y ago
  > heard on the grapevine once that Goldman Sachs have a proprietary distributed database built in Erlang From the article, third paragraph: Goldman Sachs built its messaging system using RabbitMQ, which runs on Erlang, in 2018. Jonathan Skrzypek (who now works for Coinbase) was running the messaging engineering team at Goldman at the time. The system had to be fault-free because the messages it was transmitting could "worth a couple million dollars," said Skrzypek. RabbitMQ was chosen because of its resilience and "reliable delivery, guaranteed delivery."
  - qohen 4y ago
    A comment to the posted-article, from "Frellus", who identifies as ex-Goldman, suggests RabbitMQ might not have been used so extensively: Ex-Goldman person here. To the best of my knowledge, RabbitMQ was used in spots but not where reliability was critical. Instead the main message brokers were IBM MQ and TIBCO. RabbitMQ would certainly lose messages in the event of a crash, and I'm not sure it would have been used for the main message bus given the rate of events. Additionally, Erlang was used for SecDB queries quite heavily. This was the bread-and-butter of the firm (https://github.com/saleyn/secdb https://github.com/saleyn/secdb)
    - djtango 4y ago
      SecDB fits the bill a little better for what I had heard of. Thanks
jamal-kumar 4y ago
The real eureka moment for me getting why erlang and elixir are game changing was realizing how easy it is to build distributed applications using them, especially in Elixir the facility of this is just incredible. The OTP (Open Telecom Platform) as it's called is probably its coolest feature in my eyes. https://elixir-lang.org/getting-started/mix-otp/introduction-to-mix.html https://elixir-lang.org/getting-started/mix-otp/introduction...
dgb23 4y ago
Nubank aqui-hired the people who make Elixir? So it's not quite forgotten.

182 points by mindcrime 4y ago

Who exactly claims Erlang is dead? The referenced article is SEO-infected garbage that also claims Haskell and Perl are dead.

okaleniuk 4y ago
Well, it's 21 century, nothing dies anymore but people. But you have to admit that it's not booming the way it deserves. I wrote in Erlang a decade ago and I thought that in ten years, surely, it will eat the world. Erlang got too many things right. However, as people from other domains started employing its principles, Erlang's value diminished. E. g., if we now write supervisors in Python that run servers, event handlers and FSMs written in C++, and the system works fine, we don't really need Erlang.
- worthless-trash 4y ago
  Then you need 4 languages and each of them has slightly broken interactions. Hell is the code we write.
Lio 4y ago
It's only a word but the very fact the article refers to Erlang as a "coding language" and not a "programming language" is enough to give it a cheap, amateurish feel from the start IMHO. I'd just ignore it as low quality click bait if I were you.
- rob74 4y ago
  That sounded odd to me too, but not being a native speaker, I was asking myself "is that how they call a programming language nowadays if they want to sound cool?". Guess not...
- freedomben 4y ago
  It may indicate that it was written by someone who is relatively young. The teenagers I know (including my own) all say "coding", never say "programming". I suspect the latter sounds "old" to them. Since the young tend to be amateurs, I whole heartedly agree that it sounds amateurish. It probably is, and we're probably getting old.
  - topaz0 4y ago
    "coding", sure -- I say that all the time too. But "coding language" is something I have never heard.
ivanhoe 4y ago
Erlang and Haskell were never really the mainstream so not much changed for them, but Perl was "the language" at one point in time. It was everywhere, and now it's basically in the same box as Cobol - people who use it are 99% maintaining some old script. Very few young people choose to learn it nowadays, and the development got super slow due to the lack of developers. Perl 7 sounded great on paper, but I doubt it will get released anytime soon. So if not dead yet, Perl is definitely dying a slow death...
- hestefisk 4y ago
  use Perl;
deleted 4y ago
[deleted]

okaleniuk 4y ago

Erlang is designed to accommodate principles for building reliable systems in the presence of software errors, and in such capacity it is definitely a worthy instrument. It is one of the few concurrency oriented programming languages in the world. But as Joe Armstrong himself pointed out in his dissertation: "indeed concurrent programs can be written in languages which are not themselves concurrent". You can write concurrent programs in Python if you want. Or even shell. As soon as you can spawn a process and send it a message - you're good. And this explains why Erlang hasn't conquered the world. As soon as it has established the principles, as soon as it proved them feasible in practice, it has made itself redundant. The lessons we learned from Erlang were larger than Erlang itself.

bsder 4y ago
I strongly disagree that we learned much of anything. For example: hot upgrading. The fact that an Erlang process can tail call itself means that you can swap in a new process with the same signature at the tail call of the old process. Nobody else does this that I know of. I can go on further. The whole set of behaviors encoded by the OTP libraries is also something that nobody else seems to do. Erlang's bit syntax is possibly the best out there even today. I guess pattern matching finally made it to other languages. I would think that's probably about it from Erlang (pattern matching isn't exclusive to Erlang but it was one of the earlier languages with it). None of the other programming languages seem to have learned much of anything from Erlang--and that's kind of sad.
- saurik 4y ago
  Erlang was originally either implemented in Prolog or was even a library / extension for Prolog, and its pattern matching functionality is just "because it was all Prolog and the developers were using Prolog", so it isn't really fair to give Erlang any credit at all for that as it wasn't even independently designed.
- medo-bear 4y ago
  > For example: hot upgrading. The fact that an Erlang process can tail call itself means that you can swap in a new process with the same signature at the tail call of the old process. Nobody else does this that I know of common lisp is in a league of its own when it comes to hot reloading and debugging

not_me_ever 4y ago

We didn't forget it. We burned it with fire, and then buried it. Most of us still of nightmares of it. Some didn't survive. :(

sunshinerag 4y ago
Care to share one of the nightmare

anonyfox 4y ago

I really love Elixir (and somewhat Erlang) and all the mental models and how developing in the ecosystem feels like, especially with phoenix/liveview. Having said that, nowadays anything that can't really run on AWS Lambda is a nonstarter in any company tech discussions, no matter how cool/productive it is. The operational benefits of serverless are simply too great especially when trying to scale up.

dgb23 4y ago
I don’t quite understand this. Doesn’t the BEAM runtime also have operational benefits over “lambdas”? Also not every application or component thereof wants stateless servers? What about live collaboration, game servers or just generally holding stuff in memory for perf reasons.
- mikl 4y ago
  Yeah, one could easily argue the opposite: The excellent scaling characteristics of the BEAM means that there’s no need to use extreme performance compromises like AWS Lambda. You can scale an Erlang or Elixir application extremely far by just giving it more compute resources.
dmpk2k 4y ago
You are vastly overestimating the importance of AWS Lambda, even in web tech circles.
MrBuddyCasino 4y ago
This has it backwards - lambda is only suitable for the cloud equivalent of shell scripts, anything more complex and it becomes an unmaintainable rats nest that cannot be debugged.
- bongobingo1 4y ago
  Just hook up Amazon™®© X™®©-Ray™®© into Amazon™®© Redshift™®© then use Amazon™®© Athena™®©! Simple!

Joel_Mckay 4y ago

Erlang/Elixir + OTP is unique, and for those that don't understand the use-cases its a mystery why. The article is an obvious troll, as popularity is not an indication of utility. =)

mikl 4y ago

The reason Erlang (and Elixir) are interesting are not the languages themselves (although Elixir is a very nice language in my opinion), but the runtime behind them, BEAM. The BEAM is the brainchild of the excellent engineers at Ericsson, the product of decades of R&D into building performant, scalable and reliable software for their telephony products. It scales like a dream, runs your application on all available cores with no trouble at all, handles massive amounts of concurrent requests without breaking a sweat. The programming techniques it enables with projects like Phoenix LiveView are unique and powerful.

gjvc 4y ago
Does "BEAM" mean anything / is an acronym?
- glenngillen 4y ago
  Originally “Bogdan's Erlang Abstract Machine”, but then the subsequent maintainer was named Björn so you could sub that in too.
  - sodapopcan 4y ago
    And the predecessor to BEAM was JAM (Joe’s) which is a bit of a shame we didn’t end up with that acronym… or not, I guess.
  - frou_dh 4y ago
    IIRC Joe Armstrong said he was puzzled why people latched on to the term "BEAM" so much, and he preferred that it was simply referred to as the Erlang VM.
    - andsoitis 4y ago
      Beam, with one syllable, is more convenient to say out loud than Erlang VM. It also sounds cooler.
      - 4y ago

MattPalmer1086 4y ago

Well, I can't speak for all finance firms, but ours uses Erlang. Admittedly it's not used a lot, and Java and C++ are more widely used these days.

jjallen 4y ago
Do you think Rust will replace these over time? What are the blockers for this? Is Rust perceived as a "better" language by those in your profession but of cours e you can't rewrite everything every 5-10 years? Would finance apps be written in Rust today if all of the C++/Java applications weren't already written?
- vitorsr 4y ago
  I cannot name a single high-quality scientific computing and numerical algorithms Rust library that is not a thin layer over established C and C++ libraries.
- brettdong 4y ago
  I haven’t heard any major stock and derivatives exchange providing connectivity SDK or documentation in Rust but there is always plenty of them in C/C++.
  - jjallen 4y ago
    This is true. Though I see some market data providers offering Go ones.
- antonvs 4y ago
  I’m a big fan of Rust, and am currently working on a major Rust project, but I don’t think it’s currently a viable replacement for most Java apps, nor is it really intended to be. If anything Go is closer to fitting that bill, if only because of its traditional garbage collection. Applications written in Java by definition aren’t too concerned with memory management, and Rust is objectively a step backwards for them. Rust is a more credible replacement for C++, but there I think it will be fighting inertia. Many C++ devs are actively against changing languages. I’ve also seen people “writing C++ in Rust”, using unsafe everywhere so they don’t have to figure out how to design their code to fit Rust’s model. You then end up with a kind of worst of both worlds.

haspok 4y ago

Maybe the title would have been better like this: "PROLOG: The coding language that finance forgot." Erlang (the language) is rooted in Prolog, and many of its best traits can be traced back to this fact. That everything is a pattern, and you can pattern match pretty much anything is rarely found in other languages, for example. Elixir made a mistake in my opinion when it went with a Ruby-like syntax. Also, there are those kinds of problems where in Prolog you can express and solve them in a few lines, in other languages you struggle a lot (and at the end you just reimplement half of the backtracing engine anyway - see Greenspun's tenth rule). Why it is not more commonly used in banking / finance is one of the greatest mysteries of life.

codesnik 4y ago
backtracking isn't hard to implement, though. Depth-first search is more or less what it is. But erlang lost most of the prolog ancestry, backtracking isn't there, for example. BEAM has a lot of concurrency neatness though, hard to reimplement or even mimic in languages not specifically tailored for from ground up.
brightball 4y ago
Elixirs syntax is only Ruby like in that it’s very readable IMO. Any similarity with Ruby stops there.
- adenozine 4y ago
  Well sure but you could be more clear. Block parameters, implicit parentheses for certain method/function calls, uppercase significance, symbolic significance for brackets.
  - amalgamated_inc 4y ago
    Elixir doesn't have blocks as a separate concept like Ruby. The "blocks" are just syntax sugar for passing keyword lists of code to macros. What do you mean by "symbolic significance for brackets?"

loftsy 4y ago

I've written some Erlang and found the syntax awkward. One example of this is that variables can only be bound once. This means you end up writing: Val = SomeFunc() Val1 = Func2(Val) Val2 = Func3(Val1) Yes I know you can use the functional style to minimise having to do this but you still end up seeing this pattern in real code. Kubernetes has done a good job of replacing OTP. That said I think Erlang is still an interesting language to learn just because of how different it is.

codesnik 4y ago
I personally don't find this binding once behaviour problematic in any way, but Elixir specifically addresses this (it creates another variable with the same name, though)
- holsee 4y ago
  I wish they didn't tbh, it makes me sad. Not allowing rebinding does provide a little bit of encouragement towards factoring things better, but I have seen manys a `X1` `X2` in my time :(
  - weatherlight 4y ago
    its a bit of a smell, but good elixir code doesn't have to worry about rebinding for bindings in the same scope. 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/rFeb3Env-6YJ 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.

oleks 4y ago

What does finance have to do with distributed systems? Finance is much more about mathematical modelling, which is an utter pain in a dynamically typed language with nothing but library support for state management.

capableweb 4y ago
Downtime is death, and performance is important. Distributed systems usually can help you avoid some of the types of downtime, and can help you manage throughput, although straight up latency tends to be become slightly worse.
eminent101 4y ago
Finance companies were doing distributed systems even before Internet existed. Yes, finance has a lot of numerical work but it has a lot more data pipeline work. The reason for this is to move market data from one geographical location to another. To make profitable investments, finance companies need accurate market data from all over the world available and processed at its datacenters as quickly as possible. For this reason in the early 1980s finance companies were laying down their own cables and writing their own link layer protocols to move data from one location to another. Now in the 21st century this has only got more intense. There is much more competition in this space. So finance companies that can make distributed systems right and reliable stand a good chance to the most money from the markets.
mardifoufs 4y ago
Finance is a huge field. I'd say the need for mathematical modelling, in one form or another, is pretty universal no matter what you do in Finance. But there are also tons of other stuff you might need on top of that depending on what specific field of finance you work in. Distributed systems can provide the data that your model relies on, or even the platform where the model itself needs to run on.

danielam 4y ago

For completeness, TD Securities is/was using Erlang for an in-house GED trading platform.

qohen 4y ago
To save others the Googling: GED == Global Equity Derivatives.

4pkjai 4y ago

I wonder if rust will end up as a coding language finance forgets.

aynyc 4y ago

Erlang isn't dying but not many people care for it in capital market. Looks at the traits of Erlang, it's designed for telecom environment which is almost opposite of capital market. 1. Fault tolerance is almost all hardware driven. Capital market participants spent billions of dollar building reliable private networks. 2. Distributed in trading doesn't mean what FAANG are doing. Trading systems for example usually run 2 hot-warm systems with real-time replication commits, that's about it. They don't run horizontally scaled systems because network time would kill their performance. In my experience, I haven't heard anyone asking for hot swap code and high availability (outside of trading hours). Are there shops out there that run Erlang? Sure, but most companies don't care about Erlang simply because its value isn't better than Java/C/C++.

jonhohle 4y ago
Funny anecdote about one of the FAANGs: before the idea of service meshes and Consul and Envoy a similar idea was being rolled out to transparently proxy, encrypt, and authenticate traffic between services. The initial implementation was on erlang and didn’t cause any operational issues for our team, from what I remember. The project was moved to another team who decided for version 2 to rewrite in Java (high made sense from an integration perspective). Unfortunately, they hadn’t tested at scale along with whatever it was servicing and as it was being rolled out it quickly ballooned in memory causing systems to swap and fall over. They eventually got it working, but the rollout was less than ideal and unfortunately an erlang project that affected a significant amount of traffic without notice was deprecated.
- weatherlight 4y ago
  Everyone always talks/jokes about, "Rewrite it in Rust," think about all the business applications over the years that had been rewritten to Java, just because. Usually under the guise of, "Kids coming out of college will have an easier time wrapping their heads around Java," than some other lang. In my time as an engineer, I've seen quite a few Scala and Clojure apps, get rewritten in this manner. This is all antidotal, of course.
  - 4y ago

college_physics 4y ago

Finance means different things to different people. Are we talking about trading "finance" (including high frequency trading), investment banking "spreadsheet" finance, consumer or corporate "database" finance or maybe even (the horror, the horror) "defi" cryptofinance? What is true is that finance in almost all its guises is a world apart in terms of information technology. Closed and proprietary, ultra expensive and arcane, highly regulated etc., it is an information technology branch that evolved separately and it shows. Whether that will remain so is an interesting question. So called "fintech" has been a thing for a while. E.g. whatsapp is famously built on erlang, so if Meta wants to turn it into a super-app (the "Asian way") you will have a de-facto application in "consumer" mobile/payments finance.

djtango 4y ago
Wasn't WeChat built in Erlang as well?
- jjtheblunt 4y ago
  I think WhatsApp was Elixir
  - qohen 4y ago
    I think WhatsApp was Elixir 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 https://dl.acm.org/doi/10.1145/3546186.3552537 [1] https://www.youtube.com/watch?v=do9f2FKsKxM https://www.youtube.com/watch?v=do9f2FKsKxM [2] https://github.com/WhatsApp/eqwalizer https://github.com/WhatsApp/eqwalizer [3] https://www.beamrad.io/35 https://www.beamrad.io/35 [4] https://news.ycombinator.com/item?id=32330284 https://news.ycombinator.com/item?id=32330284
    - 4y ago

innocentoldguy 4y ago

I've worked for two fintech companies (Divvy and Mastercard) that use Elixir. It is excellent language to solve finance-related problems due to its ability to supervise code and recover from unexpected issues.

djtango 4y ago

I heard on the grapevine once that Goldman Sachs have a proprietary distributed database built in Erlang. Can neither substantiate nor deny but did make me wonder about all the hidden proprietary tech out in the world...

jelkand 4y ago
Most of the hidden proprietary tech at Goldman Sachs was built in the early 90s, so a bit less sexy than Erlang. Impressive in its own right though.
Terretta 4y ago
> heard on the grapevine once that Goldman Sachs have a proprietary distributed database built in Erlang From the article, third paragraph: Goldman Sachs built its messaging system using RabbitMQ, which runs on Erlang, in 2018. Jonathan Skrzypek (who now works for Coinbase) was running the messaging engineering team at Goldman at the time. The system had to be fault-free because the messages it was transmitting could "worth a couple million dollars," said Skrzypek. RabbitMQ was chosen because of its resilience and "reliable delivery, guaranteed delivery."
- qohen 4y ago
  A comment to the posted-article, from "Frellus", who identifies as ex-Goldman, suggests RabbitMQ might not have been used so extensively: Ex-Goldman person here. To the best of my knowledge, RabbitMQ was used in spots but not where reliability was critical. Instead the main message brokers were IBM MQ and TIBCO. RabbitMQ would certainly lose messages in the event of a crash, and I'm not sure it would have been used for the main message bus given the rate of events. Additionally, Erlang was used for SecDB queries quite heavily. This was the bread-and-butter of the firm (https://github.com/saleyn/secdb https://github.com/saleyn/secdb)
  - djtango 4y ago
    SecDB fits the bill a little better for what I had heard of. Thanks

jamal-kumar 4y ago

The real eureka moment for me getting why erlang and elixir are game changing was realizing how easy it is to build distributed applications using them, especially in Elixir the facility of this is just incredible. The OTP (Open Telecom Platform) as it's called is probably its coolest feature in my eyes. https://elixir-lang.org/getting-started/mix-otp/introduction-to-mix.html https://elixir-lang.org/getting-started/mix-otp/introduction...

dgb23 4y ago

Nubank aqui-hired the people who make Elixir? So it's not quite forgotten.