Coming from Elixir, I gave Gleam a try for a couple of days over the holidays. Reasons I decided not to pursue:
- No ad-hoc polymorphism (apart from function overloading IIRC) means no standard way of defining how things work.
There are not many conventions yet in place so you won’t know if your library supports eg JSON deserialization for its types
- Coupled with a lack of macros, this means you have to implement even most basic functionality like JSON (de)serialization yourself - even for stdlib and most popular libs’ structs
- When looking on how to access the file system, I learned the stdlib does not provide fs access as the API couldn’t be shared between the JS and Erlang targets. The most popular fs package for erlang target didn’t look of high quality at all. Something so basic and important.
- This made me realise that in contrast to elixir which not only runs on the BEAM („Erlang“) but also runs with seamless Erlang interop, Gleam doesn’t have access to most of the Erlang / Elixir ecosystem out of the box.
There are many things I liked, like the algebraic data types, the Result and Option types, pattern matching with destructuring.
Which made me realize what I really want is Rust. My ways lead to Rust, I guess.
> 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’ve been doing Elixir for 9 years, 5 professionally. Nobody cares about ad-hoc polymorphism. The community doesn’t use protocols except “for data”. Whatever that means. Global singleton processes everywhere. I’m really discouraged by the practices I observe but it’s the most enjoyable language for me still.
I am in love with Gleam! As a young computer science student, I found that Gleam brought back the joy of programming just when I felt like I was seriously burning out. I was never a fan of functional programming languages. I had tried other BEAM languages like Elixir and Erlang before, but Gleam is the one I’ve enjoyed the most :)
Glean is interesting from language nerd point of view, however I never had a reason to use Erlang at work, and probably never will, and I suspect that relates to most folks.
It’s funny how we avoid the technologies we can’t complain about much. Seeing an Elixir projects on production I always wonder „why we are not using it more often”. More talking about Elixir here.
For Elixir I saw a simple distributed job scheduler - it was dead simple in code and was ripped, because it didn’t require maintenance for ~8 years just working without issue and people who knew anything about it left company or switched part of company and acted as they forgot everything.
The other example is medium sized (in terms of features and code) web app - maintained by <30 people now, delivering more than 800 people at the other company, no stress, no issues and with great DX because of the BEAM (other company is drowning in JVM based nano-services).
I remember playing with Alpaca a few years ago, and it was fun though I didn’t find the resulting code to significantly less error-prone than when I wrote regular Erlang. It’s inelegant, but I find that Erlang’s quasi-runtime-typing with pattern matching gets you pretty far and it falls into Erlang’s “let it crash” philosophy nicely.
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. The wire doesn’t care about monads or integers or characters or strings or functors, just 1’s and 0’s, and ultimately I feel like imposing a type system can often get in the way more than it helps. There’s so much weirdness and uncertainty associated with stuff going over the wire, and pretty types often don’t really capture that.
I haven’t tried Gleam yet, and I will give it a go, and it’s entirely possible it will change my opinion on this, so I am willing to have my mind changed.
I don’t understand this comment, yes everything going over the wire is bits, but both endpoints need to know how to interpret this data, right? Types are a great tool to do this. They can even drive the exact wire protocol, verification of both data and protocol version.
So it’s hard to see how types get in the way instead of being the ultimate toolset for shaping distributed communication protocols.
Bits get lost, if you don’t have protocol verification you get mismatched types.
Types naively used can fall apart pretty easily. Suppose you have some data being sent in three chunks. Suppose you get chunk 1 and chunk 3 but chunk 2 arrives corrupted for whatever reason. What do you do? Do you reject the entire object since it doesn’t conform to the type spec? Maybe you do, maybe you don’t, or maybe you structure the type around it to handle that.
But let’s dissect that last suggestion; suppose I do modify the type to encode that. Suddenly pretty much every field more or less just because Maybe/Optional. Once everything is Optional, you don’t really have a “type” anymore, you have a a runtime check of the type everywhere. This isn’t radically different than regular dynamic typing.
There are more elaborate type systems that do encode these things better like session types, and I should clarify that I don’t think that those get in the way. I just think that stuff like the C type system or HM type systems stop being useful, because these type systems don’t have the best way to encode the non-determinism of distributed stuff.
You can of course ameliorate this somewhat with higher level protocols like HTTP, and once you get to that level types do map pretty well and you should use them. I just have mixed feelings for low-level network stuff.
> But let’s dissect that last suggestion; suppose I do modify the type to encode that. Suddenly pretty much every field more or less just because Maybe/Optional. Once everything is Optional, you don’t really have a “type” anymore, you have a a runtime check of the type everywhere. This isn’t radically different than regular dynamic typing.
Of course it’s different. You have a type that accurately reflects your domain/data model. Doing that helps to ensure you know to implement the necessary runtime checks, correctly. It can also help you avoid implementing a lot of superfluous runtime checks for conditions you don’t expect to handle (and to treat those conditions as invariant violations instead).
No, it really isn’t that different. If I had a dynamic type system I would have to null check everything. If I have declare everything as a Maybe, I would have to null check everything.
For things that are invariants, that’s also trivial to check against with `if(!isValid(obj)) throw Error`.
Sure. The difference is that with a strong typing system, the compiler makes sure you write those checks. I know you know this, but that’s the confusion in this thread. For me too, I find static type systems give a lot more assurance in this way. Of course it breaks down if you assume the wrong type for the data coming in, but that’s unavoidable. At least you can contain the problem and ensure good error reports.
I don’t think I did. I am one of the very few people who have had paying jobs doing Scala, Haskell, and F#. I have also had paying jobs doing Clojure and Erlang: dynamic languages commonly used for distributed apps.
I like HM type systems a lot. I’ve given talks on type systems, I was working on trying to extend type systems to deal with these particular problems in grad school. This isn’t meant to a statements on types entirely. I am arguing that most systems don’t encode for a lot of uncertainty that you find when going over the network.
With all due respect, you really do not understand these protocols if you think “just use TCP and ECC” addresses my complaints.
Again, it’s not that I have an issue with static types “not protecting you”, I am saying that you have to encode for this uncertainty regardless of the language you use. The way you typically encode for that uncertainty is to use an algebraic data type like Maybe or Optional. Checking against a Maybe for every field ends up being the same checks you would be doing with a dynamic language.
I don’t really feel the need to list out my full resume, but I do think it is very likely that I understand type systems better than you do.
Fair enough, though I feel so entirely differently that your position baffles me.
Gleam is still new to me, but my experience writing parsers in Haskell and handling error cases succinctly through functors was such a pleasant departure from my experiences in languages that lack typeclasses, higher-kinded types, and the abstractions they allow.
The program flowed happily through my Eithers until it encountered an error, at which point that was raised with a nice summary.
Part of that was GHC extensions though they could easily be translated into boilerplate, and that only had to be done once per class.
Gleam will likely never live to that level of programmer joy; what excites me is that it’s trying to bring some of it to BEAM.
It’s more than likely your knowledge of type systems far exceeds mine—I’m frankly not the theory type. My love for them comes from having written code both ways, in C, Python, Lisp, and Haskell. Haskell’s types were such a boon, and it’s not the HM inference at all.
> 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.
Interesting! I don't share that view at all — I mean, everything running locally is just bits too, right? Your CPU doesn't care about monads or integers or characters or strings or functors either. But ultimately your higher level code does expect data to conform to some invariants, whether you explicitly model them or not.
IMO the right approach is just to parse everything into a known type at the point of ingress, and from there you can just deal with your language's native data structures.
I know everything reduces to bits eventually, but modern CPUs and memory aren’t as “lossy” as the network is, meaning you can make more assumptions about the data being and staying intact (especially if you have ECC).
Once you add distribution you have to encode for the fact that the network is terrible.
You absolutely can parse at ingress, but then there are issues with that. If the data you got is 3/4 good, but one field is corrupted, do you reject everything? Sometimes, but often Probably not, network calls are too expensive, so you encode that into the type with a Maybe. But of course any field could be corrupt so you have to encode lots of fields as Maybes. Suddenly you have reinvented dynamic typing but it’s LARPing as a static type system.
I think you can avoid most issues by not doing what you're describing! Ensuring data arrives uncorrupted is usually not an application-level concern, and if you use something like TCP you get that functionality for free.
TCP helps but only to a certain extent; it only guarantees specific ordering of bits during its session. Suppose you have to construct an object out of three separate transmissions, like some kind of multipart style thing. If one of the transmissions gets corrupted or gets errors out from TCP, then you still fall into that maybe trap.
I get what your saying, but can't you have the same issue if instead you have 3 local threads that you need to get the objects from, one can throw an exception and you only receive 2, same problem
Sometimes, but I am arguing that you need to encode for this uncertainty if you want to make distributed apps work correctly. If you can do transactions for what you’re doing then great, not every app can do that.
When you have to deal with large amounts of uncertainty, static types often reduce to a bunch of optionals, forcing you to null check every field. This is what you end up having to do with dynamic typing as well.
I don’t think types buy you much in cases with extreme uncertainty, and I think they create noise as a result.
It’s a potentially similar issue with threads as well, especially if you’re not sharing data between them, which has similar issues as a distributed app.
A difference is that it’s much cheaper to do retries within a single process compared to doing it over a network, so if something gets borked locally then a retry is (comparatively) free.
> static types often reduce to a bunch of optionals, forcing you to null check every field
On one end, you write / generate / assume a deserialisator that checks whether incoming data satisfies all required invariants, eg all fields are present. On the other end, you specify a type that has all the required fields in required format.
If deserialisation fails to satisfy type requirements, it produces an error which you can handle by eg falling back to a different type, rejecting operation or re-requesting data.
If deserialisation doesn't fail – hooray, now you don't have to worry about uncertainty.
The important thing here is that uncertainty is contained in a very specific place. It's an uncertainty barrier, if you wish: before it there's raw data, after it it's either an error or valid data.
If you don't have a strict barrier like that – every place in the program has to deal with uncertainty.
So it's not necessarily about dynamic / static. It's about being able to set barriers that narrow down uncertainty, and growing number of assumptions. The good thing about ergonomic typing system is that it allows you to offload these assumptions from your mind by encoding them in the types and let compiler worry about it.
It's basically automatization of assumptions book keeping.
You seem to have a fundamental misunderstanding about type systems. Most (the best?) typesystems are erased. This means they only have meaning "on compile time", and makes sure your code is sound and preferrably without UB.
The "its only bits" thing makes no sense in the world of types. In the end its machine code, that humans never (in practice) write or read.
I still suspect the effectiveness of plugging in a type system patch to a complete system, like typescript to javascript. We still observe so many `as any` or `as unknown as` at every corner.
Despite of the suspicion, Gleam provides a better and elegant syntax for those who are not familiar with Erlang or functional programming languages, which I loved most.
That doesn’t really apply to Gleam, it’s not a type syntax for another language that can be stripped, it’s its own language that compiles to Erlang and JS
Biggest issue with this language. But... fairly trivial to implement codegen with gleam/glance[0]. No good libraries do this well right now (e.g. support for discriminated unions).
Gleam is technically as suitable for distributed computing as Erlang: since it compiles to Erlang, it can do anything that Erlang can. You can use Erlang and Elixir libraries and write FFI code to do things that would be unergonomic to do in Gleam. Sure the experience is different and if you want to embrace the guarantees of static typing, then the APIs will look different, like gleam_otp.
If you compile it to JS, then the guarantees change to JS's guarantees.
Personally I've felt that the JS target is a big plus and hasn't detracted from Gleam. Writing a full stack app with both sides being in Gleam and sharing common code is something I've enjoyed a lot. The most visible impact is that there's no target specific functions in the stdlib or the language itself, so Erlang related things are in gleam_erlang and gleam_otp, and e.g. filesystem access is a package instead of being in the stdlib. If you're just into Erlang, you don't need to interact with the JS target at all.
Gleam is nice. However it is still very lacking in the stdlib. You will need lots of dependencies to build something usable. I kind of wish Gleam could target something like Go, then you would have the option to go native without a "heavy" VM like the BEAM.
Now here's a type-safe functional programming language I recently bumped into, which with their focus on simplicity, ease of use, and developer experience, and compiling to either Erlang or Javascript, is really tempting to delve in deeper.
https://tangled.org/slices.network/quickslice
- No ad-hoc polymorphism (apart from function overloading IIRC) means no standard way of defining how things work. There are not many conventions yet in place so you won’t know if your library supports eg JSON deserialization for its types
- Coupled with a lack of macros, this means you have to implement even most basic functionality like JSON (de)serialization yourself - even for stdlib and most popular libs’ structs
- When looking on how to access the file system, I learned the stdlib does not provide fs access as the API couldn’t be shared between the JS and Erlang targets. The most popular fs package for erlang target didn’t look of high quality at all. Something so basic and important.
- This made me realise that in contrast to elixir which not only runs on the BEAM („Erlang“) but also runs with seamless Erlang interop, Gleam doesn’t have access to most of the Erlang / Elixir ecosystem out of the box.
There are many things I liked, like the algebraic data types, the Result and Option types, pattern matching with destructuring. Which made me realize what I really want is Rust. My ways lead to Rust, I guess.
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:
As another example, I chose a package[0] at random that implements bindings to the Elixir package blake2[1]. 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
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.
For Elixir I saw a simple distributed job scheduler - it was dead simple in code and was ripped, because it didn’t require maintenance for ~8 years just working without issue and people who knew anything about it left company or switched part of company and acted as they forgot everything.
The other example is medium sized (in terms of features and code) web app - maintained by <30 people now, delivering more than 800 people at the other company, no stress, no issues and with great DX because of the BEAM (other company is drowning in JVM based nano-services).
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. The wire doesn’t care about monads or integers or characters or strings or functors, just 1’s and 0’s, and ultimately I feel like imposing a type system can often get in the way more than it helps. There’s so much weirdness and uncertainty associated with stuff going over the wire, and pretty types often don’t really capture that.
I haven’t tried Gleam yet, and I will give it a go, and it’s entirely possible it will change my opinion on this, so I am willing to have my mind changed.
So it’s hard to see how types get in the way instead of being the ultimate toolset for shaping distributed communication protocols.
Types naively used can fall apart pretty easily. Suppose you have some data being sent in three chunks. Suppose you get chunk 1 and chunk 3 but chunk 2 arrives corrupted for whatever reason. What do you do? Do you reject the entire object since it doesn’t conform to the type spec? Maybe you do, maybe you don’t, or maybe you structure the type around it to handle that.
But let’s dissect that last suggestion; suppose I do modify the type to encode that. Suddenly pretty much every field more or less just because Maybe/Optional. Once everything is Optional, you don’t really have a “type” anymore, you have a a runtime check of the type everywhere. This isn’t radically different than regular dynamic typing.
There are more elaborate type systems that do encode these things better like session types, and I should clarify that I don’t think that those get in the way. I just think that stuff like the C type system or HM type systems stop being useful, because these type systems don’t have the best way to encode the non-determinism of distributed stuff.
You can of course ameliorate this somewhat with higher level protocols like HTTP, and once you get to that level types do map pretty well and you should use them. I just have mixed feelings for low-level network stuff.
Of course it’s different. You have a type that accurately reflects your domain/data model. Doing that helps to ensure you know to implement the necessary runtime checks, correctly. It can also help you avoid implementing a lot of superfluous runtime checks for conditions you don’t expect to handle (and to treat those conditions as invariant violations instead).
For things that are invariants, that’s also trivial to check against with `if(!isValid(obj)) throw Error`.
I like HM type systems a lot. I’ve given talks on type systems, I was working on trying to extend type systems to deal with these particular problems in grad school. This isn’t meant to a statements on types entirely. I am arguing that most systems don’t encode for a lot of uncertainty that you find when going over the network.
For ensuring bits don't get lost, you use protocols like TCP. For ensuring they don't silently flip on you, you use ECC.
Complaining that static types don't guard you against lost packets and bit flips is missing the point.
Again, it’s not that I have an issue with static types “not protecting you”, I am saying that you have to encode for this uncertainty regardless of the language you use. The way you typically encode for that uncertainty is to use an algebraic data type like Maybe or Optional. Checking against a Maybe for every field ends up being the same checks you would be doing with a dynamic language.
I don’t really feel the need to list out my full resume, but I do think it is very likely that I understand type systems better than you do.
Sure thing. Unless dev forgets to do (some of) these checks, or some code downstream changes and upstream checks become gibberish or insufficient.
Gleam is still new to me, but my experience writing parsers in Haskell and handling error cases succinctly through functors was such a pleasant departure from my experiences in languages that lack typeclasses, higher-kinded types, and the abstractions they allow.
The program flowed happily through my Eithers until it encountered an error, at which point that was raised with a nice summary.
Part of that was GHC extensions though they could easily be translated into boilerplate, and that only had to be done once per class.
Gleam will likely never live to that level of programmer joy; what excites me is that it’s trying to bring some of it to BEAM.
It’s more than likely your knowledge of type systems far exceeds mine—I’m frankly not the theory type. My love for them comes from having written code both ways, in C, Python, Lisp, and Haskell. Haskell’s types were such a boon, and it’s not the HM inference at all.
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.
IMO the right approach is just to parse everything into a known type at the point of ingress, and from there you can just deal with your language's native data structures.
Once you add distribution you have to encode for the fact that the network is terrible.
You absolutely can parse at ingress, but then there are issues with that. If the data you got is 3/4 good, but one field is corrupted, do you reject everything? Sometimes, but often Probably not, network calls are too expensive, so you encode that into the type with a Maybe. But of course any field could be corrupt so you have to encode lots of fields as Maybes. Suddenly you have reinvented dynamic typing but it’s LARPing as a static type system.
I get what your saying, but can't you have the same issue if instead you have 3 local threads that you need to get the objects from, one can throw an exception and you only receive 2, same problem
When you have to deal with large amounts of uncertainty, static types often reduce to a bunch of optionals, forcing you to null check every field. This is what you end up having to do with dynamic typing as well.
I don’t think types buy you much in cases with extreme uncertainty, and I think they create noise as a result.
It’s a potentially similar issue with threads as well, especially if you’re not sharing data between them, which has similar issues as a distributed app.
A difference is that it’s much cheaper to do retries within a single process compared to doing it over a network, so if something gets borked locally then a retry is (comparatively) free.
On one end, you write / generate / assume a deserialisator that checks whether incoming data satisfies all required invariants, eg all fields are present. On the other end, you specify a type that has all the required fields in required format.
If deserialisation fails to satisfy type requirements, it produces an error which you can handle by eg falling back to a different type, rejecting operation or re-requesting data.
If deserialisation doesn't fail – hooray, now you don't have to worry about uncertainty.
The important thing here is that uncertainty is contained in a very specific place. It's an uncertainty barrier, if you wish: before it there's raw data, after it it's either an error or valid data.
If you don't have a strict barrier like that – every place in the program has to deal with uncertainty.
So it's not necessarily about dynamic / static. It's about being able to set barriers that narrow down uncertainty, and growing number of assumptions. The good thing about ergonomic typing system is that it allows you to offload these assumptions from your mind by encoding them in the types and let compiler worry about it.
It's basically automatization of assumptions book keeping.
The "its only bits" thing makes no sense in the world of types. In the end its machine code, that humans never (in practice) write or read.
Despite of the suspicion, Gleam provides a better and elegant syntax for those who are not familiar with Erlang or functional programming languages, which I loved most.
[0] https://hexdocs.pm/glance/glance.html
https://news.ycombinator.com/item?id=46255991
It's confusing too. Is Gleam suitable for distributed computing like Elixir/Erlang on BEAM? Would that answer change if I compile it to JS?
If you compile it to JS, then the guarantees change to JS's guarantees.
Personally I've felt that the JS target is a big plus and hasn't detracted from Gleam. Writing a full stack app with both sides being in Gleam and sharing common code is something I've enjoyed a lot. The most visible impact is that there's no target specific functions in the stdlib or the language itself, so Erlang related things are in gleam_erlang and gleam_otp, and e.g. filesystem access is a package instead of being in the stdlib. If you're just into Erlang, you don't need to interact with the JS target at all.