> The JIT now works for 64-bit ARM processors. Does this mean mobile apps in Erlang is not far off ?
Probably mostly focused towards running on Graviton et al.
Erlang/OTP 25.0 Release
71–80 of 125 posts
Re: Erlang/OTP 25.0 Release
#72I've seen more than once recently an engineer saying that software solutions outside of the Serverless ecosystem (FaaS, DB, etc) is "the new legacy". And that cloud providers have solved all the pains that Erlang was supposed to address. What's your feeling on this? Elixir sounds very compelling to me, but I worry that I might be going in a direction that's not where the industry is going.
One current advantage: FaaS is sold below cost by every cloud provider at the moment, so if you can design your app to take advantage of it, you'll save $$$.
Don't know how that'll hold up into the very long term though...
Re: Erlang/OTP 25.0 Release
#73I've seen more than once recently an engineer saying that software solutions outside of the Serverless ecosystem (FaaS, DB, etc) is "the new legacy". And that cloud providers have solved all the pains that Erlang was supposed to address. What's your feeling on this? Elixir sounds very compelling to me, but I worry that I might be going in a direction that's not where the industry is going.
One current advantage: FaaS is sold below cost by every cloud provider at the moment, so if you can design your app to take advantage of it, you'll save $$$. Don't know how that'll hold up into the very long term though...
I highly doubt they are sold below cost - when I've checked, the costs are actually higher than a regular VM instance for the equivalent amount of compute.
Re: Erlang/OTP 25.0 Release
#74> The JIT now works for 64-bit ARM processors. Does this mean mobile apps in Erlang is not far off ?
I don't see any serious attempt at UIs with erlang. I think erlang processes would provide a great foundation for UI components, but has it even been tried?
Not really, because UI components inherently need tight integration for event propagation, layouting, drawing... Sure, you could render individual components in their own processes and have one process accumulate a render tree , but I don't see much sense in that.
The lack of GC also is a problem, so you might have to do each redraw in a fresh process or something like that to avoid accumulating too much memory.
Processes would be good for all sideline functionality like API/db requests and expensive computations.
Re: Erlang/OTP 25.0 Release
#75https://youtu.be/rRbY3TMUcgQ 2013 and still totally relevant Outlaw Techno Psychobitch FTW
“Go home and take my nine nines with me.” Hilarious! Thank you.
Re: Erlang/OTP 25.0 Release
#76I've seen more than once recently an engineer saying that software solutions outside of the Serverless ecosystem (FaaS, DB, etc) is "the new legacy". And that cloud providers have solved all the pains that Erlang was supposed to address. What's your feeling on this? Elixir sounds very compelling to me, but I worry that I might be going in a direction that's not where the industry is going.
Serverless systems in almost every implementation are still stateless or limited stateful-serverless (the best examples are probably Microsoft's Durable Functions or Flink's Stateful Functions - there's also solid attempts by the Akka folks). These are largely built on top of either a stream processing (in case of Flink) or some flavor of Actor model based on event sourcing for peristence. What I'm getting at is that…
This is one of the best answer.
Also:
- the supervisor system in Erlang/Elixir is relatively complex. It goes much beyond the "restart my service" when it crashes but allow to restart some processes, without restarting the service, and in a specific order to keep the system coherent.
- local and remote calls behave the same in Erlang/Elixir, allowing to start with a monorepo having different Erlang "apps" than run on the same node, but then running the different apps on different nodes in the future, once the application, scales. This can be done very little changes to the application.
Re: Erlang/OTP 25.0 Release
#77Earlier quoted context omitted.
I'm not sure where the industry is going but the innovations around LiveView are really convincing (I'm using LiveView in my work). Some great innovating Elixir projects: Oban: https://getoban.pro/ Oban Demo: https://getoban.pro/oban Livebook: https://livebook.dev/
A lot of popular web frameworks have their take on how to arrive at the same goal which is to be able to create responsive feeling sites without writing a lot of JS and creating API backends. Rails has Hotwire Turbo (which is technically back-end agnostic), Laravel has LiveWire, there's also HTMX which is a bit lower level and back-end agnostic. There's also Django Unicorn and Rails Stimulus Reflex. All of these solu…
I also worked with Rails before and I'm happy to see their progress,
I however wouldn't go back to work with it if I can choose,
for me Phoenix and LiveView doesn't feel like magic or too much convention unlike Rails does unfortunately.
Re: Erlang/OTP 25.0 Release
#78> The JIT now works for 64-bit ARM processors. Does this mean mobile apps in Erlang is not far off ?
I don't see any serious attempt at UIs with erlang. I think erlang processes would provide a great foundation for UI components, but has it even been tried?
I'm in elixir land - but have a look at https://github.com/elixir-desktop - they even have an ios app in the app store..
basically wxwidgets comes with a webview, and that one is loaded up - and everything is packaged as an app - so you can use phoenix (liveview), or even react or anything to your liking..
believe certain improvements were made to OTP 25, so multiple things will land soon - even livebook https://github.com/livebook-dev/livebook are aiming at shipping a native app..
Re: Erlang/OTP 25.0 Release
#79> The JIT now works for 64-bit ARM processors. Does this mean mobile apps in Erlang is not far off ?
I haven't used it, but in a recent Thinking Elixir episode, they talked about Elixir-Desktop, which supports Android and iOS, as well as the standard Windows/Mac/Linux
Re: Erlang/OTP 25.0 Release
#80* The JIT now works for 64-bit ARM processors, including M1 * The JIT now does type-based optimizations based on type information in the BEAM files.
Previously (Erlang/OTP 24 highlight)
"The BeamAsm JIT-compiler has been added to Erlang/OTP and will give a significant performance boost for many applications. The JIT-compiler is enabled by default on most x86 64-bit platforms that have a C++ compiler that can compile C++17."