Does anyone working at one of these banks or similar know if this information still holds true?
And have any of the banks started using uv yet? Or will they forever be using pip?
31–40 of 74 posts
Does anyone working at one of these banks or similar know if this information still holds true?
And have any of the banks started using uv yet? Or will they forever be using pip?
The previous discussion was fascinating: https://news.ycombinator.com/item?id=29104047 Does anyone working at one of these banks or similar know if this information still holds true? And have any of the banks started using uv yet? Or will they forever be using pip?
> but the default ring is more or less a single, global, object database for the entire bank. Is this really the case? I'm sure there are plenty of transactions that for umpteen different reasons must not be exposed on a global level.
But anyway, specific trades are rarely private to one part of the bank for many reasons. For example regulatory: these days you have to notify the regulator about every trade.
> but the default ring is more or less a single, global, object database for the entire bank. Is this really the case? I'm sure there are plenty of transactions that for umpteen different reasons must not be exposed on a global level.
What I imply from the description is that, the default ring contains some shared global public data (e.g. a cache of bloomberg informations), and each individual team will have their own rings. Afterall there's no that many you can fit into 16mb
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.
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.
> but the default ring is more or less a single, global, object database for the entire bank. Is this really the case? I'm sure there are plenty of transactions that for umpteen different reasons must not be exposed on a global level.
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.
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.
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.
>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/
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?
There's a very big difference between the kind of bank you walk into to get a checking account, versus one that has no (individual) customers and whose job it is to assist with IPOs or whatever.
> 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