Hacker News Reader

Comment by bobthechef | Hacker News Reader

Why has this been upvoted? The author is a novice and provides no insight. This just reads like he finally got to the second page of your standard book on functional programming and somehow came to believe that everyone else is still on page one. What village is this guy from?

View on HN

> What village is this guy from?

I know this thread is about functional programming and so condescension is the norm, but isn't it about time we change that part of our culture a bit?

You offer significantly fewer insights than the OP. Zero arguments, just name calling. The author reads this thread and is a real person. Are you proud?

I, for one, found the article an insightful articulation of things I kinda sorta already knew but hadn't acted on. Also our team is in the middle of building an Elixir backend with a classically designed mutable DB so the article helps me reflect. Maybe now is the better time to change this.

Elixir has more to offer than just a functional approach; there is OTP, lightweight processes, etc. If these are things you need, Elixir might still be an excellent choice.

I meant that I'm now considering changing the thing the article is about: using immutable data in the database and considering any mutable parts of it a cache, in a sense. Basically he's describing CQRS but not using the term.

Moving off of Elixir certainly isn't being considered :-) We chose it particularly for its concurrency and robustness features, which are important to us (we're a messaging component for marketplace/platform sites so deliverability and concurrency are very high on the list). We'd have picked Erlang if Elixir didn't exist.

I am indeed describing CQRS, or at least the way I see it. The way I am doing is this by making my read side a combination of lightweight "code-only" domain models and heavy db-side indexing of events themselves (as opposed to domain model tables of some sort)

If you have any thoughts or questions, feel free to reach out to me (my nickname is the same almost anywhere, twitter, gmail, etc.) or Eventsourcing gitter room http://gitter.im/eventsourcing/eventsourcing and I'll be happy to talk about these things.

I liked Elixir, other than it wasn't statically typed, but I found the ecosystem quite young which means you will have to spend a bunch of time purely keeping your code up to date with libraries as they change and if your tech integration doesn't exist, you are on your own.

After a bit of consideration, I figured F# makes more sense for me. It has a large ecosystem covering many technologies, its all moving to open source / any platform. It also has lightweight processes, and lots of tooling.

I agree that there's little point in using Elixir currently if you don't need its concurrency/robustness story.

Probably because event-sourcing is beginning to trend.

The article is not that interesting in itself, but the conclusion is a good starting point for a conversation that may be.

> Systems are largely not functional. But they can be.

So, how?

My research into this topic has led me to lazy event sourcing so far https://blog.eventsourcing.com/lazy-event-sourcing-ed7e59007...

My current view is that by eliminating or reducing the need to serialize domain objects, we're creating a system which is easier to argue about and provides an easy way to adjust domain models as the understanding or circumstances evolve.

Yeah, now this is a nice continuation to the conversation :)

I too have been mildly obsessed with the kind of thinking you're developing in your post - very nice article!

I've been very attracted to event-sourcing since I realized that now that React and redux have mostly solved the UI problem what remains to be solved is the problem of how to store our beautiful event-driven data.

EDIT: re-read your comment, felt the need to say that your "current view" is exactly mine too

I am happy to continue this conversation off-HN, perhaps Gitter? http://gitter.im/eventsourcing/eventsourcing

Reply on news.ycombinator.com