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

201–210 of 223 posts

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

#201

Post by rkhacker »

>If you had a database and some separate messaging like ZeroMQ, Rabbit, Kafka, you’re going to get race conditions. There’s always going to be a potential race where you have two messages - one is going to the disk and one is going to the network. If someone else is listening and sees both of them, they could potentially get them in either order. So it’s much, much simpler to just have one path. Foundation is really fast, so it works great.

Having difficulty parsing this justification. How will a client code listening to an event get two events - one from network, and one from disk in case of any of the queuing systems mentioned here? I am also curious to know how the FoundationDB act like a messaging system apart more than a message store?

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

#202

Post by n42 »

danpalmer wrote: post #139
weird-eye-issue wrote: post #116

Earlier quoted context omitted.

You don't have to choose between under and over engineering

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 for future requirements that are realized before their cost outweighs the cost it would have taken to implement them upfront. somewhere there is a line, and on both sides you wasted money. if you perfectly engineered something, you spent the money optimally. in this industry, the idea you could perfect that is laughable. it's either over, or under engineered.

reading a blog post gives you fuck-all for insight into a project or team's actual budget and requirements. driving by and shouting "over engineered" is a very clear sign of lack of experience, and one of the most uninteresting things you can add to a conversation about a company _literally starting their own bank from nothing_.

so, OP, how would you under engineer your bank?

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

#203

Post by n42 »

rkhacker wrote: post #201

>If you had a database and some separate messaging like ZeroMQ, Rabbit, Kafka, you’re going to get race conditions. There’s always going to be a potential race where you have two messages - one is going to the disk and one is going to the network. If someone else is listening and sees both of them, they could potentially get them in either order. So it’s much, much simpler to just have one path. Foundation is really…

I think he's talking about how with FoundationDB, pub/sub notifications ("watches") are transactional – the notification is only sent if the transaction succeeds. because FoundationDB can guarantee transactions across multiple key writes, you can write your state at the same time you write an event/message/job somewhere else, in one transaction, with the subscriber only being notified on success. I think this is impossible(?) to achieve without the message queue and data store being the same service.

otherwise, you have a transaction to write to your database and a separate call to the message queue, which introduces the race condition.

https://apple.github.io/foundationdb/features.html#watches

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

#204

Post by blibble »

yakshaving_jgt wrote: post #200
blibble wrote: post #199

Earlier quoted context omitted.

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.

> I'm not here to engage in flamewars

-> ends previous comment in an ad-hominem

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

#205

Post by n42 »

anentropic wrote: post #163
n42 wrote: post #89

Earlier quoted context omitted.

how would you under engineer your bank?

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?

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

#206

Post by tacker2000 »

devgoth wrote: post #107
ano88888 wrote: post #100

which is a better or more productive language? Clojure or Elixir for web development?

I would argue that Elixir is due to Phoenix being a "batteries included" web framework....but as always: use the right tool for the job.

What does “batteries-included” mean? Except more buzzwords?

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

#207

Post by dustingetz »

kiitos wrote: post #190
dustingetz wrote: post #81

Earlier quoted context omitted.

never say never, i think maybe can be done with modifications to missionary, a structured concurrency dsl implementing process supervision for clojure/script. we already instrument missionary flows for testing missionary itself (asserting its state transitions)

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

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

#208

Post by lmm »

theonething wrote: post #133
lmm wrote: post #96

Earlier quoted context omitted.

> Classic "logic" stuff. Forgetting to modify and return a map given some other information. Accidentally returning the inverse of a boolean (i.e. !isSomething(x) vs isSomething(x)), incorrect adds or bit shifts If something really is just a map or a boolean or an integer then you can't avoid this kind of thing. But usually it isn't, it's something meaningful in your domain, and then you can make and enforce the righ…

> If something really is just a map or a boolean or an integer then you can't avoid this kind of thing. But usually it isn't, No matter how much you abstract out and dress up a boolean, at its heart it's still a boolean value and I don't see how making a custom type based on boolean would prevent returning the inverse of a boolean value bug.

Most of the time a "boolean" isn't a boolean - it's a flag to indicate one of two different things, which is something you can represent more directly.

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

#209

Post by lmm »

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…

Quips are not a good basis for decision-making. Immutability is valuable but there is no conflict between immutability and types; you should use both. As for "bugs found in the field", having switched to Scala I pretty much don't encounter them.

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

#210

Post by jwr »

yakshaving_jgt wrote: post #149
jwr wrote: post #78

Earlier quoted context omitted.

Of course it's an opinion. Anytime somebody says something, it's his/her opinion. My opinion, for example, is that I agree with his opinion :-) My solo-founder business would not have been possible without Clojure and ClojureScript, which is a testament to the "power" of this language. I consider it "powerful", because it lets a single developer write and maintain a complex app over the years. It gives me power.

> My solo-founder business would not have been possible without Clojure and ClojureScript …Really? Why?

Because I would have to write much more code, and likely not in a single language. More code = more bugs and more maintenance overhead.

Larger companies can afford this, in exchange for "average programmer accessibility". I can't.

Post reply on HN