1. 49
  1.  

  2. 11

    There’s no overhead compared to calling regular Erlang code, and the generated APIs are idiomatic Erlang.

    Any Gleam packages published to Hex (the BEAM ecosystem package manager) now includes the project code compiled to Erlang. Once the various build tools of the other languages have been updated they will be able to depend on packages written in Gleam without having the Gleam compiler installed.

    We want to fit into the wider ecosystem so smoothly that Erlang and Elixir programmers might not even know they’re using Gleam at all! All they need to know is that the library they are using is rock-solid and doesn’t fail on them.

    This is awesome! It’s really a shame that Elixir never did this. All the Elixir libraries are really painful to use in Erlang projects. I intentionally use Erlang for the open source libraries I’ve created so they are usable from all languages built on the VM.

    1. 5

      You feel exactly the same way I do! There’s so much good stuff in Elixir I wish the other languages could use.

      1. 1

        What are some other notable languages on the BEAM runtime? I’m only aware of Elixir, Erlang, and Gleam.

        1. 2

          Elixir and Erlang are the big ones but the other ones that get used in production that I’m aware of are LFE, Purerl, Hamler, and Luerl

          1. 1

            I’ll have to look into those languages. Thanks!

      2. 2

        It’s really a shame that Elixir never did this. All the Elixir libraries are really painful to use in Erlang projects.

        Aside from needing an Elixir compiler in all cases, and not being able to use Elixir macros (not Elixir’s fault!), where is the pain point? I am on the Elixir side 99.9% of the time so I don’t see it.

        1. 5

          There’s a few things:

          • The Elixir compiler and standard library need to be installed, but they’re not on Hex unlike everything else, you don’t get declarative version resolution when installing them, and they increase the bytecode size quite a lot.
          • The Elixir compilation process has a final step that needs to run last in order to optimise protocols, so you’ll need to wrap or modify your build tool in some way to do this.
          • The Elixir module names and some function names use characters that require quoting in atoms so the function calls look rather strange 'Elixir.Project.Module':'active?'(X).
          • Many APIs use macros when they could be functional, making them unsable from other languages.

          These are not huge barriers, but if you use a library written in Erlang (or in future Gleam) you don’t have to worry about any of this. You add it to your list of deps and that’s it.

          1. 4

            I think you missed my point. It’s troublesome when you want to use Elixir libraries from Erlang, or from any other language on the Erlang VM. The overhead and hassle of retrofitting an existing project with support for Elixir compilation makes it not worth the effort. Thus I stick with Erlang because I need to write code that can be used from any language on the VM.

            1. 2

              It could be (and probably is) pretty easy to use one of the existing rebar3 plugins for using Elixir from a Erlang project. Take https://github.com/barrel-db/rebar3_elixir_compile as an example integration. I haven’t used it, but it looks pretty straight forward. I still wonder how any configuration would be wired together, but that should be pretty reasonable to write if needed.

              Beyond the build system, I imagine Elixir code doesn’t feel ergonomic in other languages. It’s function argument ordering differs from a lot of functional languages, the pervasive use of structs in library APIs, the use of capitalization for modules doesn’t read well, and the constant prefix of 'Elixir.AppModue':some_function(). all make it less appealing.

              All together it’s just enough hassle to use outside of Elixir, and often that bit of work + usability issues isn’t worth it.

          2. 5

            (meta) Thanks for adding the short description of the project in the title, makes the list of articles here a bit easier to scroll through.