Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • I would give my left leg to learn how the permissions system worked – do end users (and PHBs) get to edit the rules directly? I fully expect some HR ass to go:

      can_view(Person) :- didPITAOnlineTraining(Person), ...
    by nxobject
  • > 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

    by horticulturist
  • The penny doesn't matter but being off by a cent can mean there are serious problems in the workflow.
    by AdamN
  • Precision?

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

    by TZubiri
  • Prior discussion: https://news.ycombinator.com/item?id=29104047
    by piinbinary
  • People turning up in hedge funds (i.e. much smaller) and trying to rewrite the bit of a bank they used to work in's equivalent of this article is so annoying.
    by mhh__
  • I think it is a pity they’ll likely never open source any of this stuff

    Of course, financial institutions have a lot of “secret sauce” - such as financial models - you’d never expect them to release.

    But this kind of underlying infrastructure isn’t really “secret sauce”

    by skissane
  • This infrastructure is more secret sauce than the financial models, which change rapidly.
    by veqq
  • Well I doubt these solutions are very useful outside; from what I read what they have is a universal data store (that isn't hard to implement using current off-the-shelf OSS), something for financial instruments that has a compositional nature (you won't encounter much of that in the outside world), plus some other quirky features.
    by Jianghong94
  • > I think it is a pity they’ll likely never open source any of this stuf

    The more they use cloud-hosted LLMs, the more likely it will get leaked into training data.

    by jgalt212
  • Morgan Stanley's version is open-source at https://github.com/morganstanley/optimus-cirrus , although I don't know how practical it is to actually run yourself. (They don't go quite as far as having the code itself be bitemporal and kept in the datastore, but most of the stuff in the article exists there)
    by lmm
  • 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.

    by manoDev
  • >Applications also commonly store their internal state in Barbara - writing dataclasses straight in and out with only very simple locking and transactions (if any).

    Right out of the gates, it's crazy how this contrasts with Mercury's Haskell infra

    https://blog.haskell.org/a-couple-million-lines-of-haskell/

    by TZubiri
  • Eh, to be fair, this post is about a _bank_, and the one you've linked is about _fintech_. They are not even close to the same space, even though they both deal with money.

    But also I suppose you may be saying exactly this?

    by devin
  • It sounds pretty similar actually. Barbara fills the same role that Temporal is doing at Mercury.
    by lmm
  • 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.
    by amyjess
  • What a well-written account of "how things are done".

    > Time to drop a bit of a bombshell: the [Barbara] source code is in Barbara too, not on disk. Remain composed. It's kept in a special Barbara ring called sourcecode.

    by axus
  • This makes it feel like a gigantic Smalltalk instance.
    by rbanffy
  • When first encountering these ecosystems and looking at the various pieces they contain, one may repeatedly ask: "why didn't they just use <off-the-shelf solution> 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.

    by tsukikage
  • Very much so, I worked on Quartz at BAML for a few years.

    The whole idea was actually to use as much existing Open Source technology as possible. Hence Python and it's rich library ecosystem, instead of something home grown like SecDB/Slang. This was supplemented with proprietary infrastructure and libraries only where there was a clear need. For example a Directed Acyclic Graph library to ease migrations from the Excel sheets used by Quants. The distributed object store was pretty neat.

    You could code up a basic web service with minimal functionality and have it running in nonprod in an afternoon, and then production the day after. All that boilerplate stuff was super low friction, so you could spend much more of your time on solving the actual problem.

    by simonh
  • That's only half the answer. These large investment banks' value-add is partly that they can integrate everything they know into these closed-world environments (kind of like a Smalltalk image), which is something that simply isn't done in the wider world because you can't accrete it out of smaller pieces and it doesn't make sense at all for smaller entities.
    by lmm
  • 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’ll rebase over upstream releases and everyone nods wisely. Then you skip a release, and another, and presto: you now you have Bank Redis or Bank Selenium or Bank Hadoop trapped on the last version of upstream before the fork but to which you can patch changes as fast as you like. I’d liken this to crossing an event horizon except the astronaut sees the universe freeze and fade away instead of the outside observer.

    It’s possible to make it work if the upstream project either gives you a majority vote (or at least a substantial share of the vote) on project direction, or you’re working on a project large enough to have lots of corporate (ie funded, high velocity) stakeholders already.

    by gorgoiler
  • 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 - Alpha and Quartz respectively. Barclays Capital has/had a similar system as well I think, but it’s not one I know about offhand - they did though, memorably, have a system that was pretty much Haskell-in-Excel.

    by elemeno
  • 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.
    by simonh
  • A lot of them retired too and enjoyed making bank producing a pile of hot mess that the rest of the higher ups did not fully appreciate the mess they were producing. Collected their multi million packages and left
    by Maven911
  • JPM's version was Athena (not Alpha) [0]

    [0] https://www.slideshare.net/slideshow/managing-python-at-scal...

    by Thrymr
  • I've worked at a bank and several large hedge funds.

    Some additional interesting tech stories I would add:

    - in 2010, the bank had retail Good Till Cancel orders from 1997. I think one was "Buy INTC at $6"

    - There is a mix of "I didn't know technology could do this" in the good sense and "I'm amazed this code a. works at all and b. hasn't had an outage in 6 years"

    - There is a strong desire, I chose this word carefully, to migrate off of legacy systems. That being said there are several; big issues: 1. it's a GIGANTIC amount of effort with often unclear ROI to the business, 2. upside is capped (maybe you get a promotion) but downside risk is huge (you could tank the business with an outage). 3. Slow, gradual refactors are generally better here but some things can only be "big bang" for various reasons

    - You tend to see old but performant and battle tested systems get retired in favor of shiny, new systems with lots of bugs. Why? It looks better on a resume to say "I retired old, crufty legacy system and rolled out a new system" instead of "I refactored old system to be better"

    - The complexities are wild e.g. Korean trading requires: a. traders to be licensed in Korea (even if they are working in NYC), b. servers to be in Korea c. tagging orders with not only their executions but also the exchange rate at the time

    - There are entire SYSTEMS built to track trade breaks (e.g. Bank A doesn't agreed with Bank B on fill 1248383). Some of these trade breaks are open for for YEARS due to litigation, companies going out of business etc

    I could go on and on about this.

    If anyone is ever interested in having me on a podcast to talk more about it, I would totally be up for it.

    by alexpotato