Comment by hosh | Hacker News Reader

Comment by hosh | Hacker News Reader

Parent Full thread

It is not so black and white.

The BEAM ecosystem (Erlang, Elixir, Gleam, etc) can do distributed microservices within a monolith.

A single monolith can be deployed in different ways to handle different scalability requirements. For example, a distinct set of pods responding to endpoints for reports, another set for just websocket connections, and the remaining ones for the rest of the endpoints. Those can be independently scaled but released on the same cadence.

There was a long form article I once read that reasoned through this. Given M number of code sources, there are N number of deployables. It is the delivery system’s job to transform M -> N. M is based on how the engineering team(s) work on code, whether that is a monorepo, multiple repos, shared libraries, etc. N is what makes sense operationally . By making it the delivery system’s job to transform M -> N, then you can decouple M and N. I don’t remember the title of that article anymore. (Maybe someone on the internet remembers).

> The BEAM ecosystem (Erlang, Elixir, Gleam, etc) can do distributed microservices within a monolith.

This ain't new. Any language supporting loading modules can give you the organization benefit of microservices (if you consider it a benefit that is - very few orgs actually benefit from the separation) while operating like a monolith. Java could do it 20+ years ago, just upload your .WAR files to an application server.

> Java could do it 20+ years ago, just upload your .WAR files to an application server.

Erlang could do it almost 40 years ago.

It can be used to upgrade applications at runtime without stopping the service. That works well in Erlang, it’s designed from the ground up for it. I know of a few places that used that feature.

Erlang seems like a joy to use. I feel a slight pang of regret that I haven't (yet) gotten to use it in my career. (I don't quite have the time or energy to play with it during my off hours, but it is on my list for someday.)

You might give Gleam [0] a try, which is advertised as "language you can learn in a day". It is type-safe, supports the BEAM and you can easily invoke Erlang and Elixir. Compiles to Erlang or Javascript.

[0] https://gleam.run/

This looks delightful! Thanks for the recommendation!

This is kind of why I've never bothered to look at it - everyone /says/ it's a wonderful thing, but... nobody uses it in production, or hobbies (apart from the diehard fans)

It might see the light of day at some point in the future, but if the past is anything to go by...

I have worked in production Elixir. (Learning platform supporting realtime student-teacher classroom experience).

Whatsapp is implemented with Erlang.

It is a more robust platform for agentic AI, and I’d certainly start with a BEAM language for agentic AI.

Well the canonical example is WhatsApp, but there are loads of other success stories if you care to look.

Small teams, big results is a characteristic that I’m very interested in, in our post-ZIRP reality.

I'm familiar with Whatsapp and its relationship with erlang (there's RabbitMQ as well, which I always forget when asked..)

But they're the only real case studies

If I were to say "Go", people can point to big projects like Docker, Kubernetes, etcd, Googles internal use, and a few others (Uber?)

Erlang just doesn't have that sort of buy in, which is concerning because it's been around longer than Go (as a FOSS language), heck it's been around longer than Python (but it was proprietary back then)

Speaking as someone that's never used it, that's got "don't bother unless you've got an academic interest in it" written all over it

The ideas in Erlang keeps getting (poorly) reinvented.

So it remains a “secret” weapon and I am fine with that. Not everything have to be validated by popularity in order to be unreasonably effective.

Sounds like haskell.

What BEAM offers isn’t modularity, but concurrency. Every genserver is operating concurrently, all within the runtime. Up until actor models came to Java, and more recent Java with lightweight threads, Java was incapable of this. Java is still missing things that BEAM and OTP provides.

Besides: Erlang predates Java.

I mean sure but one could also argue that VB6 can do the same analogue of Java so long as ASP is involved... And yes I've seen it done; you have a basic interface similar to an actor, but really more like a 'Take a key-value in for input, do processing on it, return a key-value to go to the next stage' and then the other necessary glue to handle that. The way the glue worked, it was minimal ceremony to get a new module in.

NGL It was clever enough that every few years I think about trying to redo the concept in another language....

Yup, good point on the BEAM. The joke we used when microservices were hot was that the BEAM is already ahead with nano-services: a gen_server is a nice lightweight, isolated process. You can define a callback API wrapper for it and deploy millions of them on a cluster.

Yeah, the isolation provides a fault tolerance not seen in wide use until Kubernetes.

Although it would be neat to implement some of the benefits of a service mesh for BEAM — for example, consistently applying network retry/circuit breaker policies, or dynamically scalable genservers.

Reply on news.ycombinator.com