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?
Gleam OTP – Fault Tolerant Multicore Programs with Actors
21–30 of 89 posts
Re: Gleam OTP – Fault Tolerant Multicore Programs with Actors
#22Earlier quoted context omitted.
The website and gh repo say it compiles to JS. Where did you learn that it has an Erlang backend?
https://github.com/purescript/documentation/blob/master/ecos...
Isn’t it the opposite of what the GP stated:
> purerl is a PureScript backend targetting Erlang source.
The backend is not Erlang. It’s a Purescriot backend.
Re: Gleam OTP – Fault Tolerant Multicore Programs with Actors
#23IMHO 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…
This is a wild take. It's one thing to criticise the BEAM for things it's bad at, it's another to criticise it for the thing it absolutely excels at.
The BEAM is built around passing immutable messages between cheap green threads, watched over by resilient supervisor trees. This means no data races (immutability), no hung threads (supervisor trees), no boilerplate (all of this is built in). The performance is surprisingly good, since mandatory immutability permits reference-based optimisations (copying, passing, etc).
The BEAM is, in fact, the perfect platform for the exact use case you describe - fault-tolerant, distributed/concurrent systems.
Re: Gleam OTP – Fault Tolerant Multicore Programs with Actors
#24Earlier 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.
you are not blocked on response right ?
Re: Gleam OTP – Fault Tolerant Multicore Programs with Actors
#25Earlier quoted context omitted.
https://github.com/purescript/documentation/blob/master/ecos...
Isn’t it the opposite of what the GP stated: > purerl is a PureScript backend targetting Erlang source. The backend is not Erlang. It’s a Purescriot backend. https://github.com/purerl/purerl
I think that’s just confusing wording. It sounds like it’s a backend for the Purescript compiler that generates Erlang.
Re: Gleam OTP – Fault Tolerant Multicore Programs with Actors
#26I just started a small project using gleam / lustre, and so far I’m loving it. Worth trying if you’re on the fence, especially if you’re into static types, no nulls, functional, ML type languages. Plus beam of course.
For someone who hasn’t worked with either, is it better to learn gleam/lustre better or elixir/phoenix?
Re: Gleam OTP – Fault Tolerant Multicore Programs with Actors
#27Earlier quoted context omitted.
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.
receive takes a timeout. A would crash/hit the timeout and deal with the problem.
Yes, agreed, hence rarely a problem in practice ;)
Re: Gleam OTP – Fault Tolerant Multicore Programs with Actors
#28IMHO 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…
> IMHO the actor model is great until you need to share something across processes, then you have a distributed computing problem inside your program.
I'm sorry, but your multicore computer (and most single core computers, too) are a distributed system, regardless of if you acknowledge it.
Shared memory concurrency use implicit communicatiom between threads, but it's still communicating processes, you just don't have the same level of control and isolation. That said, of course there are situations where you can have better results with shared memory and there are situations where message passing is better. You can do shared memory in BEAM with ets, and if that doesn't meet your needs, with NIFs ... you likely lose out on some isolation, etc, and it won't always be a good fit.
> Plus the JVM software ecosystem and runtime observability / battle-testedness is far better than BEAM.
Maybe battle tested (although, I've certainly battle tested BEAM more than I've tested JVM; but I'll grant that many more people have done battle with the JVM)... but BEAM has quite extensive observability. You can see all sorts of stuff about every process, you can add tracing at run time. You can change the code at run time if you need to add more stuff; and runtime code changing is just in the normal setup, it's not exotic (although many people eschew it)
Re: Gleam OTP – Fault Tolerant Multicore Programs with Actors
#29I just started a small project using gleam / lustre, and so far I’m loving it. Worth trying if you’re on the fence, especially if you’re into static types, no nulls, functional, ML type languages. Plus beam of course.
For someone who hasn’t worked with either, is it better to learn gleam/lustre better or elixir/phoenix?
For me, gleam is a better fit for the reasons I mentioned, but elixir / phoenix is definitely more mature, so I guess it depends what you like and what you want out of it.
Re: Gleam OTP – Fault Tolerant Multicore Programs with Actors
#30IMHO 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…
> I think I'm better off using a functional effects system with software transactional memory like Scala/ZIO than Gleam/OTP
Translation: I think I'm better off using needlessly complex overengineered monstrosity that takes insane effort to do even the simplest of things, and that still gives me no actual guarantees, than a simple system that has been battle tested over decades of actual hardcore industrial use.