11–20 of 89 posts
PureScript is a mature functional programming language with an Erlang back end, if you want another statically typed alternative for BEAM. It is basically a dialect of Haskell with strict evaluation and row polymorphism.
Earlier quoted context omitted.
Whenever you message another process and need a reply there is a risk of deadlock. I didn't find any primtives in OTP for handling this, you have to structure your actor interaction to avoid it. You can't just have a little bit of shared memory. The actor model doesn't really offer any benefit over other models while bringing significant downsides. Plus, there are major downsides to using an unpopular platform like E…
``` Whenever you message another process and need a reply there is a risk of deadlock. ``` can you please explain how there is risk of deadlock here ? thanks !
This is rarely a problem in practice however.
IMHO the actor model is great until you need to share something across processes, then you have a distributed computing problem inside your program. For developing fault tolerant multicore programs I think I'm better off using a functional effects system with software transactional memory like Scala/ZIO than Gleam/OTP. I can still use the actor model where appropriate. Plus the JVM software ecosystem and runtime obse…
Incidentally that's what actors are designed for, passing data and being able to mutate their state without use of explicit synchronisation. You either copy or transfer ownership of data from one actor to the next via message passing. Actual sharing should be only done if the data in question is globally immutable.
Earlier quoted context omitted.
In Elixir/Gleam/OTP.., the entire program is a collection of progresses which are isolated from each other. Even if you don’t implement the actor pattern, passing state between processes and coordinating is a solved problem. We have primitives like tasks, agents, GenServer, Supervisors etc.
Whenever you message another process and need a reply there is a risk of deadlock. I didn't find any primtives in OTP for handling this, you have to structure your actor interaction to avoid it. You can't just have a little bit of shared memory. The actor model doesn't really offer any benefit over other models while bringing significant downsides. Plus, there are major downsides to using an unpopular platform like E…
Earlier quoted context omitted.
In Elixir/Gleam/OTP.., the entire program is a collection of progresses which are isolated from each other. Even if you don’t implement the actor pattern, passing state between processes and coordinating is a solved problem. We have primitives like tasks, agents, GenServer, Supervisors etc.
Whenever you message another process and need a reply there is a risk of deadlock. I didn't find any primtives in OTP for handling this, you have to structure your actor interaction to avoid it. You can't just have a little bit of shared memory. The actor model doesn't really offer any benefit over other models while bringing significant downsides. Plus, there are major downsides to using an unpopular platform like E…
There are edge cases, sure, but I have yet to encounter a deadlock after 7 years of professional work with Elixir.
> I didn't find any primtives in OTP for handling this
See `GenServer.call/2`. This covers 99% of call/return patters in distributed systems. I take it you haven’t written much (any?) Elixir because you would have found this function.
> The actor model doesn't really offer any benefit over other models while bringing significant downsides.
Actors are a way better abstraction for pretty much any application-level code I can think of. I say this having written Go, Rust, and Elixir. What downsides are you talking about specifically?
> Plus, there are major downsides to using an unpopular platform like Erlang/BEAM.
The BEAM is popular. At least 3 different serious languages use it. What down sites are you waving your hands up here?
Earlier quoted context omitted.
``` Whenever you message another process and need a reply there is a risk of deadlock. ``` can you please explain how there is risk of deadlock here ? thanks !
Risk of deadlock is real if you have processes calling each-other in a cyclic way. e.g. process A sends GenServer call to process B, that then sends a GenServer call to process A to in order to handle the original call. However, process A is busy waiting on B to reply to it's initial call. This is rarely a problem in practice however.
PureScript is a mature functional programming language with an Erlang back end, if you want another statically typed alternative for BEAM. It is basically a dialect of Haskell with strict evaluation and row polymorphism.
The website and gh repo say it compiles to JS. Where did you learn that it has an Erlang backend?
IMHO the actor model is great until you need to share something across processes, then you have a distributed computing problem inside your program. For developing fault tolerant multicore programs I think I'm better off using a functional effects system with software transactional memory like Scala/ZIO than Gleam/OTP. I can still use the actor model where appropriate. Plus the JVM software ecosystem and runtime obse…
Earlier quoted context omitted.
In Elixir/Gleam/OTP.., the entire program is a collection of progresses which are isolated from each other. Even if you don’t implement the actor pattern, passing state between processes and coordinating is a solved problem. We have primitives like tasks, agents, GenServer, Supervisors etc.
Whenever you message another process and need a reply there is a risk of deadlock. I didn't find any primtives in OTP for handling this, you have to structure your actor interaction to avoid it. You can't just have a little bit of shared memory. The actor model doesn't really offer any benefit over other models while bringing significant downsides. Plus, there are major downsides to using an unpopular platform like E…
Earlier quoted context omitted.
Whenever you message another process and need a reply there is a risk of deadlock. I didn't find any primtives in OTP for handling this, you have to structure your actor interaction to avoid it. You can't just have a little bit of shared memory. The actor model doesn't really offer any benefit over other models while bringing significant downsides. Plus, there are major downsides to using an unpopular platform like E…
OTP typically handles this with timeouts and then restarts when timeouts occur. Not to say it can't happen, but there are strategies.