[HN Gopher] Gleam 0.16 compiles to JavaScript
___________________________________________________________________
Gleam 0.16 compiles to JavaScript
Author : todsacerdoti
Score : 147 points
Date : 2021-06-17 12:38 UTC (10 hours ago)
(HTM) web link (gleam.run)
(TXT) w3m dump (gleam.run)
| gampleman wrote:
| 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?
| lpil wrote:
| 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.
| donpdonp wrote:
| The similarities to elm make this language intriguing. What I'd
| really like to see is a compiler in webasm that compiles Gleam
| code to webasm.
| tynanbe wrote:
| 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.
| lpil wrote:
| 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.
| spinningslate wrote:
| 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.
| lpil wrote:
| 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.
| mcintyre1994 wrote:
| This looks really cool, and TIL (from their compiled JavaScript)
| about JS' reflect: https://developer.mozilla.org/en-
| US/docs/Web/JavaScript/Refe...
|
| 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:
| external fn query_selector(String) -> Element = ""
| "document.querySelector"
|
| Becomes: function query_selector(arg0) {
| return document.querySelector(arg0) }
|
| I'm not sure what the empty string first argument is doing in
| this case.
| tynanbe wrote:
| It references module, which can be seen when creating an
| `external fn` for Erlang or Elixir, for example.
| https://gleam.run/book/tour/external-functions.html
| lpil wrote:
| 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.
| jitl wrote:
| > 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...
| louissm_it wrote:
| 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.
| lpil wrote:
| A full stack web framework is certainly something we want to
| explore in future.
| crowdhailer wrote:
| 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
| lpil wrote:
| Very cool, I'm looking forward to seeing what you come up with
| yewenjie wrote:
| 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?
| ch4s3 wrote:
| There's Purerl[1] which is purescript erlang backend.
|
| [1]https://github.com/purerl/purerl
| juicypt wrote:
| Here's an interesting effort in creating an Ocaml for the BEAM
| VM: https://github.com/AbstractMachinesLab/caramel
|
| It's still pretty new though, so I don't know how well it works
| just yet.
| chrischen wrote:
| Gleam is already pretty close to ocaml.
| throwaway894345 wrote:
| 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?
| lpil wrote:
| 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.
| robbie-c wrote:
| This is really cool! Really excited to see what people will do
| with the JS support
| miguelraz wrote:
| Congrats to Louis and the team, great work!
___________________________________________________________________
(page generated 2021-06-17 23:01 UTC)