5 ms·

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 J

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.

dzonga 4y ago
would Golang have a role in finance ? pros and cons of java vs golang in finance besides java being widespread ?
- xmcqdpt2 4y ago
  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.)
sclarisse 4y ago
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.
- giraffe_lady 4y ago
  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.
  - sclarisse 4y ago
    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.

dzonga 4y ago

would Golang have a role in finance ? pros and cons of java vs golang in finance besides java being widespread ?

xmcqdpt2 4y ago
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.)

sclarisse 4y ago

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.

giraffe_lady 4y ago
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.
- sclarisse 4y ago
  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.