Very nice release, Gleam looks like a good contender for "high-level Rust".
Small nitpick:
> One drawback of this sound type system is that converting untyped input from the outside world into data of known types requires some additional code which would not be required in unsound systems.
It isn't really consequence of its sound type system, but its runtime representation - assuming it requires type information to be safely constructed and manipulated, you really need to generate code to do so, but the compiler could instead choose to use more dynamic representation, e.g. compiling to ordinary Erlang maps / JS objects.
How would this representation be converted back to known types without similar decoders? Right now Gleam compiles custom types to Erlang records (tuples) and JS classes.
The representation would be _the_ runtime representation of those types - in the same way as TypeScript objects are just JavaScript objects with static analysis. The choice of representation is a matter of performance and statically-typed languages usually choose to compile every type to custom representation simply because it makes things more efficient, not because they have to. Unless you implement some baked-in reflection mechanism, there isn't really anything that ties runtime representation to its type, which is a compile-time concept.
The other problem is ensuring that such casting is safe, but that requires runtime checking even in dynamically typed languages.
Since it requires runtime checking anyway, that code has to live somewhere. The decoders are that code. I don't understand how changing the runtime representation would allow to not have those decoders. Unless you mean they should be implicitly generated by the compiler. Or maybe I'm just missing what you're saying.
My point was about the sentence from the original post - its not the consequence of sound type system, its the consequence of choice of runtime representation. If runtime checking matters (which it does in practice), then we don't get any advantage in terms of simplicity by using "unsound" system, because we need to write that code anyway.
Ah, thanks for explaining. :)
Anyone have some interesting things they've built with Gleam?
I'm a master of half finished projects, so here's one that's half finished and one that's actually published and has a half finished user's guide: a PWA client for the iBroadcast music service [0] and a static blog generator [1] that I use to generate my blog [2].
Since all of my free time programming nowadays is in Gleam, I hope to have better examples for you in the future. :)
[0] https://git.ahlcode.fi/nicd/elektrofoni
I've built several personal projects that I'm not really ready to share widely:
An AI tourguide which presents the nearest geotagged Wikipedia pages to the user's location and then produces an entertaining summary of your chosen topic on request. It's just a simple mashup of Wikipedia, MaxBox and OpenAI APIs.
A "leaving the house" dashboard for my wife. It's displayed on a tablet near her mirror, and shows weather and live public transport information to reduce the "I missed the bus and I didn't realize it's raining" disasters that get her day off to a bad start.
I've had a lot of fun making these with Gleam. It has the "if it compiles, it usually works" factor that people love about Rust, with none of the complicated borrow-checking rules. It's very simple - once you're up and running, there's not a lot more to learn about the language and you can just focus on modelling your problem.
Gleam vs Elixir? Go!
Static types is all the reason I need to use Gleam over Elixir.
I tried Gleam for advent of code. Love the types, but the standard library needs desperately something along "lazy sequences" (elixir streams) and every os call should support that. It was too hard to figure out through unmaintained packages
I love elixir but gleam looks more easy to learn if you come from javascript
It depends a lot on the way you write JavaScript. If you work with React, like FP and make everything you can immutable, you’ll probably find it easy.
If you write JavaScript like it’s Java and really lean into OO, then Elixir will be more alien and force you to learn some new patterns.
I don't really see why this is the case. Both Elixir and Gleam are functional languages with immutable data.
The only major difference between them is the typing and the syntax I'd say.
I'm not sure that I like choice to generate decoder code instead of introducing a macro system that can be used to generate the code behind the scenes.
Consider what would happen if you have a larger json object you want to decode (which is often the case). This would require a substantial amount of code that you later would have to read through (being vary of minor changes).
In contrast to Rust's approach where you just have a few notations you can quickly scan through and identify anything unusual.
This is honestly a major turnoff for me with Gleam and doesn't make me want to use the language for anything where I need to handle json (despite all the other things I appreciate about the language).
I like comptime concept over macros, because on Rust you need to annotate a type with the macro derive or manually implement the encoder or decoder, while in Zig for example, (I'm not experienced with Zig, but it seems that is possible to do this) it should be possible to have the encode and decode method to implement the logic to do the work, that means that the boilerplate is generated only when needed and also should work for third party types where you don't have control over.
You might be interested in this: https://lpil.uk/blog/how-to-add-metaprogramming-to-gleam/
> and identify anything unusual.
What strangeness are you expecting to encounter?
The type system should help you if you change any fields. It's hard for me to image this causing anything beyond slight annoyance at the small additional maintenance required as your types evolve.
Rust's serde crate defines a bunch of attributes that are commonly used: https://serde.rs/attributes.html
For example:
* Rename keys to lowercase, uppercase, snake_case, etc.
* Deserialize incoming data with a "type" field that specifies what enum variant it should target.
* Default to a value if the key doesn't exist.
* Skip serializing if it's None (or include it).
* Skip a field completely.
And the list goes on.
With a declarative macro system all attributes are immediately visible so I know what to expect but with Gleam I'd have to carefully read through the code every time to understand what it does. There's a ton of cognitive overload here that doesn't have to exist.
Remember that it's user data we're parsing so we'd have to maintain (update and debug) the code continually, which means reading through the boilerplate again and again.
How is gleam funded?
So purely through GitHub sponsors, that is it?
I like this language a lot. I find myself searching for something to make in it.
[dead]