8 ms·

Gleam OTP – Fault Tolerant Multicore Programs with Actors

197 points by TheWiggles 1y ago

rapind 1y ago
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.
- akudha 1y ago
  For someone who hasn’t worked with either, is it better to learn gleam/lustre better or elixir/phoenix?
  - rapind 1y 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.
  - the-grump 1y ago
    My path is a little different. I have used Haskell, and I'm looking to get into OTP. My original plan was either Elixir or vanilla Erlang depending on which one suits my sensibilities better. Reading about Gleam recently has me super, super excited. That's definitely going to be my path now. I don't know if Gleam is the best entry into the world of rich types that you find in a language like Haskell--I'm yet to actually build something with it. What I can tell you is that Haskell is a complete joy to use and it honestly ruins most other programming for me. So as a direction, I cannot recommend it enough, and I'm hoping, for my sake and yours, that Gleam offers a similarly stimulating sandbox. Just a warning that it will take time to get used to "higher-kinded" types. It's an exercise in head scratching and frustration at first. The reward part arrives when you start thinking in types yourself and you know which ones to reach for and when you find the libraries you want by entering a signature on Hoogle.
    - raphinou 1y ago
      Interesting! I have a F# background, and thought to have read that some constructs I learned to appreciate are not available in Gleam (the one I can think of right now is currying, but I thought there were others). Also, Gleam otp didn't seem to be a priority. What's your experience regarding these 2 points?
      - innocentoldguy 1y ago
        The issue isn't that OTP isn't a priority for Gleam, but rather that it doesn't work with the static typing Gleam is implementing. This is why they've had to reimplement their own OTP functionality in gleam_otp. Even then, gleam_otp has some limitations, like being unable to support all of OTP's messages, named processes, etc. gleam_otp is also considered experimental at this point.
        59nadir 1y ago
        Having Erlang-style OTP support (for the most part) is very doable, I've written my own OTP layer instead of the pretty shoddy stuff Gleam ships with. It's not really that challenging of a problem and you can get stuff like typed processes (`Pid(message_type)`, i.e. we can only send `message_type` messages to this process), etc. out of it very easily. This idea that static typing is such a massive issue for OTP style servers and messaging is a very persistent myth, to be honest; I've created thin layers on top of OTP for both `purerl` (PureScript compiled to Erlang) and Gleam that end up with both type-safe interfaces (we can only send the right messages to the processes) and are type-safe internally (we can only write the process in a type-safe way based on its state and message types).
        innocentoldguy 1y ago
        I wholeheartedly agree with you that gleam_otp is janky. Still, actor message passing is only part of the picture. Here are some issues that make static typing difficult in OTP: • OTP processes communicate via the actor model by sending messages of any type. Each actor is responsible for pattern-matching the incoming message and handling it (or not) based on its type. To implement static typing, you need to know at compile time what type of message an actor can receive, what type it will send back, and how to verify this at compile time. • OTP's GenServer behaviour uses callbacks that can return various types, depending on runtime conditions. Static typing would require that you predefine all return types for all callbacks, handle type-safe state management, and provide compile-time guarantees when handling these myriad types. • OTP supervisors manage child processes dynamically, which could be of any type. To implement static typing, you would need to know and define the types of all supervised processes, know how they are going to interact with each other, and implement type-safe restart strategies for each type. These and other design roadblocks may be why Gleam chose to implement primitives, like statically typed actors, instead of GenServer, GenStage, GenEvent, and other specialized OTP behaviours, full supervisor functionality, DynamicSupervisor, and OTP's Registry, Agent, Task, etc. OTP and BEAM are Erlang and Elixir's killer features, and have been battle-tested in some of the most demanding environments for decades. I can't see the logic in ditching them or cobbling together a lesser, unproven version of them to gain something as mundane as static typing. EDIT: I completely missed the word "actor" as the second word in my second sentence, so I added it.
  - Munksgaard 1y ago
    As someone who comes from Haskell/ML-like languages, I decided to opt for Elixir and Phoenix for my latest project, simply because of the maturity of the web framework and LiveView. If I weren't building a web app, I'd probably have gone with Gleam instead. Edit: I do miss static typing, but it's worth it to not have to reinvent the web framework wheels myself.
  - innocentoldguy 1y ago
    In my opinion, Elixir and Phoenix will give you a better experience with BEAM and OTP, excellent tooling, a more mature ecosystem, and one of the best web frameworks ever to exist. I think Gleam is cool, but I can't see trading these benefits in for static typing. To be fair, I can't think of anything I care less about than static typing, so please keep that in mind when entertaining my opinion.
    - raphinou 1y ago
      I also preferred dynamic typing, until my complex rails app grew to the point I didn't dare to do any refactoring. But I didn't switch opinion until I discovered ML type systems, which really allow for fearless refactoring. At occasion there's some battling to satisfy the typesystem, but even with that I'm more productive once the app grows in complexity. I thought I'd share my experience, not trying to convince anyone ; - )
  - MDTHLN 1y ago
    I love Gleam, but I would start with Elixir if you're interested in learning about how powerful the BEAM & OTP are. There's not much documentation/resources around OTP in Gleam. When I was playing around with it I often found myself referring to the Elixir docs and then 'translating' that knowledge to Gleam's OTP implementation. Gleam is still very new so this is totally understandable, and both are great languages so you'll likely have a lot of fun learning either of them.
    - 59nadir 1y ago
      Erlang is a much better language to learn if you're interested in learning about the BEAM and OTP, and the book "Programming Erlang"[0] is an excellent resource for learning it. 0 - https://pragprog.com/titles/jaerlang2/programming-erlang-2nd-edition/ https://pragprog.com/titles/jaerlang2/programming-erlang-2nd...
      - _acco 1y ago
        I disagree. I started with Elixir and its OTP resources are really good. Books like Elixir in Action do a great job. I read Programming Erlang later, but it was just for fun, and I knew most things already at that point.
        59nadir 1y ago
        I've used Elixir since 2015 and in fact learned it first. I still think "Programming Erlang" is a much better book than any other for actually learning Erlang and BEAM/OTP principles. Erlang as a language is simpler, leaving more time and energy for learning the actual important bits about OTP.
        Miner49er 1y ago
        Also Elixir abstracts even more of the OTP and does some automagical stuff with it. Erlang is more explicit, which is better for learning, IMO.
  - victorbjorklund 1y ago
    Gleam is cool but honestly for now the ecosystem is so much bigger in Elixir. And yes, you can use some libraries across and things like that, but then again you could also bring in the parts that you need from Gleam into Elixir and instead of vice versa. If you just want to learn a really cool language, I think Gleam is pretty cool. But if you want to learn a language that is more productive but still kind of cool, I would start really like here and then dip my toes into Gleam.
- sureglymop 1y ago
  Same and I like it too so far! Some thoughts so far: Installing gleam installed about 50 packages on my system (possibly all erlang/elixir related). But what if I just wanted to transpile to js? Perhaps this is a packaging issue on my system though. What I really wish is that Lua would be considered as another transpilation target. I think gleam could shine for DSLs in other programs but embedding Lua is 3x easier than embedding a js runtime imo. In general, I find the nicest thing so far the community. And I want to say that the quality of libraries and resources in the gleam community seems exceptionally high. It reminds me of the rust community insofar as that for most hard problems someone smarter than me has already worked on it and published a good solution (e.g. lustre, squirrel). Then I would say you can also expect a lot of creativity and experimentation, the things that may fly under the radar in larger language ecosystems stand out here due to the growing and welcoming community.
  - hayleighdotdev 1y ago
    > Perhaps this is a packaging issue on my system though. Gleam is only officially distributed via the releases on GitHub [1] so if you pick up Gleam from a package manager that's always maintained by someone else. I think most of those community distributions do include Erlang and bits which is probably what pulled in all those extra packages! [1]: https://github.com/gleam-lang/gleam/releases/tag/v1.13.0 https://github.com/gleam-lang/gleam/releases/tag/v1.13.0
- truculent 1y ago
  I like all of the above but have no understanding of the BEAM or OTP. Can you recommend a good place to start learning about that?
  - Joel_Mckay 1y ago
    In general, I found starting with a Erlang/Elixir framework tutorial helps. Phoenix includes a generic wrapper on top of PostgreSQL (Ecto provides data mapping and language integrated query), and hit a surprising number of users per host with trivial code (common game engine back-end.) https://www.phoenixframework.org/ https://www.phoenixframework.org/ https://www.amazon.com/Programming-Phoenix-Productive-Reliable-Fast/dp/1680501453 https://www.amazon.com/Programming-Phoenix-Productive-Reliab... If you don't run away from a framework intro, then dive into the details of the OTP: https://www.amazon.com/Designing-Elixir-Systems-OTP-Self-healing/dp/1680506617 https://www.amazon.com/Designing-Elixir-Systems-OTP-Self-hea... https://www.amazon.com/Elixir-Action-Third-Sa%C5%A1a-Juric/dp/1633438511 https://www.amazon.com/Elixir-Action-Third-Sa%C5%A1a-Juric/d... The only foot-gun I would initially avoid, is a fussy fault-tolerant multi-host cluster deployment. Check out RabbitMQ package maintainers, as those guys certainly offer a fantastic resource for students ( https://www.rabbitmq.com/docs/which-erlang https://www.rabbitmq.com/docs/which-erlang .) Best of luck =3
hackingonempty 1y 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.
- isodev 1y 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.
  - hackingonempty 1y 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.
    - isodev 1y 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).
    - g8oz 1y ago
      Unpopular as opposed to what, Scala/Zio?
    - signa11 1y 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 !
isodev 1y ago
Very cool! Looking forward to trying it out.
hackingonempty 1y 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.
- behnamoh 1y ago
  The website and gh repo say it compiles to JS. Where did you learn that it has an Erlang backend?
  - seivan 1y ago
    [dead]
  - megabluejay 1y ago
    https://github.com/purescript/documentation/blob/master/ecosystem/Alternate-backends.md https://github.com/purescript/documentation/blob/master/ecos...
    - tiffanyh 1y 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 https://github.com/purerl/purerl
      - sarchertech 1y ago
        I think that’s just confusing wording. It sounds like it’s a backend for the Purescript compiler that generates Erlang.
- lpil 1y ago
  The JS backend is mature, but the Erlang backend and accompanying ecosystem is very small compared to Gleam.
cedws 1y ago
I’m fascinated by the sound of Erlang/BEAM but I’ve never found the time to actually try it. How are people using it in production? Do you write all your service logic using it or delegate specific parts to it?
- jnmandal 1y ago
  I've seen folks doing both. Certainly, once you understand the OTP well enough, it makes sense to build all your systems on it. I've been doing that for seven years now; the only real issue was trying to train juniors to be productive on those systems. It did take longer to get them going I found.
- davydog187 1y ago
  We use Elixir at TV Labs to build our web services, a realtime matching engine, execute sandboxed Lua code, talk to microcontrollers over binary protocols, machine learning, and much more. It is an excellent general purpose language that succeeds in a lot of domains. Check out my conversation from Developer Voices for more info https://youtu.be/_MwXbHADT-A?si=2lRqjwAY9dsODyhW https://youtu.be/_MwXbHADT-A?si=2lRqjwAY9dsODyhW
- josefrichter 1y ago
  Come and have a chat at elixirforum.com. Plenty of folks write serious stuff entirely/predominantly in Erlang/Elixir & BEAM and will be happy to answer your questions.
  - cedws 1y ago
    Thank you!
- sethhochberg 1y ago
  I'm leading a team that is doing an incremental migration to Gleam by delegating specific parts - we're basically pushing the "functional core, imperative shell" pattern to its macro extreme and having Gleam pick up background jobs from our existing Ruby on Rails codebases where we have heavy calculation tasks. This approach is notably not making proper or really any use of OTP features, but it was an extremely easy way to adopt a safe, fast, functional language for number-crunching workflows while continuing to lean on Rails for everything else its great at: web interfaces, HTTP APIs, etc. Rails is basically the configuration tool for the various inputs of a job, and job is passed to Gleam via Redis as an atomic set of config inputs to be used when processing a dataset (usually big CSV files streamed from object storage). We use a very thin Elixir wrapper to do all network and file IO etc, Gleam modules are pure business logic called from Elixir. Some day soon, I'm going to try and write up a longer technical article about this approach... it comes up surprisingly often in HN conversations.
constructive 1y ago
gleam would be taken more seriously if they didnt plaster their strong political opinions on the project page..i do not understand why they need to talk about politics on a tech project page..this is not about agreeing or disagreeing with the viewpoints..just keep it out of your professional discourse if you want people to take you or your work seriously...otherwise it just deviates the discourse unnecessarily
- timeon 1y ago
  > otherwise it just deviates the discourse unnecessarily You could have chosen not to deviate the discourse.
- whalesalad 1y ago
  "Black lives matter. Trans rights are human rights. No nazi bullsh*t." Plaster? Are you referring to this singular line of text way down on their main page? If this statement precludes you from using the project I would imagine it is working as intended.
- deleted 1y ago
  [deleted]
giancarlostoro 1y ago
For all you wonderful people using Gleam, do you use Phoenix? Or any other web frameworks? I really would love to do Gleam with something like Phoenix, but I have not had enough time to check out all the options yet. I'm in the process of building a new project with Python, but if there's options with Gleam worth looking into I just might try it out for this new project.
- roxolotl 1y ago
  There isn’t really anything like Phoenix or Django or Rails. There are a set of tools though that are commonly used to build web apps. Lustre is the primary view tool. Wisp is the server. And then squirrel and POG, newer but people seem to like it, are used for sql. - squirrel: https://github.com/giacomocavalieri/squirrel https://github.com/giacomocavalieri/squirrel - Lustre: https://github.com/lustre-labs/lustre https://github.com/lustre-labs/lustre - Wisp: https://github.com/gleam-wisp/wisp https://github.com/gleam-wisp/wisp
- widdershins 1y ago
  There's a talk from Lustre's developer about doing LiveView-type things with Gleam/Lustre. The promise is that you can easily pick and choose which parts of your app run on the client, and which run on the server. https://www.youtube.com/watch?v=TbCm-zR7qZ0 https://www.youtube.com/watch?v=TbCm-zR7qZ0
candl 1y ago
I learned some Gleam a while ago, my familarity with F# helped, but I didn't find a use case for it. Some while ago I wanted to play with raw sockets so I figured, why not Gleam, its binary parsing syntax will be handy so I looked into the erlang sockets module and attempted to write some ffi wrappers for the necessary functions. Turns out it is not as straight forward, especially that the definitions on erlang side are often complex, with many variants and the dynamic nature doesn't often map very well to Gleam. The documentation was also quite sparse for interop. Interop also involves a lot of Dynamic types so encoding/decoding back which is cumbersome. Sooner or later I hit a wall. By virtue of reading Erlang docs to write the ffi wrappers I eventually got familiar with Erlang syntax which at first was quite alien, but turns out it is rather simple with just some rules to remember. I settled on writing Erlang directly. I am not sure how Elixir compares, never tried it, but I was initially put off by the syntax resembling Ruby, which I have fond memories of, but was always very implicit which I didn't like. Writing pure gleam is pretty fun, but a lot of interesting things require either ffi interop or decoders/encoders even for simple things like json which takes away some of that fun.
- jshreder 1y ago
  If you're enjoying erlang, I highly recommend giving elixir a spin. Maybe take a look at a Phoenix tutorial. Such a joy of a lang to work in. And NIFs in erlang and elixir are so nice re: ffi. OTP is just a great platform.
- lawn 1y ago
  The semantics of Elixir are much closer to Erlang than Gleam is and Elixir handles dynamic types on the same manner as Erlang, so interop is very seamless (much more than with Gleam). Don't pay too much mind on the ruby-like syntax. I also prefer the syntax of Gleam, but Elixir really isn't bad when you get used to it. JSON handling in Gleam was also something that annoyed me and made be scrap a hobby project and go with Elixir instead. I wish they had a proper macro system so you could derive json encoding/decoding like you do in Rust...
makemethrowaway 1y ago
Is there any beam language that has regular 'for','while' loops and good OTP support?
- ahf8Aithaex7Nai 1y ago
  Just write 'for' and 'while' yourself if you need it. Here is ‘for’ in Elm/Gren: for : Int -> Int -> Int -> (Int -> msg) -> List msg for start stop step action = let range = if step > 0 then List.range start (step) (stop - 1) else if step < 0 then List.range stop (abs step) (start - 1) |> List.reverse else [] in List.map action range It should be just as trivial to write this in Gleam.
- shawa_a_a 1y ago
  I think that's going to be hard to find, depending on your definition of 'regular', tbh. The BEAM's grown up along with Erlang and so the culture and optimisations are built up all around function application, list processing, recursion, and pattern matching etc. https://github.com/llaisdy/beam_languages https://github.com/llaisdy/beam_languages is a decent list of the diverse languages that have been implemented on it, but nothing quite like 'regular for and while loops'. The BEAM itself is a plain aul register machine though, so it could be done! https://www.erlang.org/blog/a-brief-beam-primer/ https://www.erlang.org/blog/a-brief-beam-primer/
- lpil 1y ago
  No, the VM is functional and immutable so you cannot implement things like `while` on it efficiently. It is highly optimised for the functional immutable style of programming.

197 points by TheWiggles 1y ago

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.

akudha 1y ago
For someone who hasn’t worked with either, is it better to learn gleam/lustre better or elixir/phoenix?
- rapind 1y 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.
- the-grump 1y ago
  My path is a little different. I have used Haskell, and I'm looking to get into OTP. My original plan was either Elixir or vanilla Erlang depending on which one suits my sensibilities better. Reading about Gleam recently has me super, super excited. That's definitely going to be my path now. I don't know if Gleam is the best entry into the world of rich types that you find in a language like Haskell--I'm yet to actually build something with it. What I can tell you is that Haskell is a complete joy to use and it honestly ruins most other programming for me. So as a direction, I cannot recommend it enough, and I'm hoping, for my sake and yours, that Gleam offers a similarly stimulating sandbox. Just a warning that it will take time to get used to "higher-kinded" types. It's an exercise in head scratching and frustration at first. The reward part arrives when you start thinking in types yourself and you know which ones to reach for and when you find the libraries you want by entering a signature on Hoogle.
  - raphinou 1y ago
    Interesting! I have a F# background, and thought to have read that some constructs I learned to appreciate are not available in Gleam (the one I can think of right now is currying, but I thought there were others). Also, Gleam otp didn't seem to be a priority. What's your experience regarding these 2 points?
    - innocentoldguy 1y ago
      The issue isn't that OTP isn't a priority for Gleam, but rather that it doesn't work with the static typing Gleam is implementing. This is why they've had to reimplement their own OTP functionality in gleam_otp. Even then, gleam_otp has some limitations, like being unable to support all of OTP's messages, named processes, etc. gleam_otp is also considered experimental at this point.
      - 59nadir 1y ago
        Having Erlang-style OTP support (for the most part) is very doable, I've written my own OTP layer instead of the pretty shoddy stuff Gleam ships with. It's not really that challenging of a problem and you can get stuff like typed processes (`Pid(message_type)`, i.e. we can only send `message_type` messages to this process), etc. out of it very easily. This idea that static typing is such a massive issue for OTP style servers and messaging is a very persistent myth, to be honest; I've created thin layers on top of OTP for both `purerl` (PureScript compiled to Erlang) and Gleam that end up with both type-safe interfaces (we can only send the right messages to the processes) and are type-safe internally (we can only write the process in a type-safe way based on its state and message types).
        innocentoldguy 1y ago
        I wholeheartedly agree with you that gleam_otp is janky. Still, actor message passing is only part of the picture. Here are some issues that make static typing difficult in OTP: • OTP processes communicate via the actor model by sending messages of any type. Each actor is responsible for pattern-matching the incoming message and handling it (or not) based on its type. To implement static typing, you need to know at compile time what type of message an actor can receive, what type it will send back, and how to verify this at compile time. • OTP's GenServer behaviour uses callbacks that can return various types, depending on runtime conditions. Static typing would require that you predefine all return types for all callbacks, handle type-safe state management, and provide compile-time guarantees when handling these myriad types. • OTP supervisors manage child processes dynamically, which could be of any type. To implement static typing, you would need to know and define the types of all supervised processes, know how they are going to interact with each other, and implement type-safe restart strategies for each type. These and other design roadblocks may be why Gleam chose to implement primitives, like statically typed actors, instead of GenServer, GenStage, GenEvent, and other specialized OTP behaviours, full supervisor functionality, DynamicSupervisor, and OTP's Registry, Agent, Task, etc. OTP and BEAM are Erlang and Elixir's killer features, and have been battle-tested in some of the most demanding environments for decades. I can't see the logic in ditching them or cobbling together a lesser, unproven version of them to gain something as mundane as static typing. EDIT: I completely missed the word "actor" as the second word in my second sentence, so I added it.
- Munksgaard 1y ago
  As someone who comes from Haskell/ML-like languages, I decided to opt for Elixir and Phoenix for my latest project, simply because of the maturity of the web framework and LiveView. If I weren't building a web app, I'd probably have gone with Gleam instead. Edit: I do miss static typing, but it's worth it to not have to reinvent the web framework wheels myself.
- innocentoldguy 1y ago
  In my opinion, Elixir and Phoenix will give you a better experience with BEAM and OTP, excellent tooling, a more mature ecosystem, and one of the best web frameworks ever to exist. I think Gleam is cool, but I can't see trading these benefits in for static typing. To be fair, I can't think of anything I care less about than static typing, so please keep that in mind when entertaining my opinion.
  - raphinou 1y ago
    I also preferred dynamic typing, until my complex rails app grew to the point I didn't dare to do any refactoring. But I didn't switch opinion until I discovered ML type systems, which really allow for fearless refactoring. At occasion there's some battling to satisfy the typesystem, but even with that I'm more productive once the app grows in complexity. I thought I'd share my experience, not trying to convince anyone ; - )
- MDTHLN 1y ago
  I love Gleam, but I would start with Elixir if you're interested in learning about how powerful the BEAM & OTP are. There's not much documentation/resources around OTP in Gleam. When I was playing around with it I often found myself referring to the Elixir docs and then 'translating' that knowledge to Gleam's OTP implementation. Gleam is still very new so this is totally understandable, and both are great languages so you'll likely have a lot of fun learning either of them.
  - 59nadir 1y ago
    Erlang is a much better language to learn if you're interested in learning about the BEAM and OTP, and the book "Programming Erlang"[0] is an excellent resource for learning it. 0 - https://pragprog.com/titles/jaerlang2/programming-erlang-2nd-edition/ https://pragprog.com/titles/jaerlang2/programming-erlang-2nd...
    - _acco 1y ago
      I disagree. I started with Elixir and its OTP resources are really good. Books like Elixir in Action do a great job. I read Programming Erlang later, but it was just for fun, and I knew most things already at that point.
      - 59nadir 1y ago
        I've used Elixir since 2015 and in fact learned it first. I still think "Programming Erlang" is a much better book than any other for actually learning Erlang and BEAM/OTP principles. Erlang as a language is simpler, leaving more time and energy for learning the actual important bits about OTP.
        Miner49er 1y ago
        Also Elixir abstracts even more of the OTP and does some automagical stuff with it. Erlang is more explicit, which is better for learning, IMO.
- victorbjorklund 1y ago
  Gleam is cool but honestly for now the ecosystem is so much bigger in Elixir. And yes, you can use some libraries across and things like that, but then again you could also bring in the parts that you need from Gleam into Elixir and instead of vice versa. If you just want to learn a really cool language, I think Gleam is pretty cool. But if you want to learn a language that is more productive but still kind of cool, I would start really like here and then dip my toes into Gleam.
sureglymop 1y ago
Same and I like it too so far! Some thoughts so far: Installing gleam installed about 50 packages on my system (possibly all erlang/elixir related). But what if I just wanted to transpile to js? Perhaps this is a packaging issue on my system though. What I really wish is that Lua would be considered as another transpilation target. I think gleam could shine for DSLs in other programs but embedding Lua is 3x easier than embedding a js runtime imo. In general, I find the nicest thing so far the community. And I want to say that the quality of libraries and resources in the gleam community seems exceptionally high. It reminds me of the rust community insofar as that for most hard problems someone smarter than me has already worked on it and published a good solution (e.g. lustre, squirrel). Then I would say you can also expect a lot of creativity and experimentation, the things that may fly under the radar in larger language ecosystems stand out here due to the growing and welcoming community.
- hayleighdotdev 1y ago
  > Perhaps this is a packaging issue on my system though. Gleam is only officially distributed via the releases on GitHub [1] so if you pick up Gleam from a package manager that's always maintained by someone else. I think most of those community distributions do include Erlang and bits which is probably what pulled in all those extra packages! [1]: https://github.com/gleam-lang/gleam/releases/tag/v1.13.0 https://github.com/gleam-lang/gleam/releases/tag/v1.13.0
truculent 1y ago
I like all of the above but have no understanding of the BEAM or OTP. Can you recommend a good place to start learning about that?
- Joel_Mckay 1y ago
  In general, I found starting with a Erlang/Elixir framework tutorial helps. Phoenix includes a generic wrapper on top of PostgreSQL (Ecto provides data mapping and language integrated query), and hit a surprising number of users per host with trivial code (common game engine back-end.) https://www.phoenixframework.org/ https://www.phoenixframework.org/ https://www.amazon.com/Programming-Phoenix-Productive-Reliable-Fast/dp/1680501453 https://www.amazon.com/Programming-Phoenix-Productive-Reliab... If you don't run away from a framework intro, then dive into the details of the OTP: https://www.amazon.com/Designing-Elixir-Systems-OTP-Self-healing/dp/1680506617 https://www.amazon.com/Designing-Elixir-Systems-OTP-Self-hea... https://www.amazon.com/Elixir-Action-Third-Sa%C5%A1a-Juric/dp/1633438511 https://www.amazon.com/Elixir-Action-Third-Sa%C5%A1a-Juric/d... The only foot-gun I would initially avoid, is a fussy fault-tolerant multi-host cluster deployment. Check out RabbitMQ package maintainers, as those guys certainly offer a fantastic resource for students ( https://www.rabbitmq.com/docs/which-erlang https://www.rabbitmq.com/docs/which-erlang .) Best of luck =3

hackingonempty 1y 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.

isodev 1y 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.
- hackingonempty 1y 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.
  - isodev 1y 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).
  - g8oz 1y ago
    Unpopular as opposed to what, Scala/Zio?
  - signa11 1y 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 !

isodev 1y ago

Very cool! Looking forward to trying it out.

hackingonempty 1y 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.

behnamoh 1y ago
The website and gh repo say it compiles to JS. Where did you learn that it has an Erlang backend?
- seivan 1y ago
  [dead]
- megabluejay 1y ago
  https://github.com/purescript/documentation/blob/master/ecosystem/Alternate-backends.md https://github.com/purescript/documentation/blob/master/ecos...
  - tiffanyh 1y 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 https://github.com/purerl/purerl
    - sarchertech 1y ago
      I think that’s just confusing wording. It sounds like it’s a backend for the Purescript compiler that generates Erlang.
lpil 1y ago
The JS backend is mature, but the Erlang backend and accompanying ecosystem is very small compared to Gleam.

cedws 1y ago

I’m fascinated by the sound of Erlang/BEAM but I’ve never found the time to actually try it. How are people using it in production? Do you write all your service logic using it or delegate specific parts to it?

jnmandal 1y ago
I've seen folks doing both. Certainly, once you understand the OTP well enough, it makes sense to build all your systems on it. I've been doing that for seven years now; the only real issue was trying to train juniors to be productive on those systems. It did take longer to get them going I found.
davydog187 1y ago
We use Elixir at TV Labs to build our web services, a realtime matching engine, execute sandboxed Lua code, talk to microcontrollers over binary protocols, machine learning, and much more. It is an excellent general purpose language that succeeds in a lot of domains. Check out my conversation from Developer Voices for more info https://youtu.be/_MwXbHADT-A?si=2lRqjwAY9dsODyhW https://youtu.be/_MwXbHADT-A?si=2lRqjwAY9dsODyhW
josefrichter 1y ago
Come and have a chat at elixirforum.com. Plenty of folks write serious stuff entirely/predominantly in Erlang/Elixir & BEAM and will be happy to answer your questions.
- cedws 1y ago
  Thank you!
sethhochberg 1y ago
I'm leading a team that is doing an incremental migration to Gleam by delegating specific parts - we're basically pushing the "functional core, imperative shell" pattern to its macro extreme and having Gleam pick up background jobs from our existing Ruby on Rails codebases where we have heavy calculation tasks. This approach is notably not making proper or really any use of OTP features, but it was an extremely easy way to adopt a safe, fast, functional language for number-crunching workflows while continuing to lean on Rails for everything else its great at: web interfaces, HTTP APIs, etc. Rails is basically the configuration tool for the various inputs of a job, and job is passed to Gleam via Redis as an atomic set of config inputs to be used when processing a dataset (usually big CSV files streamed from object storage). We use a very thin Elixir wrapper to do all network and file IO etc, Gleam modules are pure business logic called from Elixir. Some day soon, I'm going to try and write up a longer technical article about this approach... it comes up surprisingly often in HN conversations.

constructive 1y ago

gleam would be taken more seriously if they didnt plaster their strong political opinions on the project page..i do not understand why they need to talk about politics on a tech project page..this is not about agreeing or disagreeing with the viewpoints..just keep it out of your professional discourse if you want people to take you or your work seriously...otherwise it just deviates the discourse unnecessarily

timeon 1y ago
> otherwise it just deviates the discourse unnecessarily You could have chosen not to deviate the discourse.
whalesalad 1y ago
"Black lives matter. Trans rights are human rights. No nazi bullsh*t." Plaster? Are you referring to this singular line of text way down on their main page? If this statement precludes you from using the project I would imagine it is working as intended.
deleted 1y ago
[deleted]

giancarlostoro 1y ago

For all you wonderful people using Gleam, do you use Phoenix? Or any other web frameworks? I really would love to do Gleam with something like Phoenix, but I have not had enough time to check out all the options yet. I'm in the process of building a new project with Python, but if there's options with Gleam worth looking into I just might try it out for this new project.

roxolotl 1y ago
There isn’t really anything like Phoenix or Django or Rails. There are a set of tools though that are commonly used to build web apps. Lustre is the primary view tool. Wisp is the server. And then squirrel and POG, newer but people seem to like it, are used for sql. - squirrel: https://github.com/giacomocavalieri/squirrel https://github.com/giacomocavalieri/squirrel - Lustre: https://github.com/lustre-labs/lustre https://github.com/lustre-labs/lustre - Wisp: https://github.com/gleam-wisp/wisp https://github.com/gleam-wisp/wisp
widdershins 1y ago
There's a talk from Lustre's developer about doing LiveView-type things with Gleam/Lustre. The promise is that you can easily pick and choose which parts of your app run on the client, and which run on the server. https://www.youtube.com/watch?v=TbCm-zR7qZ0 https://www.youtube.com/watch?v=TbCm-zR7qZ0

candl 1y ago

I learned some Gleam a while ago, my familarity with F# helped, but I didn't find a use case for it. Some while ago I wanted to play with raw sockets so I figured, why not Gleam, its binary parsing syntax will be handy so I looked into the erlang sockets module and attempted to write some ffi wrappers for the necessary functions. Turns out it is not as straight forward, especially that the definitions on erlang side are often complex, with many variants and the dynamic nature doesn't often map very well to Gleam. The documentation was also quite sparse for interop. Interop also involves a lot of Dynamic types so encoding/decoding back which is cumbersome. Sooner or later I hit a wall. By virtue of reading Erlang docs to write the ffi wrappers I eventually got familiar with Erlang syntax which at first was quite alien, but turns out it is rather simple with just some rules to remember. I settled on writing Erlang directly. I am not sure how Elixir compares, never tried it, but I was initially put off by the syntax resembling Ruby, which I have fond memories of, but was always very implicit which I didn't like. Writing pure gleam is pretty fun, but a lot of interesting things require either ffi interop or decoders/encoders even for simple things like json which takes away some of that fun.

jshreder 1y ago
If you're enjoying erlang, I highly recommend giving elixir a spin. Maybe take a look at a Phoenix tutorial. Such a joy of a lang to work in. And NIFs in erlang and elixir are so nice re: ffi. OTP is just a great platform.
lawn 1y ago
The semantics of Elixir are much closer to Erlang than Gleam is and Elixir handles dynamic types on the same manner as Erlang, so interop is very seamless (much more than with Gleam). Don't pay too much mind on the ruby-like syntax. I also prefer the syntax of Gleam, but Elixir really isn't bad when you get used to it. JSON handling in Gleam was also something that annoyed me and made be scrap a hobby project and go with Elixir instead. I wish they had a proper macro system so you could derive json encoding/decoding like you do in Rust...

makemethrowaway 1y ago

Is there any beam language that has regular 'for','while' loops and good OTP support?

ahf8Aithaex7Nai 1y ago
Just write 'for' and 'while' yourself if you need it. Here is ‘for’ in Elm/Gren: for : Int -> Int -> Int -> (Int -> msg) -> List msg for start stop step action = let range = if step > 0 then List.range start (step) (stop - 1) else if step < 0 then List.range stop (abs step) (start - 1) |> List.reverse else [] in List.map action range It should be just as trivial to write this in Gleam.
shawa_a_a 1y ago
I think that's going to be hard to find, depending on your definition of 'regular', tbh. The BEAM's grown up along with Erlang and so the culture and optimisations are built up all around function application, list processing, recursion, and pattern matching etc. https://github.com/llaisdy/beam_languages https://github.com/llaisdy/beam_languages is a decent list of the diverse languages that have been implemented on it, but nothing quite like 'regular for and while loops'. The BEAM itself is a plain aul register machine though, so it could be done! https://www.erlang.org/blog/a-brief-beam-primer/ https://www.erlang.org/blog/a-brief-beam-primer/
lpil 1y ago
No, the VM is functional and immutable so you cannot implement things like `while` on it efficiently. It is highly optimised for the functional immutable style of programming.