Hacker News

Gleam OTP – Fault Tolerant Multicore Programs with Actors

• 29 Comments
• I 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.

  By rapind 5 hours ago

• For someone who hasn’t worked with either, is it better to learn gleam/lustre better or elixir/phoenix?

  By akudha an hour ago

• 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.

  By rapind 32 minutes ago

• 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.

  By hackingonempty 4 hours ago

• The website and gh repo say it compiles to JS. Where did you learn that it has an Erlang backend?

  By behnamoh 4 hours ago

• https://github.com/purescript/documentation/blob/master/ecos...

  By megabluejay 3 hours ago

• 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

  By tiffanyh 3 hours ago

• I think that’s just confusing wording. It sounds like it’s a backend for the Purescript compiler that generates Erlang.

  By sarchertech 2 hours ago

• Very cool! Looking forward to trying it out.

  By isodev 5 hours ago

• 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 observability / battle-testedness is far better than BEAM.

  By hackingonempty 5 hours ago

• 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.

  By troad 2 hours ago

• >IMHO the actor model is great until you need to share something across processes
  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.

  By NL807 4 hours ago

• > 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)

  By toast0 39 minutes ago

• 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.

  By isodev 5 hours ago

• 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 Erlang/BEAM.

  By hackingonempty 4 hours ago

• > Whenever you message another process and need a reply there is a risk of deadlock.
  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?

  By ashton314 3 hours ago

• > 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.
  I see a lot of people that dislike Erlang that run into this or are afraid of running into it.
  Receive with timeout is certainly a primative to handle this, and there's things like process aliases so that late responses can be more easily ignored. But, there's nothing structural preventing it. It's just that when you do it, it hurts, so hopefully you stop doing it.
  But when you're in a situation whete you've setup circular messaging, it's very easy to identify. You see a process (A) that has is making no progress and/or has a large mailbox. You see the stack trace shows it is messaging process B, you inspect process B to see why it didn't respond and see it is messaging process A and there you go. Or you look at process A's mailbox and see that it has requests related to the request it's already trying to fill.
  > The actor model doesn't really offer any benefit over other models while bringing significant downsides.
  I find the actor model makes many types of request/response for persistent state to become very simple. A process owns the state, and application level read/write messages are sent to that process. The mailbox serializes access to provide an ordering and to make changes atomic. You certainly have choose your messages; if you have a counter and do a get and a set message, you will lose updates; you need to do increment/decrement/add kind of messages; same thing for larger/more complex datastructures. Linked datastructures are still tricky.
  It's also super nice for request/response connection handling. Just write straight line code that reads from the connection when it needs a request and writes to it when the response has been computed. When you need to be asynchronous, it's more complex, but not so terrible. The process becomes a loop waiting for a fully formed request from the client (which then gets sent off to a request processor) or a reply from a processor (which then gets sent to the client) ... Java's Loom green threads will likely socialize this further than Erlang has.
  > Plus, there are major downsides to using an unpopular platform like Erlang/BEAM.
  Sure, you have to do more work yourself. On the otherhand, relying on the work of others isn't always less work than doing it yourself. There are at least a few Erlang consulting shops you can go to if you really need something and are unwilling or unable to do it. You can't find a lot of answers on stackexchange, but you also don't find a lot of wrong or outdated answers either.

  By toast0 6 minutes ago

• Unpopular as opposed to what, Scala/Zio?

  By g8oz 4 hours ago

• OTP typically handles this with timeouts and then restarts when timeouts occur. Not to say it can't happen, but there are strategies.

  By asa400 4 hours ago

• sometimes people think they know better and want to reinvent the wheel

  By throwawaymaths 3 hours ago

• Beam languages have a different concurrency model than what you’re used to in JVM world. I suggest that you try some of them in a real project (even without actors).

  By isodev 4 hours ago

• ```

      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 !

  By signa11 4 hours ago

• 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.

  By jhgg 4 hours ago

• receive takes a timeout. A would crash/hit the timeout and deal with the problem.

  By oxidant 3 hours ago

• you are not blocked on response right ?

  By signa11 2 hours ago

• Avoiding exactly that is why erlang gives you genserver.

  By throwawaymaths 3 hours ago

• > 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.

  By troupo 31 minutes ago

• This sounds like a "I could not get my head around ZIO/Fuctional Effects ergo it's a needlessly complex overengineered monstrosity" argument.
  In fact, functional effects provide another elegant solution to problems requiring structured concurrency. You might like it, you might not. But there are many engineers in the Scala community who were bitten by the exact issues of actor deadlocking / difficulty of debugging compared to functional effects that refactored enterprise codebases from Akka (Scala actors) to functional effects.
  "A simple system that has been battle tested over decades of actual hardcore industrial use". The JVM certainly is not far from that.

  By AlterEgo7 a minute ago