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

191–200 of 223 posts

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

#191

Post by ilkhan4 »

mvc wrote: post #161
ilkhan4 wrote: post #59

Earlier quoted context omitted.

I wish people would stop bringing up Nubank when it comes to Clojure/FP as if it's some sort of mic drop that proves that it's the Right Way to develop financial software. When you have to keep bringing up the same example, it's not a very good argument.

There are always going to be niche langauges and mainstream languages, and as a result, users of niche languages will always have to "justify" their use of such. To investors, to potential new users, to potential colleauges. They're not having a bash at $your_favorite_langauge. Or suggesting that nubank couldn't have been built on any other platform. They are simply responding to the oft-stated question "are there an…

Sure, I get that they have to justify themselves, but when the answer to that question is (almost) always "Because Nubank!" for the past 10 years it doesn't feel like much of a justification.

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

#192

Post by kemotep »

hanniabu wrote: post #184
kemotep wrote: post #179

Earlier quoted context omitted.

One can be anti-extrajudicial government powers and anti-cryptocurrency. For one, I believe cryptocurrencies will be the government spyware of the future that allows for total control over our finances, since crypto evangelists push “code is law” and the blockchain is immutable and completely transparent. There will be no privacy in such a system. We could spend our efforts making the current financial system be priv…

As I said in an earlier tweet, private transactions are possible

The solution to, the government is extrajudicially spying on our transactions and without due process blocking people from their finances, is not a system that uses an immutable public ledger. It’s reforming the law to protect people’s right to privacy and due process.

Ignoring solving the problem of the government not respecting people’s right to privacy and due process is not acceptable to me in my opinion. Saying Ethereum has private transactions isn’t any different than telling someone whose bank account was frozen without due process that they should just use cash.

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

#193

Post by rkeene2 »

sachin9 wrote: post #142
rkeene2 wrote: post #111

Earlier quoted context omitted.

I have a bit more information than you on the topic. We provide bank accounts, this includes checking and savings in the US.

Can people from other countries opt for this bank account?

Hi. The short answer is no.

The way our system works, the legal address of the end-user determines which bank the bank account is within -- this is largely due to regulatory requirements within the various banking systems.

There is one mechanism by which this could potentially be done from my understanding, but it will take us a few years to fully explore and integrate into that kind of model.

Another model we explored (but again, do not implement) is that instead of holding end-user funds in FDIC-insured bank accounts (in the US -- bank accounts in other countries are not FDIC insured) is treating the funds as a security backed against deposits, which is significantly different, but could make non-US users able to open US-based accounts, but they would not at that point be bank accounts.

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

#194

Post by yladiz »

fnordsensei wrote: post #189
yladiz wrote: post #170

Serious question, and I apologize for the strong language: why should I give a shit about the language a service I consume is written in? Why does it matter it’s in Clojure? I am professionally a Clojure dev so it’s cool to see something written in Clojure like this, but why should I care about that? This is one of the things I really dislike about the community. Yes, Clojure is a powerful language, and I really enjo…

This is a blog post by one Clojure company, interviewing another Clojure company, with a tech stack focus. It’s not unusual within any language stack to have these kinds of blog posts - they’re obviously by and for people who find the technology interesting. I don’t get your point. Is this somehow not appropriate behavior amongst civilized society? Your remark comes across as not a little bit ignorant. Maybe you shou…

I think you misunderstand my point. I will admit that it was vitriolic, somewhat intentionally so, and conflated my general annoyance at posts that seem to virtue signal about the language they're using for their product, and this happening specifically in the Clojure community, but my point is not that it's inappropriate and I don't think I come across as ignorant here and so I disagree with that characterization. I also don't think it's fair to say I should just, paraphrasing, "sit down and shut up" if I have some criticism, because, taken further, it's a way to just dismiss criticism as negative even if it is constructive.

To be clearer, my point is two fold:

1. Why should I care about the language that a specific service is written in, be it Clojure, Rust, TypeScript, etc.? As a language user it's cool, but as a buyer (which, of course is not the target audience of this blog post) I don't think it matters the language as long as the product works well. For a bank, I couldn't care less if it's written in COBOL, Java, JavaScript, Piet, as long as my money is safe and transactions are handled correctly. 2. It feels like there are a lot of Clojure posts that go into the territory of putting Clojure on a pedestal, making it out to be the best language, etc. when in reality it is a tool, which excels at a lot of good tasks, but not every task, and while I may be biased it sometimes feels like the community needs to justify the existence of the language, that there's some kind of imposter syndrome. Maybe I would be less annoyed about this if I saw many/any posts about the pitfalls and difficulties of using Clojure.

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

#195

Post by bnert »

_dain_ wrote: post #165
bnert wrote: post #79

Earlier quoted context omitted.

> Types validate whatever you use them to validate, which can certainly include what we usually call "logic". I'd love an example of this! I concede that I could be wrong on the point's of ML/Haskell families, however, it relies on the practitioner correctly using the type system to the extreme (at least, that is my impression). C++ and other similar OO's, the type system isn't as compelling as a correctness measure.…

Are you familiar with the idea of "making illegal states unrepresentable", and "parse, don't validate"? https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va... You brought up the examples of doing the wrong thing with booleans. With a good type system you can cut down on needing to use booleans in the first place for a lot of things. Your isSomething(x) example is a good one: presumably some code after this i…

> Are you familiar with the idea of "making illegal states unrepresentable", and "parse, don't validate"?

I haven't heard of those concepts/ideas before. Thanks for linking the article to define those concepts. With your example, and the article mentioning that "parsing should take place at the boundaries" (paraphrase), I can see how types (a la ML families) can be defined and composed give internal coherence once an external input has been parsed and hence validated.

Really interesting approach which I haven't considered before!

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

#196

Post by bnert »

Jach wrote: post #164
lmm wrote: post #60

Earlier quoted context omitted.

> In OO languages (Java, C#, C++, etc...), and functional ones (F#, Haskell, OCaml, etc...) types do not validate the correctness of logic, they evaluate the correctness of data structures and their access/mutation as they are manifested in the language. Nonsense. Types validate whatever you use them to validate, which can certainly include what we usually call "logic". > Types have little (or nothing) to do with pro…

Agree that you can use types to express and prove logical properties via compiler; it can be a fun way to solve a problem though too much of it tends to frustrate coworkers in JavaLand. It's also not exactly "low cost"; here's an old quip I have in my quotes file: "With Scala you feel smart having just got something to work in a beautiful way but when you look around the room to tell your clojure colleague how clever…

Your point about underlying data structures is spot on, in my view.

> Last quip to reflect on. "What's true of every bug found in the field? ... It passed the type checker. ... It passed all the tests. Okay. So now what do you do? Right? I think we're in this world I'd like to call guardrail programming. Right? It's really sad. We're like: I can make change because I have tests. Who does that? Who drives their car around banging against the guardrail saying, "Whoa! I'm glad I've got these guardrails because I'd never make it to the show on time."

I've been avoiding bringing up this point/example, but this is what prompted me to start thinking more deeply about types and their tradeoffs. Great talk, IMO.

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

#197

Post by _dain_ »

bnert wrote: post #195
_dain_ wrote: post #165

Earlier quoted context omitted.

Are you familiar with the idea of "making illegal states unrepresentable", and "parse, don't validate"? https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va... You brought up the examples of doing the wrong thing with booleans. With a good type system you can cut down on needing to use booleans in the first place for a lot of things. Your isSomething(x) example is a good one: presumably some code after this i…

> Are you familiar with the idea of "making illegal states unrepresentable", and "parse, don't validate"? I haven't heard of those concepts/ideas before. Thanks for linking the article to define those concepts. With your example, and the article mentioning that "parsing should take place at the boundaries" (paraphrase), I can see how types (a la ML families) can be defined and composed give internal coherence once an…

Glad I could help!

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

#198

Post by orra »

blibble wrote: post #141
sumek83 wrote: post #129

Earlier quoted context omitted.

https://en.wikipedia.org/wiki/Single_Euro_Payments_Area

yes, the EU launched a separate instant payment scheme a decade later doesn't mean the EU had anything to do with the UK's domestic faster payments scheme (SEPA is also euro only)

I was thinking of PSD (the original one), but it turns out that only required end of next business day settlement.

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

#199

Post by blibble »

yakshaving_jgt wrote: post #156
blibble wrote: post #147

Earlier quoted context omitted.

the UK had contactless transactions, free instant payments and mobile banking years before PSD2 (the mostly useless open banking stuff is however due to PSD2)

That appears to be a red herring. In the article, Griffin is described as: > Their services allow Fintech businesses to integrate banking features quickly and securely. So this is about integration with other FinTech businesses, which I think squarely falls under open banking and PSD2. I'm not sure why you describe PSD2 as "mostly useless". Did you vote for Brexit by any chance?

you should prefix all of your posts with "I don't really know much about this topic, but here are my opinions regardless."

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

#200

Post by yakshaving_jgt »

blibble wrote: post #199
yakshaving_jgt wrote: post #156

Earlier quoted context omitted.

That appears to be a red herring. In the article, Griffin is described as: > Their services allow Fintech businesses to integrate banking features quickly and securely. So this is about integration with other FinTech businesses, which I think squarely falls under open banking and PSD2. I'm not sure why you describe PSD2 as "mostly useless". Did you vote for Brexit by any chance?

you should prefix all of your posts with "I don't really know much about this topic, but here are my opinions regardless."

Wow. You really went through my recent comments to come up with this sick burn.

That's sad.

I'm not here to engage in flamewars, so let's just leave this here.

Post reply on HN