4 ms·

Amazing how Gleam is moving forward. It seems it's now pretty mature and with great tooling support?! Is it fair to call Gleam an Erlang with modern syntax and

by brabel 2y ago

Amazing how Gleam is moving forward. It seems it's now pretty mature and with great tooling support?! Is it fair to call Gleam an Erlang with modern syntax and a HM type system? It seems it can also compile to JS (not just Erlang's Beam VM) - is the JS target as well supported? Is performance just the same as Erlang (when compiled to Beam) or there's differences? Why would someone use Beam instead of Elixir (they now have optional types - not sure how well those work though)? Is there really demand for more than one modern language on top of Erlang's VM?

hayleighdotdev 2y ago
> Is it fair to call Gleam an Erlang with modern syntax and a HM type system? Kinda. There's a fair amount similar but things like message passing are implemented as a library in gleam [0] rather than being a part of the core language, so you might say the big things that make erlang _erlang_ are not part of Gleam directly. > is the JS target as well supported? The experience is pretty good, yeah! The compiler can emit typescript declarations, there's a vite plugin for gleam, I maintain a frontend framework written in gleam and it's all grand. > Is performance just the same as Erlang (when compiled to Beam) or there's differences? That's right, perf is the same. > Why would someone use Gleam instead of Elixir (they now have optional types - not sure how well those work though)? Is there really demand for more than one modern language on top of Erlang's VM? Few reasons. Elixir's type system work is very much Work In Progress and could be a long time before we get something "finished". Also the semantics and approach have quite different designs: I'd guess folks that like the gradual type experience Elixir is pushing would not like Gleam's type system and vice versa. There's certainly room for us both on the BEAM (and we do interoperate too!) [0]: https://hexdocs.pm/gleam_erlang/ https://hexdocs.pm/gleam_erlang/
- spinningslate 2y ago
  > I maintain a frontend framework written in gleam and it's all grand For anyone interested, that framework is Lustre[0]. It looks interesting: An Elm-inspired approach to SPAs on the front end, compiling Gleam to javascript. Back end also in Gleam but compiled to Erlang. Haven't tried it yet but on the list. Kudos, @hayleighdotdev, for putting something that expansive together in a pretty short period of time. [0]: https://hexdocs.pm/lustre/guide/01-quickstart.html https://hexdocs.pm/lustre/guide/01-quickstart.html
- lpil 2y ago
  > There's a fair amount similar but things like message passing are implemented as a library in gleam [0] rather than being a part of the core language, so you might say the big things that make erlang _erlang_ are not part of Gleam directly. It's worth nothing that while `!` and `receive` are in the core language for Erlang, OTP (the actor framework and what people generally consider the important bit of Erlang) is implemented as a library, just like in Gleam.

by brabel 2y ago

hayleighdotdev 2y ago

> Is it fair to call Gleam an Erlang with modern syntax and a HM type system? Kinda. There's a fair amount similar but things like message passing are implemented as a library in gleam [0] rather than being a part of the core language, so you might say the big things that make erlang _erlang_ are not part of Gleam directly. > is the JS target as well supported? The experience is pretty good, yeah! The compiler can emit typescript declarations, there's a vite plugin for gleam, I maintain a frontend framework written in gleam and it's all grand. > Is performance just the same as Erlang (when compiled to Beam) or there's differences? That's right, perf is the same. > Why would someone use Gleam instead of Elixir (they now have optional types - not sure how well those work though)? Is there really demand for more than one modern language on top of Erlang's VM? Few reasons. Elixir's type system work is very much Work In Progress and could be a long time before we get something "finished". Also the semantics and approach have quite different designs: I'd guess folks that like the gradual type experience Elixir is pushing would not like Gleam's type system and vice versa. There's certainly room for us both on the BEAM (and we do interoperate too!) [0]: https://hexdocs.pm/gleam_erlang/ https://hexdocs.pm/gleam_erlang/

spinningslate 2y ago
> I maintain a frontend framework written in gleam and it's all grand For anyone interested, that framework is Lustre[0]. It looks interesting: An Elm-inspired approach to SPAs on the front end, compiling Gleam to javascript. Back end also in Gleam but compiled to Erlang. Haven't tried it yet but on the list. Kudos, @hayleighdotdev, for putting something that expansive together in a pretty short period of time. [0]: https://hexdocs.pm/lustre/guide/01-quickstart.html https://hexdocs.pm/lustre/guide/01-quickstart.html
lpil 2y ago
> There's a fair amount similar but things like message passing are implemented as a library in gleam [0] rather than being a part of the core language, so you might say the big things that make erlang _erlang_ are not part of Gleam directly. It's worth nothing that while `!` and `receive` are in the core language for Erlang, OTP (the actor framework and what people generally consider the important bit of Erlang) is implemented as a library, just like in Gleam.