a) Ubiquity — everything understands HTTP. Erlang nodes only talk to Erlang (or a compatible runtime)

b) Because there are no middleware standards (REST, GraphQL, OAuth, etc.), you must build or integrate your own abstractions

c) Giving up infrastructure (reverse proxies, load balancers, CDNs), You handle distribution yourself or through OTP design

d) Interoperability with browsers and APIs, requiring bridging via something like Cowboy or gRPC gateway

setcookie secret in Erlang does not create or use an HTTP cookie, SSL certificate, or HTTPS connection. It sets the Erlang distribution cookie, a shared secret string used for node authentication within the Erlang runtime system (the BEAM VM).

Erlang’s built-in distributed networking subsystem allows them to connect to each other if:

1) They can reach each other over TCP (default port 4369 for the EPMD — Erlang Port Mapper Daemon — plus a dynamically assigned port for the node-to-node connection).

2) They share the same cookie value (here "secret").

The author's insight "No HTTP. No REST API", reframes the reality that Erlang moves things down the ISO OSI model - HTTP being on layer 7 and TCP being on layer 4. Erlang therefore misses the "benefits" of operating on a higher ISO layer, but gains powerful advantages of operating on layer 4:

i) True concurrency

ii) Transparent message passing

iii) Fault tolerance

iv) Soft real-time guarantees

v) Persistent cluster connections

Erlang’s design assumes a trusted, closed system of cooperating nodes, not a public Internet of clients. In other words, Erlang doesn’t live below Layer 7 — it IS its own Layer 7.

His PhD thesis explains the thinking behind Erlang, especially how it handles failures, message passing, and concurrency. It was last updated in 2003, 22 years ago, time really flies!

I'm still more of a infrastructure guy than a software developer, but working with such incredibly smart people was a delight. Basho was good at hiring people who could learn Erlang (and, perhaps unsurprisingly, was almost entirely remote).

[0]: https://pragprog.com/titles/btlang/seven-languages-in-seven-...

Erlang gets a lot of stuff right for scalable web based stuff, and even though there are many of its influences that have by now made it into other languages and eco systems it is still amazing to me that such a well thought out system is run with such incredible modesty. You'll never see the people behind Erlang be confrontational or evangelists, they just do what they're good at and it is up to you whether you adopt it or not. And that is an interesting thing: the people that are good at this are writing code, not evangelizing. If I had to reboot my career I'd pick this eco system over anything else, it has incredible staying power, handles backwards compatibility issues with grace and has a community that you can be proud of joining. Modest, competent, and with a complete lack of drama.

That said, the metaphors are so elegant, the key concepts so well chosen -- yes, the initial onramp may be a cognitive slog, but it's well worth it. It makes everything downstream so much easier.

That's really interesting... My wife, who has no real mathematical background had the EXACT same reaction when I was trying to teach her some simple programming. I tried to explain that equals in that context was more of a storage operator than a statement that said line is true. She found it very frustrating and we gave up on the endeavor shortly thereafter.

I've personally always had a soft spot for languages like TI-BASIC that use a storage operator rather than overloading = so for example:

X + 1 -> X

I wonder if I should try a functional language with her.

Sum = n(n+1)/2

It's colourful language, but it's just a stand-in for other properties you might care about. For instance, in head(sort(list)), will the whole list be sorted, or will the smallest element be returned? In atomically(doThis(); doThat()), will doThis be 100% reverted if doThat fails? If you stick to pure functions (and in the second example, STM) then you can unfire the missile!

AFAIK, Erlang just fires the missile "over there", not "over here". The author jumped from:

  (X = X + 1) is bad

  (mailbox = mailbox + message) is so simple!

My current stack is Elixir + Rustler on server and Rust + Wasm at frontend. Thanks for reading :)

The multiprocess stuff is cool too, but a premature optimization for what I was doing. If I needed to scale, I don't know if that'd be the chosen approach.

Wait, is there something I don’t actually understand about recursion? When a recursive function calls itself, is that not a loop?

It is declaring a relationship, between the previous value and the current. One way or another, youre defining transformations.

I mean even in the sum example, you see the statement "N is n-1" which is the exact same thing as x = x+1 with = swapped for "is"

I have a toy replacement for syslog.

i supervised an LLM writing a discord-esq chat program that implemented a imaginary JMAP extension called 'JCHAT'.

i had the LLM write a Erlang based dimensional accounting system

So far in real life i don't have any uses, which is a shame because it's a great language and OTP comes so batteries included I can think of many use cases.

  -module(ping).
  -export([start/0, ping/1]).

  start() ->
      register(ping, spawn(fun() -> ping(0) end)).

  ping(Count) ->
      receive
          {pong, Pong_PID} ->
              io:format("Ping received pong (~p)~n", [Count]),
              Pong_PID ! {ping, self()},
              ping(Count + 1)
      end.

Not sure if you want to call it a screwup or bad grammar or whatnot, but it is perhaps the huge mistake that the "equals" sign was used for something that feels like, but emphatically DOES NOT mean, "is equal to."

It's "put this into that". It's an action verb. Should have perhaps insisted on x <- x + 1 or maybe better x + 1 -> x

I must go dig up the Erlang book from my library. As I recall, it was a great read.

And they were right, rebranding was all Erlang needed 13 years ago

EDIT: there is Lumen, but not sure if it's stalled or still going.