The first specifies the module that the the function is contain by. In this case we are using global functions so there is no module, but if we specified and module the function would be imported from it.
> I guess that's the magic behind most JS data binding libraries?
Most of the functions on Reflect can be done using built-in language features, I haven’t seen much use of it in libraries.
For reactive, magic data binding see Proxy, which allows a callback on object property access for arbitrary objects. Proxy is the magic behind Mobx for instance. Reflect fits in well because it can be used as the “default” or fallback implementation for Proxy methods. See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
This is awesome. I've been looking forward to a Phoenix like framework in Gleam, and now I can totally see the same language being used on the frontend too.
Kudos for getting this out, and the rationale for adding js support makes sense. This bit:
> The pervasive Promise type and the split between synchronous and asynchronous functions in JavaScript can be more difficult to learn and use than languages such as Erlang and Go that make no such distinction.
is most interesting to me. I first got interested in Gleam as a statically-typed language targeting the BEAM VM that supported Erlang's concurrency model. Supporting it on JS VMs will be a whole lot harder I'd imagine. Without it, Gleam isn't really that interesting to me on the front end. But if they can pull it off, it gets very interesting. I'd take the Actor / CSP flavour of concurrency over async-await every day of the week.
Yes, for sure. I think if you look at Gleam as an alternative to PureScript or similar it's not a very exciting proposition. There's a lot of good options here.
This is more an exciting new feature for people who are already using Gleam, they can now do more with the language.
It's really cool to see this released.
I've already been running some experiments to see what framework models work well for gleam based browser apps, which I hope to share soon
I love the developer-friendliness of Elixir syntax and the robustness + power of the Erlang VM. However, I really miss the type system and cool mathy things of Haskell (eta reduction for example).
Is there a language on the BEAM that has strong functional features of Haskell?
Can you elaborate on the benefits of the BEAM? I'm of the impression that Erlang's robustness is largely a property of its use of supervision trees (OTP?) rather than the VM directly? What exactly does the VM do that makes it better than other kinds of VMs?
The supervision trees require a few features of the VM that are hard to replicate in other runtimes. Links and process isolation being the main ones.
Robustness aside the BEAM has other nice properties such as the concurrency model, the concurrent and predictably low latency GC, and it's distributed and parallel computing features.
Wasm as a compilation target is certainly of interest for the future. This Javascript target will hopefully provide a pragmatic way to write Gleam for a similar set of environments in the meantime, in addition to providing whatever unique opportunities the JS target itself offers.
If you like elm-similar languages, check out mint at mint-lang. It's very heavily inspired by Elm the language, but not Elm the community or project. I've been using it on side projects and love it. It doesn't compile to wasm, but it does compile to preact with web workers.
We would like to do that one day! It would take a long time though, so more impactful things will come first, such as improved tooling and documentation.
I've bean a fan of Gleam for a while, so please take this as more of a critique of the writing rather than of the project, but I am missing a strong rationale for why? What does compiling to JavaScript practically bring or enable? Other than having yet another way to write front-end programmes without the benefits of a strong ecosystem?
It enables Gleam developers to write Gleam code in a wider variety of situations. Web frontends are one obvious example (though as you say there are more mature ecosystems for that) but there are many others, some of which are listed in the post.
I think it is unlikely many people will pick Gleam to make just a web frontend, but if you have a Gleam backend it may be more appealling to also use it on the frontend so that you can share code and type definitions between them. In future a full stack Gleam web framework may also take care of the typically JSON API boilerplate between the front and back ends.
I can see myself using Gleam on AWS lambda and on Android in the near future using the JavaScript backend.
I guess that's the magic behind most JS data binding libraries?
I do find the syntax on the Gleam side a little bit odd:
Becomes: I'm not sure what the empty string first argument is doing in this case.Most of the functions on Reflect can be done using built-in language features, I haven’t seen much use of it in libraries.
For reactive, magic data binding see Proxy, which allows a callback on object property access for arbitrary objects. Proxy is the magic behind Mobx for instance. Reflect fits in well because it can be used as the “default” or fallback implementation for Proxy methods. See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
> The pervasive Promise type and the split between synchronous and asynchronous functions in JavaScript can be more difficult to learn and use than languages such as Erlang and Go that make no such distinction.
is most interesting to me. I first got interested in Gleam as a statically-typed language targeting the BEAM VM that supported Erlang's concurrency model. Supporting it on JS VMs will be a whole lot harder I'd imagine. Without it, Gleam isn't really that interesting to me on the front end. But if they can pull it off, it gets very interesting. I'd take the Actor / CSP flavour of concurrency over async-await every day of the week.
This is more an exciting new feature for people who are already using Gleam, they can now do more with the language.
Is there a language on the BEAM that has strong functional features of Haskell?
It's still pretty new though, so I don't know how well it works just yet.
[1]https://github.com/purerl/purerl
Robustness aside the BEAM has other nice properties such as the concurrency model, the concurrent and predictably low latency GC, and it's distributed and parallel computing features.
I think it is unlikely many people will pick Gleam to make just a web frontend, but if you have a Gleam backend it may be more appealling to also use it on the frontend so that you can share code and type definitions between them. In future a full stack Gleam web framework may also take care of the typically JSON API boilerplate between the front and back ends.
I can see myself using Gleam on AWS lambda and on Android in the near future using the JavaScript backend.