
Anatomy of a Haskell-Based Application, Revisited - kornakiewicz
https://tech-blog.capital-match.com/posts/3-anatomy-of-haskell-web-app.html
======
vemv
Ace read.

Technical considerations aside I'd love to read about the domain-specific
advantages that choosing Haskell resulted in, particularly when Capital Match
is playing in a quite crowded sector (p2p lending / invoice financing).

I have heard of similar fintechs written in e.g. Ruby that are open to white-
labeling their product for other countries. So non-differentiation from
cheaper alternatives can be a risk.

------
kccqzy
Author here. Didn’t expect this to be on the front page of HN. I have a flight
to catch but I can answer questions.

~~~
ubercow
Hey!

I'm mostly curious about the details behind the flat-file persistence. Is the
storage on the same physical machine as the API and Business Logic? If not how
is communication done? How do you handle horizontal scalability for either
perf or HA reasons?

~~~
kccqzy
Hi! That’s actually a good question, an aspect that I basically avoided in the
article. Truth be told, we aren’t happy with the way things are, but indeed
the storage is on the same physical machine (in fact a shared docker volume)
as everything else. We have a read-only replica that we use sometimes to
execute slow queries.

However, the vision is that eventually we would use Raft or other kinds of
consensus on top of the current layer of storage. Event sourcing supposedly
should make this kind of replication easy because data is always append-only.
Unfortunately the reality of a startup is that we often have to do things
quickly and this aspect has been neglected for pretty long.

------
Bob2019
Tried to explain functional programming (in C# because it's a real world job)
to a colleague. It's surprisingly difficult to sell benefits of purity and
immutability if the there is no threading going on. Much as I hate JavaScript
at least those who touch React educate themselves in right concepts (even if
they start using funny non-standard CQRS terminology).

~~~
bunderbunder
It really shouldn't be that hard.

The real benefit of purity and immutability is managing complexity. People
focus way too much on threading, which is a buzzword. As ever, the buzzwordy
version of an otherwise good idea is never all it's cracked up to be.

It's all down to context boundaries:

\- With a pure function, you can completely understand its behavior by reading
just that function's code, and possibly also the code of any other functions
it calls.

\- With a method that relies on mutable variables, you have to understand not
only that method, but also every other method that mutates the variable, and
possibly all the code that has a reference to that object.

In the second case, you've potentially got a _much_ wider scope to understand.
Almost as wide a scope as you need to understand when global variables are in
use. Worse, it's now possible to change that method's behavior without
touching any of that method's actual code. It's even possible that you could
change it without touching the file that contains it.

In a nutshell, the real benefit of purity and immutability is that it
eliminates "spooky action at a distance" type behaviors, and all the
intractability that tends to come with them.

------
cpursley
Seems like Elm would be a good choice for a more Haskell-y UI solution.

