The Isolation Trap: Erlang

johnisgood 15 minutes ago | parent | next [-]

> This isn’t obviously wrong

I thought it was obviously wrong. Server A calls Server B, and Server B calls server A. In what way is it not wrong? Because when I read the code my first thought was that it is circular. Is it really not obvious? Am I losing my mind?

> Not one is enforced by the language or the compiler, [...]. Every mitigation depends on the programmer doing the right thing.

If you enforce it through the language / compiler, do you not lose flexibility and expressiveness?

	▲	bluGill 6 minutes ago \| parent [-]
		It is too common / useful. Not everything is a tree.

▲

lukeasrodgers an hour ago | parent | prev | next [-]

I don’t have much experience with pony but it seems like it addresses the core concerns in this article by design https://www.ponylang.io/discover/why-pony/. I wish it were more popular.

▲

aeonfox 2 hours ago | parent | prev | next [-]

A real interesting read as someone who spends a bit of time with Elixir. Wasn't aware of the atomic and counter Erlang features that break isolation.

Though they do say that race conditions are purely mitigated by discipline at design time, but then mention race conditions found via static analysis:

> Maria Christakis and Konstantinos Sagonas built a static race detector for Erlang and integrated it into Dialyzer, Erlang’s standard static analysis tool. They ran it against OTP’s own libraries, which are heavily tested and widely deployed.

> They found previously unknown race conditions. Not in obscure corners of the codebase. Not in exotic edge cases. In the kind of code that every Erlang application depends on, code that had been running in production for years.

I imagine that the 4th issue of protocol violation could possibly be mitigated by a typesafe abstracted language like Gleam (or Elixir when types are fully implemented)

▲

WJW an hour ago | parent | next [-]

If these race conditions are in code that has been in production for years and yet the race conditions are "previously unknown", that does suggest to me that it is in practice quite hard to trigger these race conditions. Bugs that happen regularly in prod (and maybe I'm biased, but especially bugs that happen to erlang systems in prod) tend to get fixed.

	▲	thesz 8 minutes ago \| parent \| next [-]
		Erlang has "die and be restarted" philosophy towards process failures, so these "bugs that happen to erlang systems in prod" may not be fixed at all, if they are rare enough.
	▲	aeonfox an hour ago \| parent \| prev [-]
		True. And that the subtle bugs were then picked up by static analysis makes the safety proposition of Erlang even better. > Bugs that happen regularly in prod It depends on how regular and reproducible they are. Timing bugs are notoriously difficult to pin down. Pair that with let-it-crash philosophy, and it's maybe not worth tracking down. OTOH, Erlang has been used for critical systems for a very long time – plenty long enough for such bugs to be tracked down if they posed real problems in practice.

▲

kamma4434 an hour ago | parent | prev [-]

The 4th issue is a feature- it’s what allows zero downtime hot updates.

▲

cyberpunk 2 hours ago | parent | prev | next [-]

Eh maybe. I work on a big, mature, production erlang system which has millions of processes per cluster and while the author is right in theory, these are quite extreme edge cases and i’ve never tripped over them.

Sure, if you design a shit system that depends on ETS for shares state there are dangers, so maybe don’t do that?

I’d still rather be writing this system in erlang than in another language, where the footguns are bigger.

▲

anonymous_user9 2 hours ago | parent | prev [-]

This seems interesting, but the sheer density of LLM-isms make it hard to get through.

	▲	boxed 28 minutes ago \| parent [-]
		I think at this point comments like this are equivalent to saying "I didn't like this article, because it's written in too good English".