I was in the middle of a conversation with a friend the other week and we started debating some data access nonsense. This friend (whom shall remain anonymous) asked me a simple question:
Before I get to the meat of this post, the code for what I've written so far is up here. The main bits are in
Migrations are a simple mechanism whereby you script out some change commands for your ORM, and that ORM then builds your database for you. To me, this is pure insanity. I dislike ORMs (accept, of course, for LLBLGenPro, which is astoundingly good). Trusting your ORM to build a proper database is ... kind of weird to me. SQL is terser, more expressive and (as it turns out) just right for the job.
Let's implement an intelligent shopping cart - something that tracks what the customer is doing, how they came to our store, etc. I tend to think of these things in terms of a "Session" - a shopping process where a customer selects things, puts them back, and eventually (hopefully) buys something. If I do things correctly (to me, at least), I should end up with tight little functions an exactly 0 if statements.
When you build applications in the Erlang world you create discrete processes that interact. In theory this is pretty straightforward - until you actually try to do it. Microservices fans out there know the value (and the pain) of managing a fleet of services; there are benefits to it, definitely, and also problems.
As CTO I get to call the shots here at Red:4 but I do have to answer to the CEO and others. It's easy to arm-wave, to go on and on about Elixir and functional languages - but at the end of the day it's what you do, not what you say that counts.