top | item 44282536

(no title)

kybishop | 8 months ago

Very true it is actually designed for telecoms, but like you mentioned the distinction is so small it's not really even a stretch to say it is purpose built with at least the general architecture of web in mind.

discuss

order

demosthanos|8 months ago

In the grand scheme of things, if we're considering everything from web to bridge building, yeah, the distinction is small. But within the world of software engineering specifically it's not all that small and it's worth being precise when we're talking about it.

Whatsapp and telecoms have a lot in common, so no one questions that they benefited a ton from the BEAM.

Airbnb, though? The main similarity is that they both send large quantities of signal over wires.

Again, none of this is to stop you from liking the BEAM, but when we're talking about professional software engineering it pays to be explicit about what the design constraints were for the products that you're using so that you can make sure that your own design constraints are not in conflict with theirs.

throwawaymaths|8 months ago

no. in the modern web world you often have persistent client server connections, which make it a distributed system out the gate. the most inefficient way to deal with this is to go stateless, and without smart architecture to deal with unreliable connection, it's really your best choice (and, it's fine).

since BEAM gives you smart disconnection handling, web stuff built in elixir gives you the ability to build on client-server distributed without too much headache and with good defaults.

but look, if you want a concrete example of why this sucks. how much do you hate it when you push changes to your PR on github and the CI checks on browser tab are still not updated with the new CI that has been triggered? you've got to refresh first.

if they had built github in elixir instead of ruby would almost certainly have this sync isdur solved. in maybe two or three lines of code.