Live data from Hacker News

Erlang: The coding language that finance forgot (2022)

efinancialcareers.com

51–60 of 155 posts

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

#51
post #32

Earlier quoted context omitted.

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?

I don't think Rust is really suited to replace the million LOC java apps that are found everywhere in finance. (The C++ ones probably ought to be rewritten in Java also, IMO. Or C#.) The reason that such enormous software exists at banks is because the business rules are immensely complicated. All this code basically exists to deal with the complexity of the financial world, not the complexity of interacting with com…

Having seen actual sprawling Java codebases at banks and elsewhere, they tend to end up sprawling as they deal with (a) some specific old computer, or (b) the complexity of some dumb framework in the language itself. The business logic only approaches that level when you’re dealing with specific products are treated for things like taxes and customs, or, medical billing codes.

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

#52
post #45

Earlier quoted context omitted.

Does "BEAM" mean anything / is an acronym?

Originally “Bogdan's Erlang Abstract Machine”, but then the subsequent maintainer was named Björn so you could sub that in too.

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.

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

#53
post #32

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.

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?

I personally like Rust a lot, but it isn't on our radar at all. Nobody has even mentioned it.

Java and C++ are fine for what we do. What advantages (other than memory safety, which Java has too) do you see in Rust?

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

#54
post #32

Earlier quoted context omitted.

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?

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

This is true. Though I see some market data providers offering Go ones.

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

#55
post #35

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…

Erlang as a programming language for writing fault-tolerant systems has quite little in common with Prolog, except the syntax. That is, the semantics of Erlang vastly differ from Prolog.

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

#56

Earlier quoted context omitted.

I don't think Rust is really suited to replace the million LOC java apps that are found everywhere in finance. (The C++ ones probably ought to be rewritten in Java also, IMO. Or C#.) The reason that such enormous software exists at banks is because the business rules are immensely complicated. All this code basically exists to deal with the complexity of the financial world, not the complexity of interacting with com…

Having seen actual sprawling Java codebases at banks and elsewhere, they tend to end up sprawling as they deal with (a) some specific old computer, or (b) the complexity of some dumb framework in the language itself. The business logic only approaches that level when you’re dealing with specific products are treated for things like taxes and customs, or, medical billing codes.

Banks are not the entirety of finance, but having worked on some finance backends I agree with the comment you're responding to. Finance code is legacy by default because the policies it's modeling are political and regulatory, and subject to quick changes and reversals.

Often the law as written is ambiguous and your implementation is based on interpretation of a specific regulatory body, or even a single auditor, which frequently changes. In a country as heterogenous as the US, you don't have "business logic" per se, but just a bundle of jurisdictional exceptions, that all change out of sync with each other an incompatible ways. You often need to keep multiple implementations of the same ruleset active in your system for different products, based on when they were initiated as well. Any "changes" are actually only additions of complexity, you almost never get to remove anything.

None of these things are strictly unique to finance but they are pervasive concerns there. Codebases sprawl for other reasons too, certainly. But they necessarily sprawl for this one in finance.

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

#57
post #24

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 c…

What's the license for the BEAM runtime? I've found that Erland and Elixir are both Apache License, but I can't find out whether the bytecode they generate can be executed in a fully open source environment.

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

#59

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 co…

> 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

I made a blog post around this very idea, that new languages never get the adoption that they need, because existing languages simply incorporate the best ideas from the new languages.

At which point, why will anyone change the the new language if the features that are important have been fitted into their current languages.

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

#60
post #58

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.

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.
Post reply on HN