Why would a programing language built around accepting and dealing with millions of connections, and used in base stations, routing, and switching be useful for a mobile device?
Buzz Aldrin would have killed the Apollo 11 crew if Margaret Hamilton had been a worse developer. He pulled up an optional display during the landing that was overloading the computer due to a bug, and the scheduler kept killing optional tasks to keep the control and guidance systems all running.
There’s the same sort of realtime system in the BEAM. When you run nice to have and mission critical software together life is much less exciting if you have something handling such things.
because it was designed as a general purpose programming language that has robust affordances for weird shit like connections dropping due to a backhoe severing your copper into a PBX.
luckily, mobile devices never encounter problems like a backhoe cutting it off from the network.
The programming model of message passing between processes lends itself well to certain types of apps even if you don't need to handle millions of connections.
For example Elixir/Erlang are currently used in certain IoT applications.
At the end of the day many IOT devices are just providing or receiving messages.
Lights, fridges, washing machines.
Uniformity of language between back and front-end, and communication layers?
Because the apps on my phone need to be written in the same language as the network devices my carrier runs? What?
That's taking it to its extreme (unnecessary as your carrier is a different company), but consider building an application like Telegram or WhatsApp, then it would certainly be nice to use one language for everything, from front-end, back-end to distributed computing stuff.
> then it would certainly be nice to use one language for everything, from front-end, back-end to distributed computing stuff.
People say this, but it's not that helpful, IMHO. Front end and backend have different concerns, usually different teams, and using anything other than the preferred language for a client platform tends towards clunky UX.
You can do some sort of core networking library that's shared between clients, and I guess there's reasons you might want that to be Erlang, but integration feels like a lot of work when you can just deal with it in another language. Client side concurrency is so much less than server side concurrency, it'll be fine.
> usually different teams
Is this a reason to use a different language? Or sometimes an effect if doing so?
It's not a reason to use a different language, but if you let each team choose an effective language for their work, they may well choose different languages.
That's simply not true. The best language for a front end is the language that's preferred by the platform. Firefox famously rewrote their UI with Java on Firefox because the XUL version was miserable. You don't build iOS apps with Java. You don't build Android apps with Go.
You can't actually build a mobile app entirely in JavaScript, but if your used React Native the parts that actually deal with materially interfacing between the client and the server aren't in JavaScript. At best you can share some typescript definitions.
Java on the server is extremely different from Java on client, and the same can be said for Swift. What do you get to share? Maybe the code that serializes and deserializes messages? But even then that's thanks to a library, not the language (and if you're using a feature of the stdlib, it's almost certainly just as easy to use in any other reasonable language).
Pyodide and PyScrpt exist and you could certainly build a full stack web app with them. Why doesn't anyone, then? It's because doing so doesn't solve any serious problems or make anything much better.
Why? For a small one person team? Sure it would be nice to write everything in one language in one repo.
For a large company with lots of developers? Makes less sense. Better use the best tools for the tasks.
Why though? Why would you want your UI code in Python, as an example? Python has nothing in its standard library to help make websites. Tools like PyScript might give you the DOM, but suddenly you'll be using shims for all the other stuff you need, like resize handlers or fetch() or Intl.NumberFormat or anything else you care about.
Web apps are JavaScript. Android apps run on a JVM. iOS apps are whatever can compile to native code and use Apple's APIs. When you avoid the runtime of the language that you're expected to build for on a platform, you'll inevitably spent most of your time working just to get a handful of features that you need from the runtime into the language you're choosing to use.