An oral history of Bank Python (2021) • Hacker News Board

Re: An oral history of Bank Python (2021)

#61

Post by CamouflagedKiwi » Fri, Jun 26, 2026, 2:38 PM UTC

gorgoiler wrote: post #35

tsukikage wrote: post #14

When first encountering these ecosystems and looking at the various pieces they contain, one may repeatedly ask: "why didn't they just use for this problem instead of writing this component/subsystem from scratch"? The answer is often that the battle-hardened mature off-the-shelf solution did not exist at the time the code was written. You're doing software archaeology.

In my experience it’s extremely difficult for a highly resourced corporate engineering team to get married to an open source project run by volunteers, consensus, or both. It is possible but you need to have a first class relationship with an upstream who will take your patches. Every patch delay puts more pressure on you and your team to fork the codebase and go it alone . You and your team sit down and promise you’…

Yes, agreed. And it's not just delays - when the upstream decides that they actively don't want to take a patch that you have a burning need for (and maybe you already have systems in production depending on it), that can accelerate the process to Bank Redis a lot.

I've rolled with the "we'll keep a local patch against upstream" for small changes before, which helps keep on track with upgrades, but depends how feasible that is.

Re: An oral history of Bank Python (2021)

#62

Post by benjaminwootton » Fri, Jun 26, 2026, 2:44 PM UTC

simonh wrote: post #57

elemeno wrote: post #8

To the best of my knowledge much of this originated with SecDB/Slang at Goldman - SecDB (securities db I believe) being the object store and slang the somewhat quirky C like language that ran with it (also the only language I’ve used professionally that let you have spaces in the variable names). Some of the folk that built that (or worked on it) ended up at JPM and Merrill where they built the Python centric version…

I worked on Quartz at BAML for 4 years, it was great. I met Kirat Singh once when he visited the UK, he took the basic concept from Goldman to JPM, then to BAML.

I was lucky enough to start my career sat on the next desk across from Kirat. Genius programmer and nice guy! He later went on to found Beacon platform which was the same again, as a cloud hosted service.

Re: An oral history of Bank Python (2021)

#63

Post by CamouflagedKiwi » Fri, Jun 26, 2026, 2:45 PM UTC

ForHackernews wrote: post #49

Havoc wrote: post #12

I've seen similar inside large financial orgs - what struck me was how there are these huge amounts of people that spend their entire working life inside this alternate IT reality. It's not unlike SAP consultants where their skillset is tied to one company. Also...these things tend to have fuckin terrible documentation. Good luck figuring any of this out. And you can't google it and your AI is just as lost as you

Isn't Google like this, too? They have their own source control system, their own IDE, their own databases. It seems like any giant organization eventually develops its own software center of gravity.

Yes, it is, there's a translation table for xooglers too: https://github.com/jhuangtw/xg2xg

The only real difference there (although it is a significant one) is that most of those internal Google tools tended to be very good, often ahead of the external state-of-the-art. That's a very different feeling to a baroque old stack inside a bank somewhere. Maybe the external world has caught up on a bunch of them more recently though which would start to change that.

Re: An oral history of Bank Python (2021)

#64

Post by debamitro » Fri, Jun 26, 2026, 2:58 PM UTC

Exhilerating article, but this has been shared on HN countless times

Re: An oral history of Bank Python (2021)

#65

Post by nxobject » Fri, Jun 26, 2026, 3:02 PM UTC

TZubiri wrote: post #24

horticulturist wrote: post #23

> This is because clients generally do not ring up about pennies. I’ve had clients ring up about pennies… it can be crazy what some people are motivated by

Precision? Quite common in accounting, the accounting equation must balance, it's like a checksum

Yes, OP started the sentence with that. But, you do make me wonder if floating-point imprecision would eventually lead to material issues...

Re: An oral history of Bank Python (2021)

#66

Post by ForHackernews » Fri, Jun 26, 2026, 3:07 PM UTC

CamouflagedKiwi wrote: post #63

ForHackernews wrote: post #49

Earlier quoted context omitted.

Isn't Google like this, too? They have their own source control system, their own IDE, their own databases. It seems like any giant organization eventually develops its own software center of gravity.

Yes, it is, there's a translation table for xooglers too: https://github.com/jhuangtw/xg2xg The only real difference there (although it is a significant one) is that most of those internal Google tools tended to be very good, often ahead of the external state-of-the-art. That's a very different feeling to a baroque old stack inside a bank somewhere. Maybe the external world has caught up on a bunch of them more recen…

I suppose it depends what you're optimizing for, but this Bank Python looks like it would be great for enabling productivity in a consistent shared environment with minimal setup required for devs. This looks far better than setting up jupyter notebooks, installing all kinds of pypi dependencies, etc. whatever the equivalent on the outside would be.

Re: An oral history of Bank Python (2021)

#67

Post by amyjess » Fri, Jun 26, 2026, 3:17 PM UTC

I remember reading this article when it was first posted here five years ago, and I've been fascinated by Bank Python since. It actually reminds me of a number of systems I've come up with in my head but never told anyone about or wrote down in any way.

Re: An oral history of Bank Python (2021)

#68

Post by tomrod » Fri, Jun 26, 2026, 3:18 PM UTC

A few of the scientific computing companies from the early 2010s got their traction due to Dodd Frank-required scenario and stress testing. SAS was not up to the challenge and R could not multithread.

These initiatives were independent of Minerva and Athena, which was good but not very useful to the more mundane parts of the bank everyone off the financial trading floors care about.

Re: An oral history of Bank Python (2021)

#69

Post by monknomo » Fri, Jun 26, 2026, 4:11 PM UTC

TZubiri wrote: post #27

monknomo wrote: post #7

Earlier quoted context omitted.

to be fair, it is a fintech that wants to become a bank

It's a bank, that is, a bank in all but name for regulatory purposes.

I think they applied for an actual charter, so that will probably change

Re: An oral history of Bank Python (2021)

#70

Post by manoDev » Fri, Jun 26, 2026, 4:14 PM UTC

If you ever worked with mainframe, you'll see a lot of similarities:

- Unified interface for object stores

- Source code stored with data files

- Job runner

I also see some similarities with Lisp machine, the fact Python also has a REPL, and able to dump/restore image state (but in this case discrete objects are serialized, not the entire memory).

This might sound crazy for people used to having 90% glue code / 10% business codebases, but to me seems like a very efficient way to have users directly drive what is effectively a large computer, and more like how things used to be.

The drawback is that it seems to be a monolith, and maybe hard to reimplement on top of more modern foundations. But as a general API, it seems to make sense.