5 ms·
Gleam v1.7
- threatofrain 2y agoAnyone have some interesting things they've built with Gleam?
- Ndymium 2y agoI'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 https://git.ahlcode.fi/nicd/elektrofoni [1] https://hexdocs.pm/scriptorium/index.html https://hexdocs.pm/scriptorium/index.html [2] https://blog.nytsoi.net https://blog.nytsoi.net
- widdershins 2y agoI'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 2y agoGleam vs Elixir? Go!
- hoppp 2y agoI love elixir but gleam looks more easy to learn if you come from javascript
- AlchemistCamp 2y agoIt 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.
- lawn 2y agoI 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.
- AlchemistCamp 2y agoBeing typed would make it harder, not easier for a JS dev. Syntax is a very surface-level difference and is basically a rounding error in cases like this after the very initial stages. If I were to try to make the argument for you, I'd point to some of Elixir's more powerful abstractions like protocols and macros as a reason Elixir might be harder for JS devs. In reality, though, I found it very straightforward to learn as a JS dev, and that was back in 2016 when the documentation was much worse.
- satvikpendem 2y agoStatic types is all the reason I need to use Gleam over Elixir.
- Fire-Dragon-DoL 2y agoI 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
- ilrwbwrkhv 2y agoHow is gleam funded?
- wavemode 2y agohttps://github.com/sponsors/lpil https://github.com/sponsors/lpil
- guims767 2y agoalso https://github.com/sponsors/giacomocavalieri https://github.com/sponsors/giacomocavalieri
- ilrwbwrkhv 2y agoSo purely through GitHub sponsors, that is it?
- gleamboi 2y ago[dead]
- lawn 2y agoI'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 2y agoI 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.
- hamandcheese 2y ago> 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 2y agoRust's serde crate defines a bunch of attributes that are commonly used: https://serde.rs/attributes.html 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.
- TheMatten 2y agoVery 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.
- Ndymium 2y agoHow 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 2y agoThe 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 2y agoSince 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.
- Nijikokun 2y agoI like this language a lot. I find myself searching for something to make in it.