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?
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!
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.
luckily, mobile devices never encounter problems like a backhoe cutting it off from the network.
For example Elixir/Erlang are currently used in certain IoT applications.
Lights, fridges, washing machines.
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.
Is this a reason to use a different language? Or sometimes an effect if doing so?
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.
For a large company with lots of developers? Makes less sense. Better use the best tools for the tasks.
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.
what do you mean by that? can you please elaborate ? thanks !
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.
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.
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.
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.