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…
Erlang: The coding language that finance forgot (2022)
51–60 of 155 posts
Re: Erlang: The coding language that finance forgot (2022)
#52Earlier 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.
Re: Erlang: The coding language that finance forgot (2022)
#53Well, 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?
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)
#54Earlier 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++.
Re: Erlang: The coding language that finance forgot (2022)
#55Maybe 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…
Re: Erlang: The coding language that finance forgot (2022)
#56Earlier 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.
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)
#57The 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…
Re: Erlang: The coding language that finance forgot (2022)
#58Re: Erlang: The coding language that finance forgot (2022)
#59Erlang 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…
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)
#60What 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.