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.
Erlang: The coding language that finance forgot (2022)
31–40 of 155 posts
Re: Erlang: The coding language that finance forgot (2022)
#32Well, 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?
Re: Erlang: The coding language that finance forgot (2022)
#33I 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.
Well I remember this announcement [0] and there was this [1] but I'm not sure that went anywhere.
[0] https://aws.amazon.com/fr/blogs/aws/new-for-aws-lambda-use-a...
[1] https://github.com/aws-samples/aws-lambda-elixir-runtime
Re: Erlang: The coding language that finance forgot (2022)
#34Well, 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 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.
Re: Erlang: The coding language that finance forgot (2022)
#35Maybe 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.
Re: Erlang: The coding language that finance forgot (2022)
#36Well, 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 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)
#37Well, 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’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.
Re: Erlang: The coding language that finance forgot (2022)
#38I'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)
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.
Re: Erlang: The coding language that finance forgot (2022)
#39Earlier quoted context omitted.
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…
> 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.
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.
Re: Erlang: The coding language that finance forgot (2022)
#40Well, 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 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 computers in a high performance way with correct semantics. In most cases performance is very secondary to being able to onboard programmers quickly to write oodles of code that can be modified rapidly to address changes in regulation or markets.
Java is good for this because it's a memory safe language, quite performant, super easy to learn (and quite common already) but also because you can abstract everything in a way that makes it possible to say, change the definition of currency exchange rates to account for new business rules without having to rewrite all the existing code.
Rust would require passing Box absolutely everywhere, at which points you are basically writing Java with extra steps. And I say this as someone who loves Rust and work primarily in Scala.