Gleam v1.7
27 comments
·January 10, 2025TheMatten
Ndymium
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.
TheMatten
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.
Ndymium
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.
threatofrain
Anyone have some interesting things they've built with Gleam?
Ndymium
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
widdershins
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.
actionfromafar
Gleam vs Elixir? Go!
satvikpendem
Static types is all the reason I need to use Gleam over Elixir.
hoppp
I love elixir but gleam looks more easy to learn if you come from javascript
lawn
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).
norman784
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.
okkdev
You might be interested in this: https://lpil.uk/blog/how-to-add-metaprogramming-to-gleam/
hamandcheese
> 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.
lawn
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.
Nijikokun
I like this language a lot. I find myself searching for something to make in it.
gleamboi
[dead]
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.