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.
Although, "writing C++ in Rust with unsafe everywhere" does grant you the right to append "X written in Rust" when you finally do your Show HN, leading to a 26.7% increase in upvotes, so there is that.
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<dyn T> 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.
Yeah I mean in so far that Go is basically Java-like (GC-ed, statically typed, has interfaces, simple language) it could be used there too. Go targets very much the same kind of problem as Java. C# too.
I only have a passing knowledge of Go so I can't comment on it's advantages or disadvantages much, although one of the great strengths of Go (tooling) is also very much a strength of Java (at least in large companies where there will be dev env teams that set up the Java environment for you.)
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.
I mean, on some level, yes, but if all of the complexity people wrote with Java was merely collections of versioned strategy-patterns with average-level organization, it wouldn’t be sufficient for the language to have the AbstractEnterpriseBeanProviderFactoryFactory reputation that it does today.
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.
I know Rust is a systems programming language, but I've been playing with it for some time writing high-level stuff like REST/GraphQL APIs, websockets and web backends in general. And I have to admit it is a breath of fresh air.
No crazy enforced OOP with a gazillion classes and inheritance, no non-sense design patterns just because the language enforces you to use OOP for everything, an amazing type system, no null pointer exceptions, great compiler error messages and so on...
Of course there are problems, like any other language, but it is crazy how it as a systems programming language is so good at expressing domain logic.
Java has a much bigger ecosystem, but judging JUST by the language design, I'd pick Rust over Java without thinking twice.
Not OP and not choosing a side in this thread on the RIIR topic, but I would like to address why I like Rust over those other language - in addition to memory safety, I really like the stronger types (specifically sum types), the move semantics, and the data-race safety.
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++.
