Hacker News Reader

Comment by jacquesm | Hacker News Reader

Recent encounter: 70+ microservices for a minor ecommerce application. Total madness and while I'm all for approaching things in a modular way if you really want to mimic Erlang/BEAM/OTP just switch platforms rather than to re-invent the wheel. In Erlang it would make perfect sense to have a small component be a service all by itself with a supervision tree to ensure that all components are up and running.

View on HN

Erlang/OTP and Elixir on top of that, brings more than 30 years of experience of building Reliable, Scalable and High Available Systems.

It's difficult to fight this.

Somebody new to Erlang can get a feel of what Systems Architecture in Erlang really means from a great article by Fred Hebert:

"The Hitchhiker's Guide to the Unexpected" https://ferd.ca/the-hitchhiker-s-guide-to-the-unexpected.htm...

I'm always curious why the Actor concept isn't more widely used. Many platforms / languages have some form of it.

I have no idea either, though the simplicity may be off-putting and might make people feel stupid for making it so overly complex.

It seems like a near perfect fit for the web.

This is why WhatsApp managed a $19B exit with only 50 engineers, while so few others have managed it.

Apps like WhatsApp/Insta have relatively small feature-sets. I doubt you can pin their success on their tech-stack. It's more like they aggressively avoided feature creep.

I'm equally curious about flow-based programming. Treating things as filters has worked well for the Unix command line. There's no reason we can't have processes do sort, filter, merge, lookup, and such in well-defined ways and chain them together as needed for many kinds of applications. Although "network" and "port" mean something particular within FBP it doesn't at all mean the processes can't be on different machines and talking via TCP/IP.

There is an interesting equivalence between pure functional programming flow based programming and the actor model.

There is a lot of fancy theory to underpin this equivalence, the essence is that all of them revolve around (side effect free) transformation.

I don't know Erlang and I'm only a couple of months in to learning Elixir in my (limited) free time. Grated, it's not purely functional, but... I've been reflecting on this exact equivalence, as you put it, and am happy to hear that my inclination about the Actor model isn't unfounded.

Ugh, I'm trying to create something like this.

The nodes are fine and easy, but the orchestration / flow implementation is getting me stuck for > 1 month... :(

In Erlang it makes perfect sense to have a single counter variable be a gen_server by itself and be part of a supervision hierarchy. Deploying and versioning that counter separately will still correctly get laughed at.

Reply on news.ycombinator.com