Comment by demosthanos

Comment by demosthanos a day ago

> is actually designed from the ground up for web dev (being based on the Erlang VM)

Nit: this makes it sounds like the BEAM was designed for web dev, which it was not. Erlang came out of Ericsson and was built for telecoms (OTP stands for Open Telecom Platform), which is where its unique set of trade-offs comes from. Many of those trade-offs make a ton of sense for web but that's not because it was designed for web, it's because there's overlap between the fields.

One way to see the difference between telecoms and web is to ask yourself when was the last time that you were working on a project with an availability SLA of 9 nines (1/3 of a second of downtime per year) or even 6 nines (32s per year). Some web dev has that, but most doesn't come close, and if that's not you then Erlang wasn't built for you (though you may still find you like it for other reasons!).

kybishop a day 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.

Reply View 8 replies

demosthanos a day 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.

Reply View | 7 replies
- throwawaymaths a day 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.
  
  Reply View | 6 replies
  
  demosthanos a day ago
  
  And if you need that kind of persistent immediately reactive connection and are willing to pay the price, go for it! If that's truly a requirement for you then you're in the subset of web that overlaps substantially with telecoms.
  I'm not cautioning against making the calculated decision that realtime is a core requirement and choosing the BEAM accordingly. I'm cautioning against positioning the BEAM as being designed for web use cases in general, which it's not.
  Many projects, including GitHub, do not need that kind of immediate reactivity and would not have benefited enough from the BEAM to be worth the trade-offs involved. A single example of a UX flow that could be made slightly better by rearchitecting for realtime isn't sufficient reason to justify an entirely different architecture. Engineering is about trade-offs, and too often in our field we fall for "when all you have is a hammer". Realtime architectures are one tool in a toolbox, and they aren't even the most frequently needed tool.
  
  Reply View | 4 replies
  
  notjoemama 12 hours ago
  
  > in the modern web world you often have persistent client server connections
  Is this actually true though? I’d be interested if you know any data backing that perspective. I only know what I’ve worked on and my anecdotal experience doesn’t match with this statement. But I know my sphere doesn’t represent the whole. In terms of state, by now there are many ways of dealing with persistence and reconnection. Not only are most of those problems solved with existing technologies and protocols but they’re everywhere in web dev. Maybe we’re talking past each other? Did I misunderstand your point?
  
  Reply View | 0 replies