Considering that Erlang originated in the telecom world, I find it a bit odd that mobile development options are lacking. Anything to be expected in that space?
Erlang's use in the telecom sphere has primarily been focused on switching, routing, and real time voice processing on the backend. Beyond just handling cellular traffic, many internet switches are written in Erlang too. It's only recently that Erlang has been used for more of the type of code that could run on the frontend. (The niceness of writing Elixir is a big part of that too.)
The primary blocker to running Erlang on mobile has been the lack of portability of the BEAM VM itself, which is why this project is so exciting!
The massive concurrency and fault isolation properties are very nice for telephony switches (and web servers etc.) but not usually super relevant for phone apps.
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.
The compiler and the binaries it produces run fine on Android and Linux phones.
> … bit odd that mobile development options are lacking
what do you mean by that? can you please elaborate ? thanks !
I mean tools to run Erlang apps on iOS and Android, for example.
It has been done.
https://github.com/elixir-desktop/desktop
And a different variant driven by the server typically:
https://github.com/liveview-native/live_view_native
Not to say it is particularly ideal. But it exists.
i see ok. well, erlang is more suited to program gateway nodes in the core of 3g/4g networks.
these nodes handle tasks such as handling mobility (managing handovers as cell phones moves from one location to another etc), data transfer f.e providing ip addresses to your phones etc etc.
as you can imagine, this sort of gear lives deep within service providers network, and each entity handles hundreds of thousands of sessions f.e serving an entire state etc etc.
and these nodes cannot go down taking services/sessions with them.
Erlang (and Elixir and so on) run fine under Termux. Just slap on Phoenix or something and have your GUI in the phone browser if that's your thing.
People that have succumbed to Apple tell me they have facilities at least as good as Termux so you can probably do something similar there.
gui is single(immediate mode) or two(graph based) threaded. with some async going to backend or some app defined compute bounded.
there is no need for actors nor green threads. no need for erlang nor go. languages were not designed for gui(unlike js or csharp), will need a lot of boilerplate for trivial patterns.