Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Griffin – A fully-regulated, API-driven bank, with Clojure

juxt.pro

Post reply on HN
Print view View original

211–220 of 223 posts

Re: Griffin – A fully-regulated, API-driven bank, with Clojure

#211

Post by yyyk »

godon27 wrote: post #98
epolanski wrote: post #44

Earlier quoted context omitted.

The issue is always the same: traditional banking is frictionless, very cheap and convenient for 99.9% of people out there. Crypto isn't frictionless, it's not cheap and it solves problems that only the 0.1% has such as the need of transferring large amounts of "money", without tracing, in short times, across the globe but it undoes the benefits that the 99.9% has while bringing complexity. Plus, nobody really wants…

I'm tired of hearing the "works on my machine" line about banks. Here's a few issues I've run into in the last few years: - I dissolved a corporation in Korea and it took nearly 1.5 years and $8k USD in lawyer fees to get ~$80k USD out of the country. My other option would've been to go back to Korea and buy Rolexes. - I moved to an Eastern European country and spent several weeks providing KYC/AML docs after attempt…

So 'crypto usecases' summary:

- Avoiding the law.

- American banking is much worse than most of the world's (but not compared to crypto's risks of 'being your own bank'), especially for international transfers.

These are not very great use cases.

Re: Griffin – A fully-regulated, API-driven bank, with Clojure

#212

Post by weird-eye-issue »

n42 wrote: post #202
danpalmer wrote: post #139

Earlier quoted context omitted.

Perfectly engineering is nearly impossible. In my experience systems always end up under or over engineered. The distinction also depends on what's on the backlog – if you have a feature that's going to be hard to implement because of inflexibility, you're under-engineered, if it's easy but other features require more work than they should, you're over-engineered. I can't make a judgement call on whether they're over…

exactly this. I see it as this: over or under engineering can basically be boiled down to requirements and budget (which is itself a requirement, but many engineers don't seem to see it that way). over engineering is anticipating for future requirements that aren't ever realized, or realized so far in the future that upfront cost outweighed the cost of putting it off for later. under engineering is not anticipating f…

I feel bad for you. It must be tough living in such a black and white world :(

Re: Griffin – A fully-regulated, API-driven bank, with Clojure

#213

Post by KingMob »

seabass-labrax wrote: post #65
gremlinsinc wrote: post #38

I absolutely hate when an articles starts out with: > IN A STARTUP, YOU SHOULD BE USING THE MOST POWERFUL LANGUAGE YOU CAN, AND THAT IS CLOJURE. says you. one opinion. in a startup you should use the language that your team can build and launch your MVP the fastest so you can get your first customers or funding. Hell, this could be a low code or no-code platform(probably not in fintech, just saying with startups in g…

That catchline makes a lot more sense when you consider that JUXT is the most prominent company specialising in Clojure aside from Nubank itself, and have their logo at the foot of pretty much any conference remotely touching on Clojure topics. Clojure has a fairly insular community that overlaps with other lisps more than it does something more popular such as Python or PHP, so the cliché (admittedly, one with some…

> stating our presumed superiority is almost a greeting at this stage!

I think you're joking, but as another person in the Clojure community, please don't do this for real. The community already has issues with feeling "elite".

Re: Griffin – A fully-regulated, API-driven bank, with Clojure

#214

Post by anentropic »

n42 wrote: post #205
anentropic wrote: post #163

Earlier quoted context omitted.

maybe by not building our own database seems a bit like engineering for the sake of engineering I'm all for it if it floats your boat, not sure that it's what I want from my bank though

where in the article does it say they built their own database?

it said they built a Datomic-like db on top of FoundationDB

sounds pretty cool, but was it really necessary...?

Re: Griffin – A fully-regulated, API-driven bank, with Clojure

#215

Post by logifail »

martinald wrote: post #151
avianlyric wrote: post #146

Earlier quoted context omitted.

It’s a mix. Many of these innovations came into existence before their EU counterparts. Faster payments, for example, is a completely different system to instant SWIFT payments which most of the EU uses. Having said that, Denmark is another notable country for its innovation financial systems, ahead of the U.S., many of its EU neighbours and in some areas ahead of the UK. But the UK has always had a vibrant and innov…

Instant SEPA, not SWIFT.

> Instant SEPA

Faster payments in the UK don't attract an additional charge. Is this the case for instant SEPA?

Re: Griffin – A fully-regulated, API-driven bank, with Clojure

#216

Post by kozzz »

Every time I see ZeroMQ being placed alongside RabbitMQ or Kafka as an example of a message queue system, it makes me wonder if the person who wrote that really knows what they are talking about. If they would rtfm they’d understand that ZeroMQ is more of a transport feature, that doesn’t really intersect with other mentioned projects in its features.

Re: Griffin – A fully-regulated, API-driven bank, with Clojure

#217

Post by kiitos »

dustingetz wrote: post #207
kiitos wrote: post #190

Earlier quoted context omitted.

I guess you're suggesting that you can build an abstraction layer (I guess you're calling it missionary) which (a) can reliably intermediate every interaction between a user program and any potentially non-deterministic API, and (b) can be configured at runtime as synchronous/serial/deterministic or async/concurrent/non-deterministic. Is this accurate? (If so, I'm pretty confident that this is infeasible.)

Electric Clojure backends already get such effect supervision for free (you'll need to manually tag sync/blocking effects). https://github.com/hyperfiddle/electric https://github.com/leonoel/missionary

> you'll need to manually tag sync/blocking effects

Well, that's the hard part, so if I need to do it myself, your library isn't providing much value.

Re: Griffin – A fully-regulated, API-driven bank, with Clojure

#218

Post by Improvotter »

I've always been interested in these fintech APIs but wonder what competitive advantages the companies that build on this have compared to one another. What differentiates a company building on this from another company building on the same API? It seems like the execution would differentiate them the most? I feel like I am missing something here. Could someone enlighten me?

Re: Griffin – A fully-regulated, API-driven bank, with Clojure

#219

Post by n42 »

anentropic wrote: post #214
n42 wrote: post #205

Earlier quoted context omitted.

where in the article does it say they built their own database?

it said they built a Datomic-like db on top of FoundationDB sounds pretty cool, but was it really necessary...?

that's just how FoundationDB is architected; it's not quite the same as building your own DB. the database provides primitives that are safe to build abstractions like this on top of.

it's also not quite the same as using an off-the-shelf RDBMS, but they do a pretty good job of explaining why they made that design choice.

if anything, viewed through that lens, I'd say it seems quite pragmatic.

Re: Griffin – A fully-regulated, API-driven bank, with Clojure

#220

Post by n42 »

weird-eye-issue wrote: post #212
n42 wrote: post #202

Earlier quoted context omitted.

exactly this. I see it as this: over or under engineering can basically be boiled down to requirements and budget (which is itself a requirement, but many engineers don't seem to see it that way). over engineering is anticipating for future requirements that aren't ever realized, or realized so far in the future that upfront cost outweighed the cost of putting it off for later. under engineering is not anticipating f…

I feel bad for you. It must be tough living in such a black and white world :(

since you've resorted to grade school bullying, it's clear my point is beyond you, so I'll meet you at your level:

calling something over engineering reduces the problem to black and white thinking, which is incredibly uninteresting. let's not do that!

wow, I guess we agree, and you're still an asshole!

Post reply on HN