> 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.
the dynamic messages have to have static properties to be relevant for the receiving program, the properties are known upfront, and there's no "decades-running trap of trying to solve this".
> there's no "decades-running trap of trying to solve this".
I’m not as certain. The fact that we’ve gone from ASN.1 to COBRA/SOAP to protobuf to Cap’n’web and all the million other items I didn’t list says something. The fact that, even given a very popular alternative in that list, or super tightly integrated RPC like sending terms between BEAMs, basic questions like “should optionality/absence be encoded differently than unset default values?” and “how should we encode forward compatibility?” have so may different and unsatisfactory answers says something.
> I’m not as certain. The fact that we’ve gone from ASN.1 to COBRA/SOAP to protobuf to Cap’n’web and all the million other items I didn’t list says something.
> It absolutely is a decades old set of problems that have never been solved to the satisfaction of most users.
ASN.1 wasn't in the same problem space with CORBA/DCOM, both CORBA and DCOM/OLE were heavily invested in a general-purpose non-domain-specific object model representation that would suppot arbitrary embeddings within an open-ended range of software. I suspect this is the unsolvable problem indeed, but I also believe that's not what you meant with your comment either, since all the known large-scale BEAM deployments (the comment I originally replied to implied BEAM deployments) operate within bounded domain spaces such as telecom and messaging, where distributed properties of the systems are known upfront: there are existing formats, protocols of exchange, and the finite number of valid interactions between entities/actors of the network, the embeddings are either non-existent or limited to a finite set of media such as static images, videos, maps, contacts etc. All of these can be encoded by a compile-time specification that gets published for all parties upfront.
> basic questions like “should optionality/absence be encoded differently than unset default values?”
However you like, any monoid would work here. I would argue that [a] and [] always win over (Option a) and especially over (Option [a]).
> and “how should we encode forward compatibility?”
> 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:
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!
Isn’t this the proof of my point - How does the need of writing „@external“ annotations by hand not contradict the point of being „out of the box“ usable?
Hayleigh, when I asked on the discord about how to solve my JSON problem in order to get structured logging working, you replied that I’m the first one to ask about this.
Now reading this:
> 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
Certainly makes me even more feel like gatekeeping.
I don't think Hayleigh was trying to gatekeep, just noting that some developers prefer features that Gleam intentionally omits.
As for the @external annotations, I think you're both right to a degree. Perhaps we can all agree to say: Gleam can use most libraries from Erlang/Elixir, but requires some minimal type-annotated FFI bindings to do so (otherwise it couldn't claim to be a type-safe language).
How does it contradict it? Without any modification/installation you can interop with Erlang/Javascript. How is that not out of the box usability of the Erlang/JS ecosystem? Syntax isn't as seamless as Elixir, but we need a way to tell Gleam what types are being passed around.
Why do you feel like a gatekeeper? Your opinion is valid, it's just that the interop statement was wrong.
That's FFI bindings. I need to provide the function signature of every API, because Erlang isn't statically typed. It's okay if some library provides it (like the linked , but I don't want to write this by hand if I can avoid it. And it's definitely not out of box, someone has to write the bindings for it to work
It would be different if I didn't have to write bindings and Gleam integrated automatically with foreign APIs. For Erlang that's probably not possible, but for the Javascript ecosystem it could make use of Typescript signatures maybe. (it would be very hard though)
Yeah, it's there out of the box but it's certainly not seamless. For an Elixir dev, it is more friction than you're used to. It is the cost of static types.
This is the same as Elixir, you need to specify what Erlang function to use in that language if you want to use Erlang code. The only difference is that Gleam has a more verbose syntax for it.
The runtime behaviour and cost of calling an Erlang function is the same in Elixir and Gleam, however the syntax is more verbose in Gleam as it asks for type information, while in Elixir this is optional.
> 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!
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 ^.^
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
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!
This release is huge. I really love the attention to compiler errors and making them easy to understand - all of the general developer experience improvements are very welcome!
The BEAM ecosystem seems very impressive for backend style work, but both Erlang and Elixir's syntax are kind of a put off. Gleam I've found to be quite readable and very pleasant to look at - plus it gets all the OTP/BEAM benefits for super scaling.
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.
reply