hayleighdotdev

> Honestly, and I realize that this might get me a bit of flack here and that’s obviously fine, but I find type systems start losing utility with distributed applications. Ultimately everything being sent over the wire is just bits.

Actually Gleam somewhat shares this view, it doesn't pretend that you can do typesafe distributed message passing (and it doesn't fall into the decades-running trap of trying to solve this). Distributed computing in Gleam would involve handling dynamic messages the same way handling any other response from outside the system is done.

This is a bit more boilerplate-y but imo it's preferable to the other two options of pretending its type safe or not existing.

> Gleam doesn’t have access to most of the Erlang / Elixir ecosystem out of the box.

Gleam has access to the entire ecosystem out of the box, because all languages on the BEAM interoperate with one another. For example, here's a function inside the module for gleam_otp's static supervisor:

    @external(erlang, "supervisor", "start_link")
    fn erlang_start_link(
      module: Atom,
      args: #(ErlangStartFlags, List(ErlangChildSpec)),
    ) -> Result(Pid, Dynamic)

As another example, I chose a package[0] at random that implements bindings to the Elixir package blake2[1].

    @external(erlang, "Elixir.Blake2", "hash2b")
    pub fn hash2b(message m: BitArray, output_size output_size: Int) -> BitArray

    @external(erlang, "Elixir.Blake2", "hash2b")
    pub fn hash2b_secret(
      message m: BitArray,
      output_size output_size: Int,
      secret_key secret_key: BitArray,
    ) -> BitArray

It's ok if you don't vibe with Gleam – no ad-hoc poly and no macros are usually dealbreakers for certain types of developer – but it's wrong to say you can't lean on the wider BEAM ecosystem!

[0]: https://github.com/sisou/nimiq_gleam/blob/main/gblake2/src/g...

[1]: https://hex.pm/packages/blake2

> Perhaps this is a packaging issue on my system though.

Gleam is only officially distributed via the releases on GitHub [1] so if you pick up Gleam from a package manager that's always maintained by someone else. I think most of those community distributions do include Erlang and bits which is probably what pulled in all those extra packages!

[1]: https://github.com/gleam-lang/gleam/releases/tag/v1.13.0

No lifetimes, absolutely no plans to add anything similar. We’re nothing like rust!

They're kind of solving different problems. It's a bit like TypeScript vs Elm or PureScript: one is a type system overlaid onto an existing language with its own rich ecosystem and set of idioms, and the other is a new language that targets the same underlying platform but has different idioms and semantics for static analysis.

If you already have lots of Elixir in production, or you enjoy Elixir's highly dynamic approach to solving problems and would like to get some additional safety for free then sticking with Elixir is a no-brainer!

If you'd like a simpler language with tighter static analysis guarantees while still being able to dip into the wider ecosystem then you might prefer Gleam.

Ultimately I think the two languages have very different philosophies and idioms, folks will naturally find themselves preferring one or the other ^.^

hello fellow print debugging enjoyer, rejoice!

Lustre (hi, author here) has isomorphic components so you can render components both on the client or as realtime LiveView-esque things on the server, which I think is what the commenter was alluding to.

Definitely not a full-stack framework though: firmly a frontend thing just it blurs what "frontend" means a little! Hologram has a wider scope here being built on top of Phoenix.

I think the author might have a debug build enabled. If you open the console you can see timing information logged. Loading the introduction page of the docs [0] logs...

[Debug] Hologram: runtime script executed [Debug] Hologram: page script executed [Log] Hologram: page rendered in – 876 – "ms" [Debug] Hologram: connected to a server

Which is kind of crazy for a page with just text. Would be super curious to see what the perf is like on a proper prod build, it looks like they've implemented at least some part of the elixir vm in js

[0]: https://hologram.page/docs/introduction

The variant inference in this release is a feature I wish more functional languages had. You know what variant something inside this pattern match branch is, compiler, I just prove it to you!

Most folks are using Gleam to do full stack Web stuff. Because Gleam compiles to both Erlang and JavaScript it ends up being a pretty nice experience.

"This is my favourite release!" - person who contributed heavily to the release :3

Author of Lustre here! Yeah I agree, lack of a robust headless component library like radix-ui or react-aria is such a mark against Elm. I think it's even more important for Lustre because really all our users are going to be backendy folks with little interest in the nitty gritty frontend stuff.

Lustre will eventually have a companion ui library to plug this gap but it turns out maintaining all this stuff is a bit of a time sink, so I'm taking baby steps ^.^

> 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/

Hey there, I maintain a library a called lustre [0] that does similar things to liveview. The linked docs are the API reference, but there's not currently a guide or a robust example on how to put things together (there's a bare minimum one in the repo you can find) – that'll be changing soon, I was just giving a talk about this at Lambda Days ^.^

In the interest of fairness, there's also sprocket [1] which leans much heavier into thing that you might also what a check out.

[0]: https://hexdocs.pm/lustre/lustre/server_component.html [1]: https://sprocket.live

Gleam doesn't have auto currying! Often folks find this (currying) a bit confusing to wrap their head around when learning functional programming and we don't feel like it really affords you much that couldn't already be achieved with just a little bit more work by the programmer.

Applicative builder APIs are the only thing we've found would be much much better if we had auto currying.