(no title)
hayleighdotdev | 1 year ago
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!)
spinningslate|1 year ago
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
lpil|1 year ago
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.