What’s the latest on BEAMJIT progress?
OTP 23
91–100 of 121 posts
Re: OTP 23
#92Does cloud-based serverless computing compete with or complement Erland/Elixir? As a dotNetCore developer who writes a lot of Lambda and Azure function code I am trying to understand how OTP relates to these paradigms or if they are apples and oranges.
Erlang VM startup time is not great (in order of hundred milliseconds), but it has pretty unique features like hot bytecode patching in a running VM. So, naturally, Erlang shines when you need to build a system that runs for a long time, as opposed to short-lived lambdas.
reminds me of: https://github.com/cloudozer/ling
Re: OTP 23
#93Re: OTP 23
#94Earlier quoted context omitted.
Everything that you pointed out can be achieved in Elixir, quite easily too. If I understood you correctly. Not sure what you mean by "actor frameworks don't compose"?
Actor frameworks don't compose, because actors are an atomic compute unit. You can't really take a horse actor and a bird actor and turn them into a pegasus actor. There are non-trivial interactions between message handling logic that would prevent such a thing with some fairly trivial-to-generate breaking cases. Maybe composition for compositions' sake isn't that important?
You can write great and useful software in non-composable languages. People write good stuff in C or Go.
But if you have the choice, composability always seems much nicer to me and stops me wanting to tear my hair out.
Re: OTP 23
#95Earlier quoted context omitted.
Mutable state is essential to the actor model. Local arguments to a tail-recursive message loop which change based on the last received message and the previous arguments, and determine behavior (i.e. messages sent and side effects), are equivalent to local mutable state. State machines are a lot better than unstructured, freely mutable global variables, but they are still mutable state.
Sure. That's absolutely unavoidable in any FP language. All their compilers invisibly produce a lower-level code that's intrinsically using the mutable paradigm. It's how our hardware works currently.
No, in an actor based model the mutable parts that the comment you replied to mentioned are surfaced to the user.
It's not about how the Erlang VM is implemented. You could implement it in pure Haskell and compile it so some hypothetical pure CPU. Wouldn't change that part of how you interact with it that is stateful as described.
(And I liked programming in Erlang.)
Re: OTP 23
#96Earlier quoted context omitted.
Everything that you pointed out can be achieved in Elixir, quite easily too. If I understood you correctly. Not sure what you mean by "actor frameworks don't compose"?
Actor frameworks don't compose, because actors are an atomic compute unit. You can't really take a horse actor and a bird actor and turn them into a pegasus actor. There are non-trivial interactions between message handling logic that would prevent such a thing with some fairly trivial-to-generate breaking cases. Maybe composition for compositions' sake isn't that important?
> Maybe composition for compositions' sake isn't that important?
Definitely. I was about to ask "but when did you actually need to compose actors and how does that even make sense?" -- and while I am sure there are people who would find a scenario I feel that would still be tarrying on minutiae.
Obviously the actor model is not a panacea. But for my commercial work Elixir -- and thus Erlang's OTP -- has been a true blessing. There aren't many commercial scenarios where OTP is a very poor fit. They do exist but I'd dare saying they are no more than 10-15% of everything you can stumble upon out there.
Re: OTP 23
#97Earlier quoted context omitted.
Actor frameworks don't compose, because actors are an atomic compute unit. You can't really take a horse actor and a bird actor and turn them into a pegasus actor. There are non-trivial interactions between message handling logic that would prevent such a thing with some fairly trivial-to-generate breaking cases. Maybe composition for compositions' sake isn't that important?
You can write great and useful software in non-composable languages. People write good stuff in C or Go. But if you have the choice, composability always seems much nicer to me and stops me wanting to tear my hair out.
This is definitely true, I am just not sure how well it applies to actors. For all data-modelling scenarios and OOP/FP ways of doing polymorphism, composability is a life-saver though.
Re: OTP 23
#98Earlier quoted context omitted.
Sure. That's absolutely unavoidable in any FP language. All their compilers invisibly produce a lower-level code that's intrinsically using the mutable paradigm. It's how our hardware works currently.
No, in an actor based model the mutable parts that the comment you replied to mentioned are surfaced to the user. It's not about how the Erlang VM is implemented. You could implement it in pure Haskell and compile it so some hypothetical pure CPU. Wouldn't change that part of how you interact with it that is stateful as described. (And I liked programming in Erlang.)
And I still disagree with that comment that "mutable state is rampant". There are realities which we all have to take into account. To give an extreme example, should we get rid of all mutable databases and use append-only journals? That might help eliminate another class of bugs but there are a number of (practical and political) limiting factors in commercial projects.
But maybe we'll talk the same language if you give a few examples. I was under the impression that my parent poster made the point of "but your FP code gets compiled to imperative mutable code so FP is not good" or something. If I was mistaken in my interpretation then we're talking past each other.
Re: OTP 23
#99Does cloud-based serverless computing compete with or complement Erland/Elixir? As a dotNetCore developer who writes a lot of Lambda and Azure function code I am trying to understand how OTP relates to these paradigms or if they are apples and oranges.
It competes, mostly. Amazon's internal SOA implements pretty much the same principle around resilience and load balancing.
Unlike OTP it must be language-agnostic and also aware of latency and bandwidth.
Re: OTP 23
#100Earlier quoted context omitted.
I've used Erlang/OTP only on stateful servers, and observed its use in semi-stateless containerized deployment (but in that case, we were generating the containers to have a fictional state; we always had nodeX@hostnameY even if the container being that node moved around). However, OTP ships with a diskless mode, where all of the code and config, other than BEAM and modules critical to starting dist come from dist.
Stateful servers seems like an atrocious point of failure nowadays (except if it's a DB server, or a persistent queue). And i barely see it anymore, now that everything seems to be running on containers or VM that are supposed to be destroyable at any time. That's why the value of OTP seems to be less obvious at the moment (from the point of view of someone who doesn't use it). But there's surely something i'm missin…
> Stateful servers seems like an atrocious point of failure nowadays (except if it's a DB server, or a persistent queue)
I think that's the perception, but it isn't necessarily true. I work on an Elixir team that quite successfully runs a stateful server. The service is pretty stable and the stateful portion is never the source of problems. That's one anecdote, but if you look at servers for online games, they're often quite stateful and work rather well.