5 ms·

As Elixir is getting its own type system, should one still pick Gleam over Elixir?

by akudha 2y ago

hayleighdotdev 2y ago
They're kind of solving different problems. It's a bit like TypeScript vs Elm or PureScript: one is a type system overlaid onto an existing language with its own rich ecosystem and set of idioms, and the other is a new language that targets the same underlying platform but has different idioms and semantics for static analysis. If you already have lots of Elixir in production, or you enjoy Elixir's highly dynamic approach to solving problems and would like to get some additional safety for free then sticking with Elixir is a no-brainer! If you'd like a simpler language with tighter static analysis guarantees while still being able to dip into the wider ecosystem then you might prefer Gleam. Ultimately I think the two languages have very different philosophies and idioms, folks will naturally find themselves preferring one or the other ^.^
- tmountain 2y ago
  Gleam is about as simple as Go but with a more expressive type system and Elm style guarantees that your app won’t crash if you stay in its ecosystem.
bmitc 2y ago
I find it unfortunate. The BEAM is so influential as a VM, that most languages on top of it will be very similar. I don't really like the situation where we have Erlang, Elixir, and Gleam all atop the same VM, and they're all basically the same language. It's a split that isn't needed.
- juped 2y ago
  Gleam is nothing like Erlang or Elixir (its copying of Rust is so slavish it even has a toml file driven build system) and Erlang and Elixir are not split (the only place where they even sorta are is rebar vs. mix). I don't particularly want to gatekeep "Rust fans who just want to write lots of Rust" off OTP. Let them have Gleam. Maybe they'll figure out how to lifetime-annotate binaries?
  - tomtheelder 2y ago
    Gleam and Rust are really not alike at all aside from the most superficial ways. A couple bits of syntax, and the use of toml are about all I can come up with.
    - deleted 2y ago
      [deleted]
  - worthless-trash 2y ago
    > Maybe they'll figure out how to lifetime-annotate binaries? What do you mean by this, I know how lifetimes work in rust, but how would you do it on the binary level ?
    - juped 2y ago
      Binary is Erlangese for Vec<u8>, hope that helps
      - worthless-trash 2y ago
        There are no lifetimes in gleam though right ? or did i miss the memo.
        juped 2y ago
        maybe they can add them to guard against copying large binaries too much
        hayleighdotdev 2y ago
        No lifetimes, absolutely no plans to add anything similar. We’re nothing like rust!
- lpil 2y ago
  Hi, I'm the designer of Gleam! Beyond being functional and sharing a runtime I don't think Elixir and Gleam have much in common at all. Our recent developer survey showed that the majority of Gleam programmers were not Elixir users and largely were not attracted to that language.
  - bmitc 2y ago
    My question is: is how one approaches writing programs in Erlang, Elixir, and Gleam fundamentally different from one another? And is the difference enough for the split in the ecosystem? > Our recent developer survey showed that the majority of Gleam programmers ... largely were not attracted to that language. I must admit that I find that fairly bizarre. What do you imagine the source of that lack of desire is? For context, my favorite language is F# and ML-dialects in general, but I also like what I call "principled" dynamically typed languages like Scheme, Racket, Erlang, and Elixir.
    - lpil 2y ago
      Yes, they are very different. It's not splitting the ecosystem though as the vast majority of Gleam programmers are not former Elixir, Erlang, or LFE programmers, it's people coming from other ecosystems. Gleam grows the BEAM ecosystem by bringing people in from elsewhere who were not interested in writing Elixir, Erlang, or LFE. > I must admit that I find that fairly bizarre. What do you imagine the source of that lack of desire is? They're just very different languages to work with. The programming experience is very different.
- tmountain 2y ago
  There are TONS of JVM languages and nobody is complaining about that. BEAM is much smaller and a very nice target IMO. I learned Erlang but found it too weird for my tastes. Elixir lacked a type system when I evaluated it, and that steered me away from it. Gleam feels kind of like Elm felt. Small, simple, and safe. It feels very intentional and designed for a particular purpose and audience. I did their online tutorial and felt comfortable with the language in one sitting. Can’t say that for many other languages.
  - bmitc 2y ago
    Who is choosing anything but Kotlin for new projects on the JVM? The point is that beyond some basic typing things, programs written in Erlang, Elixir, and Gleam will all have the same core structure. Immutable data plus pattern matching plus BEAM processes has a pretty strong affect on any BEAM language.
    - tmountain 2y ago
      > Who is choosing anything but Kotlin for new projects on the JVM? I dunno... Scala, Clojure, and Groovy users? Small user bases, but the languages are not dead.
      - bmitc 2y ago
        That's kind of my point. Does the JVM really need four different general purpose languages with their own ecosystems to split the JVM ecosystem and userbase?
        Alupis 2y ago
        Why not? There's like 483 different application frameworks for the JVM too. The more choices the better - it lets ideas cross-pollinate, and the best ideas get borrowed/stolen. Some people like different syntax, bindings, etc. I find the opposite more troubling, actually. Take the C# ecosystem and see how there's one de-facto application framework (.NET), one logging lib, one etc... It's usually Microsoft's way or the highway, and 3rd party libraries and frameworks struggle to get any adoption. Consequently, that ecosystem is much smaller, less diverse, and less innovative.
sodapopcan 2y ago
I'm not fully qualified but in a nutshell, Gleam doesn't support OTP out of the box. There is a separate package for it [0] but it doesn't offer everything, so it depends on your needs. If you're going to be doing heavy OTP stuff you'll need to stick with Elixir. If you want to transpile to JS, then Gleam is the better choice. Otherwise it's up to your tastes around type systems and syntax. [0] https://github.com/gleam-lang/otp https://github.com/gleam-lang/otp
- lpil 2y ago
  Gleam isn't different from Erlang or Elixir in this case, all three languages implement OTP in "user land" rather than being part of the language. The only difference is how this OTP code gets distributed from the core team to you. In Gleam the BEAM ecosystem package manager is used, Elixir and Erlang leave it up to the operating system package manager, a docker container, or some other solution.
  - sodapopcan 2y ago
    > all three languages implement OTP in "user land" rather than being part of the language I understand that, but why then is OTP then limited on Gleam? Is interop to Erlang different than it is in Elixir? Elixir doesn't offer Elixir versions of a *lot* of OTP, but its Erlang interop feels quite natural (though not seamless). Can you just farm out to Erlang in Gleam? Does Gleam's static typing hinder this at all? Of course I can look this up for myself, but figured I'd asked here for the benefit of others since you're the author of Gleam :)
    - lpil 2y ago
      It’s not limited in Gleam. All existing Erlang and Elixir OTP modules are usable in Gleam, and there’s also an additional set of Gleam OTP modules which provide type safety guarantees for a subset of OTP functionality.
      - dqv 2y ago
        I think what they mean that the Gleam OTP implementation has some caveats - the two that jump out at me is not supporting named processes and not supporting all OTP system messages. Named processes, though, could be implemented like Elixir's Registry, but gleamically. Something that takes a type and returns a PID. Then the process gets named with a via-tuple that calls Gleam's registry.

As Elixir is getting its own type system, should one still pick Gleam over Elixir?

by akudha 2y ago

As Elixir is getting its own type system, should one still pick Gleam over Elixir?

They're kind of solving different problems. It's a bit like TypeScript vs Elm or PureScript: one is a type system overlaid onto an existing language with its own rich ecosystem and set of idioms, and the other is a new language that targets the same underlying platform but has different idioms and semantics for static analysis. If you already have lots of Elixir in production, or you enjoy Elixir's highly dynamic approach to solving problems and would like to get some additional safety for free then sticking with Elixir is a no-brainer! If you'd like a simpler language with tighter static analysis guarantees while still being able to dip into the wider ecosystem then you might prefer Gleam. Ultimately I think the two languages have very different philosophies and idioms, folks will naturally find themselves preferring one or the other ^.^

tmountain 2y ago
Gleam is about as simple as Go but with a more expressive type system and Elm style guarantees that your app won’t crash if you stay in its ecosystem.

bmitc 2y ago

I find it unfortunate. The BEAM is so influential as a VM, that most languages on top of it will be very similar. I don't really like the situation where we have Erlang, Elixir, and Gleam all atop the same VM, and they're all basically the same language. It's a split that isn't needed.

juped 2y ago
Gleam is nothing like Erlang or Elixir (its copying of Rust is so slavish it even has a toml file driven build system) and Erlang and Elixir are not split (the only place where they even sorta are is rebar vs. mix). I don't particularly want to gatekeep "Rust fans who just want to write lots of Rust" off OTP. Let them have Gleam. Maybe they'll figure out how to lifetime-annotate binaries?
- tomtheelder 2y ago
  Gleam and Rust are really not alike at all aside from the most superficial ways. A couple bits of syntax, and the use of toml are about all I can come up with.
  - deleted 2y ago
    [deleted]
- worthless-trash 2y ago
  > Maybe they'll figure out how to lifetime-annotate binaries? What do you mean by this, I know how lifetimes work in rust, but how would you do it on the binary level ?
  - juped 2y ago
    Binary is Erlangese for Vec<u8>, hope that helps
    - worthless-trash 2y ago
      There are no lifetimes in gleam though right ? or did i miss the memo.
      - juped 2y ago
        maybe they can add them to guard against copying large binaries too much
      - hayleighdotdev 2y ago
        No lifetimes, absolutely no plans to add anything similar. We’re nothing like rust!
lpil 2y ago
Hi, I'm the designer of Gleam! Beyond being functional and sharing a runtime I don't think Elixir and Gleam have much in common at all. Our recent developer survey showed that the majority of Gleam programmers were not Elixir users and largely were not attracted to that language.
- bmitc 2y ago
  My question is: is how one approaches writing programs in Erlang, Elixir, and Gleam fundamentally different from one another? And is the difference enough for the split in the ecosystem? > Our recent developer survey showed that the majority of Gleam programmers ... largely were not attracted to that language. I must admit that I find that fairly bizarre. What do you imagine the source of that lack of desire is? For context, my favorite language is F# and ML-dialects in general, but I also like what I call "principled" dynamically typed languages like Scheme, Racket, Erlang, and Elixir.
  - lpil 2y ago
    Yes, they are very different. It's not splitting the ecosystem though as the vast majority of Gleam programmers are not former Elixir, Erlang, or LFE programmers, it's people coming from other ecosystems. Gleam grows the BEAM ecosystem by bringing people in from elsewhere who were not interested in writing Elixir, Erlang, or LFE. > I must admit that I find that fairly bizarre. What do you imagine the source of that lack of desire is? They're just very different languages to work with. The programming experience is very different.
tmountain 2y ago
There are TONS of JVM languages and nobody is complaining about that. BEAM is much smaller and a very nice target IMO. I learned Erlang but found it too weird for my tastes. Elixir lacked a type system when I evaluated it, and that steered me away from it. Gleam feels kind of like Elm felt. Small, simple, and safe. It feels very intentional and designed for a particular purpose and audience. I did their online tutorial and felt comfortable with the language in one sitting. Can’t say that for many other languages.
- bmitc 2y ago
  Who is choosing anything but Kotlin for new projects on the JVM? The point is that beyond some basic typing things, programs written in Erlang, Elixir, and Gleam will all have the same core structure. Immutable data plus pattern matching plus BEAM processes has a pretty strong affect on any BEAM language.
  - tmountain 2y ago
    > Who is choosing anything but Kotlin for new projects on the JVM? I dunno... Scala, Clojure, and Groovy users? Small user bases, but the languages are not dead.
    - bmitc 2y ago
      That's kind of my point. Does the JVM really need four different general purpose languages with their own ecosystems to split the JVM ecosystem and userbase?
      - Alupis 2y ago
        Why not? There's like 483 different application frameworks for the JVM too. The more choices the better - it lets ideas cross-pollinate, and the best ideas get borrowed/stolen. Some people like different syntax, bindings, etc. I find the opposite more troubling, actually. Take the C# ecosystem and see how there's one de-facto application framework (.NET), one logging lib, one etc... It's usually Microsoft's way or the highway, and 3rd party libraries and frameworks struggle to get any adoption. Consequently, that ecosystem is much smaller, less diverse, and less innovative.

sodapopcan 2y ago

I'm not fully qualified but in a nutshell, Gleam doesn't support OTP out of the box. There is a separate package for it [0] but it doesn't offer everything, so it depends on your needs. If you're going to be doing heavy OTP stuff you'll need to stick with Elixir. If you want to transpile to JS, then Gleam is the better choice. Otherwise it's up to your tastes around type systems and syntax. [0] https://github.com/gleam-lang/otp https://github.com/gleam-lang/otp

lpil 2y ago
Gleam isn't different from Erlang or Elixir in this case, all three languages implement OTP in "user land" rather than being part of the language. The only difference is how this OTP code gets distributed from the core team to you. In Gleam the BEAM ecosystem package manager is used, Elixir and Erlang leave it up to the operating system package manager, a docker container, or some other solution.
- sodapopcan 2y ago
  > all three languages implement OTP in "user land" rather than being part of the language I understand that, but why then is OTP then limited on Gleam? Is interop to Erlang different than it is in Elixir? Elixir doesn't offer Elixir versions of a *lot* of OTP, but its Erlang interop feels quite natural (though not seamless). Can you just farm out to Erlang in Gleam? Does Gleam's static typing hinder this at all? Of course I can look this up for myself, but figured I'd asked here for the benefit of others since you're the author of Gleam :)
  - lpil 2y ago
    It’s not limited in Gleam. All existing Erlang and Elixir OTP modules are usable in Gleam, and there’s also an additional set of Gleam OTP modules which provide type safety guarantees for a subset of OTP functionality.
    - dqv 2y ago
      I think what they mean that the Gleam OTP implementation has some caveats - the two that jump out at me is not supporting named processes and not supporting all OTP system messages. Named processes, though, could be implemented like Elixir's Registry, but gleamically. Something that takes a type and returns a PID. Then the process gets named with a via-tuple that calls Gleam's registry.