♫Money Money Money… <high-pitched>Money</high-pitched>♫
^.^
1 Like
Just recently it occurred to me that the question isn’t so much WHY are banks still using Java (I think fairly well answered here), but WHAT SUPPORT does Elixir have for playing nicely with languages like Java and conventions used in Entreprise Architectures found in Java Shops (SOAP, WSDL…)
The Java investment by banks is a SUNK COST (another financial term) but banks maybe open to MARGINAL COSTS of using Elixir as long as there is good integration affinity given increased developer productivity…
Big data wise, Elixir GenStage/Flow is a start to providing some initial capabilities of Apache Spark
I came across this thread from a while back…(Clearly I’m not the Java Enterprise Expert)
2 Likes
Ego validation can be pervasive and dangerous in all trades, I think not falling into media and buzzwords is important to retain professionalism. But is hard to not being impressionable when you are young and exited for all the “new stuff” that is coming. 
Recently found this article moderately related to this discussion? It actually touches upong the points you mention @bibekp.
3 Likes
Great food for thought @chouzar! (Sorry I missed this - to which everyone needs to read Joe’s article linked above. I’ll paste a little:)
https://joearms.github.io/published/2016-08-08-Draft-Payment-System-in-Erlang.html
What are the difficult problems in a payment system?On a couple of occasions I found myself talking to people who had personally built large scale financial payment systems so I asked them what the most difficult problems were and got two answers:
Satisfying the regulatory authorities, and,
Interacting with legacy systemsRegulation in financial systems is vital. Financial transactions have to be approved by regulatory authorities. It is not enough that the software is correct and performant. You must be able to satisfy the regulatory authorities that the software is doing the right thing and obeying all the regulations.
Financial systems do not live in isolated worlds, they interact with legacy systems written in archaic languages and with bizarre and poorly documented protocols. Interacting with the world as it is, and not how we would like it to be is a huge problem.
Funnily enough - both experts did not mention performance as a problem - actually virtually nobody mentions performance as a problem - if the software actually works (which is often viewed as a miracle, since most projects are canceled because the software never actually works) and is slow, the usually solution is just to “throw more machines at it”.
1 Like
I’ll bite. Mindshare and momentum. IBM took over the enterprise space with J2EE back in the late 90’s. They hired every Java developer they could find and convinced the world they put the e in e-business. I still find customers planning to rebuild their enterprise stacks with Portal Server which as been dead for 10 years now. The ones who buy the tech aren’t the ones tasked with implementing it.
I worked for a large banking customer who was trying to get off the mainframe. They chose SAP but hated the interface. So, they decided to write their own front end in Java by themselves. It took 8 years and was a disaster. Enterprises are too big to be innovative, IMHO, and frankly they don’t want to be. They want cookie cutter COTS solutions which are written mostly in Java now anyway.
If you want Elixir in the enterprise, start with tooling. All those little utils you create to get your work done can be done with elixir. Internal web sites for support teams can be Phoenix.
If you really want Elixir in the enterprise, write the Oracle driver for Ecto. 
4 Likes
Let’s not. 
1 Like
jam_db already has. 
I actually just mount an Oracle database as an FDW inside PostgreSQL and access it that way at work. ^.^;
3 Likes
Another reason why banks use loads of Java is because there aren’t any new banks, just old banks acquiring/merging with other old banks, with the same flavor of engineers moving laterally and vertically through the career paths offered therein.
If there was a robust banking startup ecosystem that was somehow more attractive and more visible to consumers than the banks of olde, there would be a greater diversity of langs used in bank engineering, but a lot of the properties of “startup banks” would make them fundamentally unattractive to consumers.
As previously mentioned, we’re seeing fintech/banking innovation with blockchain among the most technologically advanced banking/creditor firms and in developing countries because of the security/persistence of the 'chain…
… so maybe current BEAMy blockchain initiatives will eventually result in more Erlang/Elixir bank code 
1 Like
Not all banks are old … and use old technology …
https://www.jpmorgan.com/country/PL/en/jpmorgan
1 Like
Java is stable and mature alright but that doesn’t mean much. Other ecosystems are stable and mature as well (especially Erlang but let’s not forget that modern C++ is pretty huge and well-tamed in not a small amount of areas). What mostly wins is good enterprise-level marketing. Managers LOVE to hear about automated processes and all their favourite buzzwords – they imagine less hired people, saved expenses, pats on the back, fat bonuses, and golf with the CEO. Of course they’ll bite the bait. And that’s exactly what happened.
I was in several very big Java projects, including one for the government of my country, between 10 to 13 years ago. Java was a crapshow; the JVM had to be very finely tuned to not run out of memory and be killed by the Linux OOM, GC pauses were unpredictable – but consistently worse as the apps ran for longer and longer – and maintaining the code was a nightmare. People were so happy to autogenerate code with Eclipse’s numerous addons it wasn’t even funny. Of course the moment that programmer moves on to something else, good luck maintaining or even understanding those pieces of code. And it’s all “business-critical”. No it wasn’t. It was just that everybody was too afraid not to rock the boat. The system miraculously worked somehow and nobody wanted to accidentally break it. (Nevermind the fact that at least 1/3 of the system DID NOT actually work but nobody wanted to complain either.)
That’s all that Java has: INERTIA. It was sort of good before. It’s not good for years now. Hotspot JVM is the only good thing about it nowadays.
One of the other reasons why Java and modern C++ are a pretty bad idea is that there are way too many ways to do stuff. That’s why languages like Go found a sympathetic ear from many devs; its surface is lower and is easier to reason about. Go’s code is verbosive, yes – and it’s easy to not handle an error, which is a huge anti-pattern – but as verbosive as it is, it’s still easier on your cognitive abilities. Same goes for Elixir IMO, if we exclude the OTP; it’s mostly very easy to parse by a human.
Banks have plenty of money to experiment with new tech and try to save expenses long-term. R&D in these areas isn’t even that expensive. But you can’t expect bean counters to be interested in R&D. So there’s that.
3 Likes
@njwest Its funny you mention startup banks because I know of a NYC former bank guy that is trying to do this, as I spoke to him probably 2 weeks ago. Basically since the regulatory burden of banks is quite onerous they have been implementing a version of a bank in a traditional language (I think C++ or Java - and was easier to find bodies here IMHO) over the past few years. Now that I believe they’ve gotten the regulatory approval are now trying to replicate the functionality in Erlang (perhaps Elixir) or atleast about to start from what I gathered…
They are entirely looking at Erlang/Elixir primarily to solve the settlement latency problem… Banks have billions of dollars tied up in money transfer settlement latency (e.g. required to wait a business day, or a week, etc…). Banks would clearly rather use this money at a higher yield! With all the excitement about blockchain, and I believe it takes 10 minutes for a bitcoin block to be added to the blockchain and banks/bank entrepreneurs are definately taking notice! 
10 minutes vs 1 week or 1 day? Which you prefer? (and of course the security and persistence of the chain…)
2 Likes
“No new banks” was hyperbolic, I’ll admit, but many of Goldman Sachs’s banking services (not trading services) still run on legacy systems. I know they’re actually updating one of their most active regions to the Java architecture they use in America with shiny React front-end bits.
JP Morgan Chase has been doing very interesting stuff with blockchain and ZEC, and Quorum is definitely an interesting Ethereum mutant…
…but regarding Quorum, JP Morgan does not seem interested in sustaining it, judging by their thinking it should be “spun off” (maybe they don’t want to take responsibility for it):
This goes back to my point that the big players’ R&D interests regard fintech solutions that attract absurd amounts of investment, or real-time data (enter Erlang VM plz) hence the streaming langs you reference
As far as basic banking and information services go, the fact that the meta description for JP Morgan’s Quorum webpage renders jacked up JQuery is further evidence of their reliance on dated web tech:
Advancing Blockchain Technology iconDownload Quorum $j(“h1”).css(‘textShadow’,‘black 0.1em 0.1em 0.2em’); $j(“h1”).append(‘™’);
Maybe it is good that they want to Quorum not be related to JPMorgan only, like Kubernetes now is not related to Google.
Any way Quorum is listed under
Enterprise Smart Contracts with Marley Gray
In this episode, Marley Gray from Microsoft joins the show to discuss enterprise smart contracts–why you would want to use them and how they can be architected. Marley has worked on banking and financial technology for over a decade, and makes some strong arguments for why banks will adopt smart contracts, and the timeline for how that might take place.
Maybe little off topic
https://www.cryptoground.com/article/surprise-fees-by-jp-morgan-chase-on-crypto-card-transactions-leads-to-a-lawsuit
2 Likes
