3 ms·

>It's just so elegant to read and write. Interesting. I was just about to write the opposite. I tried Gleam to solve last year's Advent of Code, and it felt li

>It's just so elegant to read and write. Interesting. I was just about to write the opposite. I tried Gleam to solve last year's Advent of Code, and it felt like a weird mix between Rust and Elixir. You can't write code as elegantly as you'd do in Elixir, which was somewhat disappointing. I switched back to Elixir after a couple of days. I think the biggest advantage of Gleam is static type system.

lpil 1y ago
If you've examples of code you have in Elixir that you could not express well in Gleam I would be very happy to help you out with that. The two languages are almost the same at the value level, so code should translate across well.
Alupis 1y ago
Depending when this was, it was likely pre-1.x days? Things moved very quickly there for a while - it's worth checking back in again. Gleam seems to have a lot of obvious influences from Rust, and the creator is a rust dev. While the Gleam ecosystem is vastly less mature than Elixir's or Rust's (because it's literally younger), the language itself, I've found, is vastly more pleasant to read/write. YMMV of course.
- lpil 1y ago
  > Gleam seems to have a lot of obvious influences from Rust, and the creator is a rust dev. Hi! That's me! Gleam the language doesn't have any Rust influence really. It's a happy accident that some of the syntax ended up looking the same, but that's likely due to both being inspired by similar languages such as OCaml and the C family. Most the syntax and the semantics predate Gleam's compiler being rewritten in Rust. The build tool is a rip-off of Cargo for sure though.
  - Alupis 1y ago
    > The build tool is a rip-off of Cargo for sure though. Hey, great artists steal, as the saying goes... It's all shaped up really nice. I'm a big fan of Gleam and your work in general.
    - lpil 1y ago
      Thank you, very kind.
- zem 1y ago
  more like both gleam and rust have a strong ML influence (gleam might actually consider itself an ML? not sure about that, but it's definitely a descendant)
innocentoldguy 1y ago
I prefer Elixir's syntax over Gleam's, but my main issue with Gleam is architectural. Specifically, Gleam had to bastardize BEAM and OTP to implement static typing. To me, static typing vs. dynamic typing is like having a shelf with a doily vs. one without a doily (the shelf works fine either way), so messing up a solid Actor Model implementation, for instance, for the sake of static typing seems like the wrong thing to do.
- chamomeal 1y ago
  How does it bastardize the beam? Like are there things you can do in elixir/erlang that you couldn’t with gleam?
  - Alupis 1y ago
    I'm curious to know what the parent meant, as well. My understanding, which is incomplete admittedly, is that Gleam's type system lives in Gleam and isn't carried over into the produced Erlang/BEAM code, since BEAM has no concept of types, etc. Gleam also has an OTP implementation[1] available, which includes Actors and the like. My understanding is that every BEAM language must implement OTP themselves, so there's nothing unusual here. [1] https://hexdocs.pm/gleam_otp/ https://hexdocs.pm/gleam_otp/
    - innocentoldguy 1y ago
      Gleam's type system is the root cause of the problem. Please see my reply to the parent of your post.
  - innocentoldguy 1y ago
    It has been a while since I looked at Gleam. Some things may have changed. However, the last time I used Gleam, I was forced to switch back to Elixir because Gleam: • Lacks support for named processes. • Has limited actor abstractions. • Doesn't support OTP system messages. • Has implemented supervisors in a way that can lead to improper shutdowns, data loss, and deviations from the expected BEAM behavior. • Doesn't support pattern matching directly in function definitions. Instead, it requires you to use case statements. • Doesn't support global mutable variables because it has no way to track variable types and state changes when BEAM modifies these variables, which is one of the hallmark features of BEAM. • Doesn't support hot code reloading. All of these features, which are readily available in Erlang and Elixir, are far more important to me than static typing. I've used statically typed languages like C, C++, C#, and Java, and dynamically typed languages like Python, Ruby, and Elixir throughout my 30+ years career. I've never once lamented not having static types, nor have I ever jumped for joy when I do. For me, static vs. dynamic typing is largely irrelevant and doesn't affect my work one way or the other.

lpil 1y ago

If you've examples of code you have in Elixir that you could not express well in Gleam I would be very happy to help you out with that. The two languages are almost the same at the value level, so code should translate across well.

Alupis 1y ago

Depending when this was, it was likely pre-1.x days? Things moved very quickly there for a while - it's worth checking back in again. Gleam seems to have a lot of obvious influences from Rust, and the creator is a rust dev. While the Gleam ecosystem is vastly less mature than Elixir's or Rust's (because it's literally younger), the language itself, I've found, is vastly more pleasant to read/write. YMMV of course.

lpil 1y ago
> Gleam seems to have a lot of obvious influences from Rust, and the creator is a rust dev. Hi! That's me! Gleam the language doesn't have any Rust influence really. It's a happy accident that some of the syntax ended up looking the same, but that's likely due to both being inspired by similar languages such as OCaml and the C family. Most the syntax and the semantics predate Gleam's compiler being rewritten in Rust. The build tool is a rip-off of Cargo for sure though.
- Alupis 1y ago
  > The build tool is a rip-off of Cargo for sure though. Hey, great artists steal, as the saying goes... It's all shaped up really nice. I'm a big fan of Gleam and your work in general.
  - lpil 1y ago
    Thank you, very kind.
zem 1y ago
more like both gleam and rust have a strong ML influence (gleam might actually consider itself an ML? not sure about that, but it's definitely a descendant)

innocentoldguy 1y ago

I prefer Elixir's syntax over Gleam's, but my main issue with Gleam is architectural. Specifically, Gleam had to bastardize BEAM and OTP to implement static typing. To me, static typing vs. dynamic typing is like having a shelf with a doily vs. one without a doily (the shelf works fine either way), so messing up a solid Actor Model implementation, for instance, for the sake of static typing seems like the wrong thing to do.

chamomeal 1y ago
How does it bastardize the beam? Like are there things you can do in elixir/erlang that you couldn’t with gleam?
- Alupis 1y ago
  I'm curious to know what the parent meant, as well. My understanding, which is incomplete admittedly, is that Gleam's type system lives in Gleam and isn't carried over into the produced Erlang/BEAM code, since BEAM has no concept of types, etc. Gleam also has an OTP implementation[1] available, which includes Actors and the like. My understanding is that every BEAM language must implement OTP themselves, so there's nothing unusual here. [1] https://hexdocs.pm/gleam_otp/ https://hexdocs.pm/gleam_otp/
  - innocentoldguy 1y ago
    Gleam's type system is the root cause of the problem. Please see my reply to the parent of your post.
- innocentoldguy 1y ago
  It has been a while since I looked at Gleam. Some things may have changed. However, the last time I used Gleam, I was forced to switch back to Elixir because Gleam: • Lacks support for named processes. • Has limited actor abstractions. • Doesn't support OTP system messages. • Has implemented supervisors in a way that can lead to improper shutdowns, data loss, and deviations from the expected BEAM behavior. • Doesn't support pattern matching directly in function definitions. Instead, it requires you to use case statements. • Doesn't support global mutable variables because it has no way to track variable types and state changes when BEAM modifies these variables, which is one of the hallmark features of BEAM. • Doesn't support hot code reloading. All of these features, which are readily available in Erlang and Elixir, are far more important to me than static typing. I've used statically typed languages like C, C++, C#, and Java, and dynamically typed languages like Python, Ruby, and Elixir throughout my 30+ years career. I've never once lamented not having static types, nor have I ever jumped for joy when I do. For me, static vs. dynamic typing is largely irrelevant and doesn't affect my work one way or the other.