3 ms·

Gleam runs on the BEAM

by vereis 2y ago

atemerev 2y ago
It does. However, its actor implementation is not built upon Erlang/OTP, and currently is “experimental” and not even mentioned on the main site.
- lolinder 2y ago
  > its actor implementation is not built upon Erlang/OTP This seems to be the opposite of pragmatic. The most pragmatic approach to actors when you're building a BEAM language would be to write bindings for OTP and be done with it. This sounds kind of like building a JVM language with no intention of providing interop with the JVM ecosystem—yeah, the VM is good, but the ecosystem is what we're actually there for. If you're building a BEAM language, why would you attempt to reimplement OTP?
  - arcanemachiner 2y ago
    I believe their implementation was written to support static typing (since Gleam is a statically-typed language).
  - okkdev 2y ago
    Because of type safety. The OTP lib is already great, but there are still some things missing, most requested being named processes. But there is work being done to figure out how to best make it work for gleam.
    - lolinder 2y ago
      The question of type safety has come up so often here that I guess it's worth replying: That's exactly what I mean by this not seeming pragmatic. Pragmatic would be making do with partial type safety in order to be fully compatible with OTP. That's the much-maligned TypeScript approach, and it worked for TypeScript because it was pragmatic. Now, maybe Gleam feels the need to take this approach because Elixir is already planning on filling the pragmatic gradually-typed BEAM language niche. That's fine if so!
      - okkdev 2y ago
        Type safety is one of the goals of the language I don't see a reason to throw it out of the window now. I see what you mean, but the type system is one of the things that makes gleam pragmatic. If you really need some missing OTP feature you can super easily step into Erlang using FFI and get it. That's one of the reasons the article doesn't call gleam pure.
      - lpil 2y ago
        Gleam does not sacrifice OTP compatibility for type safety. It picks both.
      - giraffe_lady 2y ago
        And what has this approach gotten them? A language as complex as c++ and haskell combined, but that still has runtime type errors. A typescript backlash is coming.
  - H12 2y ago
    IIRC the re-implementation was necessary for type-safety.
  - pmontra 2y ago
    I agree with the part about reusing OTP but some of the server syntax of Erlang and Elixir is not good IMHO. I never liked using those handle_* functions. Give them proper names and you cover nearly all the normal usage, which is mutating the internal state of a process (an object in other families of languages.) That would be the pragmatic choice, to lure Java, C++ programmers.
    - throwawaymaths 2y ago
      Elixir gives you Agent, which is what you want, but for reasons, Agent is a bad choice. What you're not seeing with the handle_* functions is all the extra stuff in there that deals with, for example, "what if the thing you want to access is unavailable?". That's not really something that for example go is able to handle so easily.
    - toast0 2y ago
      What would be the proper name to handle a call other than handle_call?
      - pmontra 2y ago
        This is Elixir syntax, not Gleam: Instead of defmodule Robot do def handle_call(:get_state, _from, state) do something() end def get_state() do GenServer.call(__MODULE__, :get_state) end end robot = Robot.start_link() robot.get_state() just let me write (note the new flavor of def) defstatefulmodule Robot do def get_state() do something() end end robot = Robot.new() robot.get_state() Possibly add a defsync / defasync flavor of function definition to declare when the caller has to wait for the result of the function. The idea is that I don't have to do the job of the compiler. It should add the boilerplate during the compilation to BEAM bytecode. I know that there are a number of other possible cases that the handle_* functions can accommodate and this code does not, but this object-oriented-style state management is the purpose of almost all the occurrences of GenServers in the code bases I saw. Unfortunately it's littered by handle_* boilerplate that hides the purpose of the code and as all code, adds bugs by itself. So: add handle_* to BEAM languages for maximum control but also add a dumbed down version that's all we need almost anytime.
  - deleted 2y ago
    [deleted]
  - lpil 2y ago
    It uses the same primitives as Erlang, the difference is that it exposes type safe APIs instead of untyped ones which you would get from using the Erlang abstractions. It implements the same protocols and does not have any interop shortcomings.
- lpil 2y ago
  It is production ready and has been used for numerous non-trivial projects. Experimental in this context means there is expected to be API changes and feature additions in future.

Gleam runs on the BEAM

by vereis 2y ago

Gleam runs on the BEAM

It does. However, its actor implementation is not built upon Erlang/OTP, and currently is “experimental” and not even mentioned on the main site.

lolinder 2y ago
> its actor implementation is not built upon Erlang/OTP This seems to be the opposite of pragmatic. The most pragmatic approach to actors when you're building a BEAM language would be to write bindings for OTP and be done with it. This sounds kind of like building a JVM language with no intention of providing interop with the JVM ecosystem—yeah, the VM is good, but the ecosystem is what we're actually there for. If you're building a BEAM language, why would you attempt to reimplement OTP?
- arcanemachiner 2y ago
  I believe their implementation was written to support static typing (since Gleam is a statically-typed language).
- okkdev 2y ago
  Because of type safety. The OTP lib is already great, but there are still some things missing, most requested being named processes. But there is work being done to figure out how to best make it work for gleam.
  - lolinder 2y ago
    The question of type safety has come up so often here that I guess it's worth replying: That's exactly what I mean by this not seeming pragmatic. Pragmatic would be making do with partial type safety in order to be fully compatible with OTP. That's the much-maligned TypeScript approach, and it worked for TypeScript because it was pragmatic. Now, maybe Gleam feels the need to take this approach because Elixir is already planning on filling the pragmatic gradually-typed BEAM language niche. That's fine if so!
    - okkdev 2y ago
      Type safety is one of the goals of the language I don't see a reason to throw it out of the window now. I see what you mean, but the type system is one of the things that makes gleam pragmatic. If you really need some missing OTP feature you can super easily step into Erlang using FFI and get it. That's one of the reasons the article doesn't call gleam pure.
    - lpil 2y ago
      Gleam does not sacrifice OTP compatibility for type safety. It picks both.
    - giraffe_lady 2y ago
      And what has this approach gotten them? A language as complex as c++ and haskell combined, but that still has runtime type errors. A typescript backlash is coming.
- H12 2y ago
  IIRC the re-implementation was necessary for type-safety.
- pmontra 2y ago
  I agree with the part about reusing OTP but some of the server syntax of Erlang and Elixir is not good IMHO. I never liked using those handle_* functions. Give them proper names and you cover nearly all the normal usage, which is mutating the internal state of a process (an object in other families of languages.) That would be the pragmatic choice, to lure Java, C++ programmers.
  - throwawaymaths 2y ago
    Elixir gives you Agent, which is what you want, but for reasons, Agent is a bad choice. What you're not seeing with the handle_* functions is all the extra stuff in there that deals with, for example, "what if the thing you want to access is unavailable?". That's not really something that for example go is able to handle so easily.
  - toast0 2y ago
    What would be the proper name to handle a call other than handle_call?
    - pmontra 2y ago
      This is Elixir syntax, not Gleam: Instead of defmodule Robot do def handle_call(:get_state, _from, state) do something() end def get_state() do GenServer.call(__MODULE__, :get_state) end end robot = Robot.start_link() robot.get_state() just let me write (note the new flavor of def) defstatefulmodule Robot do def get_state() do something() end end robot = Robot.new() robot.get_state() Possibly add a defsync / defasync flavor of function definition to declare when the caller has to wait for the result of the function. The idea is that I don't have to do the job of the compiler. It should add the boilerplate during the compilation to BEAM bytecode. I know that there are a number of other possible cases that the handle_* functions can accommodate and this code does not, but this object-oriented-style state management is the purpose of almost all the occurrences of GenServers in the code bases I saw. Unfortunately it's littered by handle_* boilerplate that hides the purpose of the code and as all code, adds bugs by itself. So: add handle_* to BEAM languages for maximum control but also add a dumbed down version that's all we need almost anytime.
- deleted 2y ago
  [deleted]
- lpil 2y ago
  It uses the same primitives as Erlang, the difference is that it exposes type safe APIs instead of untyped ones which you would get from using the Erlang abstractions. It implements the same protocols and does not have any interop shortcomings.
lpil 2y ago
It is production ready and has been used for numerous non-trivial projects. Experimental in this context means there is expected to be API changes and feature additions in future.