7 ms·

Gleam is a beautiful language, and what I wish Elixir would become (re:typing). For those that don't know its also built upon OTP, the erlang vm that makes con

by bnchrch 10mo ago

Gleam is a beautiful language, and what I wish Elixir would become (re:typing). For those that don't know its also built upon OTP, the erlang vm that makes concurrency and queues a trivial problem in my opinion. Absolutely wonderful ecosystem. I've been wanting to make Gleam my primary language, but I fear LLMs have frozen programming language advancement and adoption for anything past 2021. But I am hopeful that Gleam has slid just under the closing door and LLMs will get up to speed on it fast.

sbuttgereit 10mo ago
> For those that don't know its also built upon OTP, the erlang vm This isn't correct. It can compile to run on the BEAM: that is the Erlang VM. OTP isn't the Erlang VM; rather, "OTP is set of Erlang libraries and design principles providing middle-ware to develop [concurrent/distributed/fault tolerant] systems." Gleam itself provides what I believe is a substantial subset of OTP support via a library: https://github.com/gleam-lang/otp https://github.com/gleam-lang/otp Importantly: "Gleam has its own version of OTP which is type safe, but has a smaller feature set. [vs. Elixir, another BEAM language with OTP support]"
- lpil 10mo ago
  Hi, I’m the creator of Gleam! The comment you are replying to is correct, and you are incorrect. All OTP APIs are usable as normal within Gleam, the language is designed with it in mind, and there’s an additional set of Gleam specific additions to OTP (which you have linked there). Gleam does not have access to only a subset of OTP, and it does not have its own distinct OTP inspired OTP. It uses the OTP framework.
  - tazjin 10mo ago
    (I know Erlang well, but haven't used Gleam) The library the parent links to says this: > Not all Erlang/OTP functionality is included in this library. Some is not possible to represent in a type safe way, so it is not included. Does this mean in practice that you can use all parts of OTP, but you might lose type checking for the parts the library doesn't cover?
    - lpil 10mo ago
      No, it means that one specific package only offers bindings to certain parts. It’s the documentation for one library, not the language.
  - miki123211 10mo ago
    > Hi, I’m the creator of Gleam! What's the state of Gleam's JSON parsing / serialization capabilities right now? I find it to be a lovely little language, but having to essentially write every type three times (once for the type definition, once for the serializer, once for the deserializer) isn't something I'm looking forward to. A functional language that can run both on the backend (Beam) and frontend (JS) lets one do a lot of cool stuff, like optimistic updates, server reconciliation, easy rollback on failure etc, but that requires making actions (and likely also states) easily serializable and deserializable.
    - lawn 10mo ago
      This is also what really annoyed me when I tried out Gleam. I'm waiting for something similar to serde in Rust, where you simply tag your type and it'll generate type-safe serialization and deserialization for you. Gleam has some feature to generate the code for you via the LSP, but it's just not good enough IMHO.
      - lpil 10mo ago
        Multiple of such tools exist and have done for years. Serde isn’t a Rust-core project, and similarly the Gleam alternatives are not Gleam-core.
        lawn 10mo ago
        Rust has macros that make serde very convenient, which Gleam doesn't have. Could you point to a solution that provides serde level of convenience? Edit: The difference with generating code (like with Gleam) and having macros generate the code from a few tags is quite big. Small tweaks are immediately obvious in serde in Rust, but they drown in the noise in the complete serialization code like with the Gleam tools.
        lpil 10mo ago
        In Gleam code generators are most commonly used, similar to in C#, Go, or Elm.
  - sbuttgereit 10mo ago
    Fair enough, but to be fair to my statements, the quotes I chose were largely from gleam-lang.org or the Gleam OTP library. Take for example this section of the Gleam website FAQ section: https://gleam.run/frequently-asked-questions/#how-does-gleam-compare-to-elixir https://gleam.run/frequently-asked-questions/#how-does-gleam... "Elixir has better support for the OTP actor framework. Gleam has its own version of OTP which is type safe, but has a smaller feature set." At least on the surface, "but has a smaller feature set" suggests that there are features left of the table: which I think it would be fair to read as a subset of support. If I look at this statement from the Gleam OTP Library `readme.md`: "Not all Erlang/OTP functionality is included in this library. Some is not possible to represent in a type safe way, so it is not included. Other features are still in development, such as further process supervision strategies." That quote leaves the impression that OTP is not fully supported and therefore only a subset is. It doesn't expound further to say unsupported OTP functionality is alternatively available by accessing the Erlang modules/functions directly or through other mechanisms. In all of this I'll take your word for it over the website and readme files; these things are often not written directly by the principals and are often not kept as up-to-date as you'd probably like. Still even taking that at face value, I think it leaves some questions open. What is meant by supporting all of OTP? Where the documentation and library readme equivocates to full OTP support, are there trade-offs? Is "usable as normal" usable as normal for Erlang or as normal for Gleam? For example, are the parts left out of the library available via directly accessing the Erlang modules/functions, but only at the cost of abandoning the Gleam type safety guarantees for those of Erlang? How does this hold for Gleam's JavaScript compilation target? As you know, Elixir also provides for much OTP functionality via direct access to the Erlang libraries. However, there I expect the distinction between Elixir support and the Erlang functionality to be substantially more seamless than with Gleam: Elixir integrates the Erlang concepts of typing (etc.) much more directly than does Gleam. If, however, we're really talking about full OTP support in Gleam while not losing the reasons you might choose Gleam over Elixir or Erlang, which I think is mostly going to be about the static typing... then yes, I'm very wrong. If not... I could see how strictly speaking I'm wrong, but perhaps not completely wrong in spirit.
    - lpil 10mo ago
      Ah, that’s good feedback. I agree, that documentation is misleading. I’ll fix them ASAP. > Elixir also provides for much OTP functionality via direct access to the Erlang libraries. This is the norm in Gleam too! Gleam’s primary design constraint is interop with Erlang code, so using these libraries is straightforward and commonplace.
agos 10mo ago
the Erlang vm is called BEAM, not OTP. sadly, Gleam's implementation of OTP is not at the same level as Elixir's or Erlang.
- lpil 10mo ago
  Gleam uses regular OTP, it doesn’t have a distinct OTP inspired framework. Source: I’m the author of Gleam.
  - girvo 10mo ago
    I wonder why so many have got this wrong across this thread? Was it true once upon a time or something, or have people just misunderstood your docs or similar?
    - lpil 10mo ago
      OTP is a very complex subject and quite unusual in its scope, and it’s not even overly clear what it even is. Even in Erlang and Elixir it’s commonly confused, so I think it’s understandable that Gleam has the same problem further still with its more distinct programming style.
  - andy_ppp 10mo ago
    "Big Elixir" must be paying people to misunderstand Gleam today eh ;-)
  - constructive 10mo ago
    who cares, just dont shove political opinions into a software project that developers. we are devs not jobless sjw's running around the road with some useless sign board
    - lpil 10mo ago
      Free software was started as a political movement by Stallman et al. Why would we stop now?
    - 10mo ago
Uehreka 10mo ago
> I fear LLMs have frozen programming language advancement and adoption for anything past 2021. Why would that be the case? Many models have knowledge cutoffs in this calendar year. Furthermore I’ve found that LLMs are generally pretty good at picking up new (or just obscure) languages as long as you have a few examples. As wide and varied as programming languages are, syntactically and ideologically they can only be so different.
- schrodinger 10mo ago
  The motivation isn’t there to create new languages for humans when you’re programming at a higher level of abstraction now (AI prompting). It’d be like inventing a new assembly language when everyone is writing code in higher level languages that compile to assembly. I hope it’s not true, but I believe that’s what OP meant and I think the concern is valid!
  - pxc 10mo ago
    > It’d be like inventing a new assembly language when everyone is writing code in higher level languages that compile to assembly. Isn't that what WASM is? Or more or less what is going on when people devise a new intermediate representation for a new virtual machine? Creating new assembly languages is a useful thing that people continue to do!
  - rapind 10mo ago
    We may end up using AI to create simplified bespoke subset languages that fit our preferences. Like a DSL of sorts but with better performance characteristics than a traditional DSL and a small enough surface area.
  - merlincorey 10mo ago
    I believe prompting an AI is more like delegation than abstraction especially considering the non-deterministic nature of the results.
    - sarchertech 10mo ago
innocentoldguy 10mo ago
I don’t mean to minimize the huge effort by the Gleam team; however, Elixir cannot become Gleam without breaking OTP/BEAM in the same ways Gleam does. As it stands now, Elixir is the superior language between the two, if using the full Erlang VM is your goal.
- worthless-trash 10mo ago
  I use many of the otp functions in gleam on thr regular, what functionality cant i call? Gleam can call any erlang function, and can somewhat handle the idc types. [ im sure it has another name ]. Did i miss something that gleam fails on, because this is one of my concerns.
  - innocentoldguy 10mo ago
    - No state machine behaviours. Gleam cannot do gen_statem. - Limited OTP system messages. Gleam doesn't yet support all OTP system messages, so some OTP debugging messages are discarded by Gleam. - Gleam doesn't have an equivalent of gen_event to handle event handlers. - Gleam doesn't support DynamicSupervisor or the :simple_one_for_one for dynamically starting children at runtime.
    - worthless-trash 10mo ago
      I didn't know about the statem limitation, I have howerver worked around it with gen server like wrapper, that way all state transitions were handled with gleams type system. I have been meaning to ask about that on the discord but its one of the ten thousand things on my backlog. Maybe i could write a gen_event equivalent.. I have some code which does very similar things. Thank you for taking the time to respond.
      - innocentoldguy 10mo ago
        You're welcome. I'm sure at some point, Gleam will figure it all out.
market_hacker 10mo ago
i just implemented a project in elixir with LLM support and would never have considered that before. (i had never used elixir before) - So who knows maybe it will help adoption?
troupo 10mo ago
> what I wish Elixir would become (re:typing). Elixir is slowly rolling out set-theoretic typing: https://hexdocs.pm/elixir/main/gradual-set-theoretic-types.html https://hexdocs.pm/elixir/main/gradual-set-theoretic-types.h...
- tasuki 10mo ago
  I dunno, my unfounded guess is that gradual type systems are super complex and very hard to get right. Why use something complex and half working, when you can have the real thing?
  - troupo 10mo ago
    They are working towards "the real thing", whatever your definition of real is. BTW in the 90s people tried to come up with a type system for Erlang, and failed: --- start quote --- Phil Wadler[1] and Simon Marlow [2] worked on a type system for over a year and the results were published in [3]. The results of the project were somewhat disappointing. To start with, only a subset of the language was type-checkable, the major omission being the lack of process types and of type checking inter-process mes-sages. Although their type system was never put into production, it did result in a notation for types which is still in use today for informally annotating types. Several other projects to type check Erlang also failed to produce results that could be put into production. It was not until the advent of the Dialyzer [4] that realistic type analysis of Erlang programs became possible. https://lfe.io/papers/%5B2007%5D%20Armstrong%20-%20HOPL%20III%20A%20History%20of%20Erlang.pdf https://lfe.io/papers/%5B2007%5D%20Armstrong%20-%20HOPL%20II... --- end quote --- [1] Yes, that Philip Wadler, https://en.wikipedia.org/wiki/Philip_Wadler https://en.wikipedia.org/wiki/Philip_Wadler [2] Yes, that Simon Marlow, https://en.wikipedia.org/wiki/Simon_Marlow https://en.wikipedia.org/wiki/Simon_Marlow [3] A practical subtyping system for Erlang https://dl.acm.org/doi/10.1145/258948.258962 https://dl.acm.org/doi/10.1145/258948.258962 [4] https://www.erlang.org/doc/apps/dialyzer/dialyzer.html https://www.erlang.org/doc/apps/dialyzer/dialyzer.html
  - foxygen 10mo ago
    I hate how people talk about type systems as if there were no trade-offs to be considered. A Hindley–Milner style type system would effectively kill half the features that make Elixir amazing, and worse, would break pretty much all existing code.
devalexwells 10mo ago
I've also been wanting to make Gleam my primary language (am generally a Typescript dev), and I have not had any issue with using it with LLMs (caveat, I'm obviously still new with it, so might just be ignorant). In fact, I'd say most of the Gleam code that has been generated has been surprisingly reliable and easy to reason about. I suspect this has to do with the static typing, incredible language tooling, and small surface area of the language. I literally just copy the docs from https://tour.gleam.run/everything/ https://tour.gleam.run/everything/ into a local MD file and let it run. Packages are also well documented, and Claude has had no issue looping with tests/type checking. In the past month I've built the following, all primarily with Claude writing the Gleam parts: - A websocket-first analytics/feature flag platform (Gleam as the backend): https://github.com/devdumpling/beacon https://github.com/devdumpling/beacon - A realtime holiday celebration app for my team where Gleam manages presence, cursor state, emojis, and guestbook writes (still rough): https://github.com/devdumpling/snowglobe https://github.com/devdumpling/snowglobe - A private autobattler game backend built for the web While it's obviously not as well-trodden as building in typescript or Go or Rust, I've been really happy with the results as someone not super familiar with the BEAM/Erlang. EDIT: Sorry I don't have demos up for these yet. Wasn't really ready to share them but felt relevant to this thread.
constructive 10mo ago
[flagged]
- nodra 10mo ago
  I don’t know anything about gleam. I couldn’t find anything as “shoving political ideologies” on their code of conduct https://github.com/gleam-lang/gleam/blob/main/CODE_OF_CONDUCT.md https://github.com/gleam-lang/gleam/blob/main/CODE_OF_CONDUC... Examples?
  - constructive 10mo ago
    homepage

by bnchrch 10mo ago

sbuttgereit 10mo ago

> For those that don't know its also built upon OTP, the erlang vm This isn't correct. It can compile to run on the BEAM: that is the Erlang VM. OTP isn't the Erlang VM; rather, "OTP is set of Erlang libraries and design principles providing middle-ware to develop [concurrent/distributed/fault tolerant] systems." Gleam itself provides what I believe is a substantial subset of OTP support via a library: https://github.com/gleam-lang/otp https://github.com/gleam-lang/otp Importantly: "Gleam has its own version of OTP which is type safe, but has a smaller feature set. [vs. Elixir, another BEAM language with OTP support]"

lpil 10mo ago
Hi, I’m the creator of Gleam! The comment you are replying to is correct, and you are incorrect. All OTP APIs are usable as normal within Gleam, the language is designed with it in mind, and there’s an additional set of Gleam specific additions to OTP (which you have linked there). Gleam does not have access to only a subset of OTP, and it does not have its own distinct OTP inspired OTP. It uses the OTP framework.
- tazjin 10mo ago
  (I know Erlang well, but haven't used Gleam) The library the parent links to says this: > Not all Erlang/OTP functionality is included in this library. Some is not possible to represent in a type safe way, so it is not included. Does this mean in practice that you can use all parts of OTP, but you might lose type checking for the parts the library doesn't cover?
  - lpil 10mo ago
    No, it means that one specific package only offers bindings to certain parts. It’s the documentation for one library, not the language.
- miki123211 10mo ago
  > Hi, I’m the creator of Gleam! What's the state of Gleam's JSON parsing / serialization capabilities right now? I find it to be a lovely little language, but having to essentially write every type three times (once for the type definition, once for the serializer, once for the deserializer) isn't something I'm looking forward to. A functional language that can run both on the backend (Beam) and frontend (JS) lets one do a lot of cool stuff, like optimistic updates, server reconciliation, easy rollback on failure etc, but that requires making actions (and likely also states) easily serializable and deserializable.
  - lawn 10mo ago
    This is also what really annoyed me when I tried out Gleam. I'm waiting for something similar to serde in Rust, where you simply tag your type and it'll generate type-safe serialization and deserialization for you. Gleam has some feature to generate the code for you via the LSP, but it's just not good enough IMHO.
    - lpil 10mo ago
      Multiple of such tools exist and have done for years. Serde isn’t a Rust-core project, and similarly the Gleam alternatives are not Gleam-core.
      - lawn 10mo ago
        Rust has macros that make serde very convenient, which Gleam doesn't have. Could you point to a solution that provides serde level of convenience? Edit: The difference with generating code (like with Gleam) and having macros generate the code from a few tags is quite big. Small tweaks are immediately obvious in serde in Rust, but they drown in the noise in the complete serialization code like with the Gleam tools.
        lpil 10mo ago
        In Gleam code generators are most commonly used, similar to in C#, Go, or Elm.
- sbuttgereit 10mo ago
  Fair enough, but to be fair to my statements, the quotes I chose were largely from gleam-lang.org or the Gleam OTP library. Take for example this section of the Gleam website FAQ section: https://gleam.run/frequently-asked-questions/#how-does-gleam-compare-to-elixir https://gleam.run/frequently-asked-questions/#how-does-gleam... "Elixir has better support for the OTP actor framework. Gleam has its own version of OTP which is type safe, but has a smaller feature set." At least on the surface, "but has a smaller feature set" suggests that there are features left of the table: which I think it would be fair to read as a subset of support. If I look at this statement from the Gleam OTP Library `readme.md`: "Not all Erlang/OTP functionality is included in this library. Some is not possible to represent in a type safe way, so it is not included. Other features are still in development, such as further process supervision strategies." That quote leaves the impression that OTP is not fully supported and therefore only a subset is. It doesn't expound further to say unsupported OTP functionality is alternatively available by accessing the Erlang modules/functions directly or through other mechanisms. In all of this I'll take your word for it over the website and readme files; these things are often not written directly by the principals and are often not kept as up-to-date as you'd probably like. Still even taking that at face value, I think it leaves some questions open. What is meant by supporting all of OTP? Where the documentation and library readme equivocates to full OTP support, are there trade-offs? Is "usable as normal" usable as normal for Erlang or as normal for Gleam? For example, are the parts left out of the library available via directly accessing the Erlang modules/functions, but only at the cost of abandoning the Gleam type safety guarantees for those of Erlang? How does this hold for Gleam's JavaScript compilation target? As you know, Elixir also provides for much OTP functionality via direct access to the Erlang libraries. However, there I expect the distinction between Elixir support and the Erlang functionality to be substantially more seamless than with Gleam: Elixir integrates the Erlang concepts of typing (etc.) much more directly than does Gleam. If, however, we're really talking about full OTP support in Gleam while not losing the reasons you might choose Gleam over Elixir or Erlang, which I think is mostly going to be about the static typing... then yes, I'm very wrong. If not... I could see how strictly speaking I'm wrong, but perhaps not completely wrong in spirit.
  - lpil 10mo ago
    Ah, that’s good feedback. I agree, that documentation is misleading. I’ll fix them ASAP. > Elixir also provides for much OTP functionality via direct access to the Erlang libraries. This is the norm in Gleam too! Gleam’s primary design constraint is interop with Erlang code, so using these libraries is straightforward and commonplace.

agos 10mo ago

the Erlang vm is called BEAM, not OTP. sadly, Gleam's implementation of OTP is not at the same level as Elixir's or Erlang.

lpil 10mo ago
Gleam uses regular OTP, it doesn’t have a distinct OTP inspired framework. Source: I’m the author of Gleam.
- girvo 10mo ago
  I wonder why so many have got this wrong across this thread? Was it true once upon a time or something, or have people just misunderstood your docs or similar?
  - lpil 10mo ago
    OTP is a very complex subject and quite unusual in its scope, and it’s not even overly clear what it even is. Even in Erlang and Elixir it’s commonly confused, so I think it’s understandable that Gleam has the same problem further still with its more distinct programming style.
- andy_ppp 10mo ago
  "Big Elixir" must be paying people to misunderstand Gleam today eh ;-)
- constructive 10mo ago
  who cares, just dont shove political opinions into a software project that developers. we are devs not jobless sjw's running around the road with some useless sign board
  - lpil 10mo ago
    Free software was started as a political movement by Stallman et al. Why would we stop now?
  - 10mo ago

Uehreka 10mo ago

> I fear LLMs have frozen programming language advancement and adoption for anything past 2021. Why would that be the case? Many models have knowledge cutoffs in this calendar year. Furthermore I’ve found that LLMs are generally pretty good at picking up new (or just obscure) languages as long as you have a few examples. As wide and varied as programming languages are, syntactically and ideologically they can only be so different.

schrodinger 10mo ago
The motivation isn’t there to create new languages for humans when you’re programming at a higher level of abstraction now (AI prompting). It’d be like inventing a new assembly language when everyone is writing code in higher level languages that compile to assembly. I hope it’s not true, but I believe that’s what OP meant and I think the concern is valid!
- pxc 10mo ago
  > It’d be like inventing a new assembly language when everyone is writing code in higher level languages that compile to assembly. Isn't that what WASM is? Or more or less what is going on when people devise a new intermediate representation for a new virtual machine? Creating new assembly languages is a useful thing that people continue to do!
- rapind 10mo ago
  We may end up using AI to create simplified bespoke subset languages that fit our preferences. Like a DSL of sorts but with better performance characteristics than a traditional DSL and a small enough surface area.
- merlincorey 10mo ago
  I believe prompting an AI is more like delegation than abstraction especially considering the non-deterministic nature of the results.
  - sarchertech 10mo ago

innocentoldguy 10mo ago

I don’t mean to minimize the huge effort by the Gleam team; however, Elixir cannot become Gleam without breaking OTP/BEAM in the same ways Gleam does. As it stands now, Elixir is the superior language between the two, if using the full Erlang VM is your goal.

worthless-trash 10mo ago
I use many of the otp functions in gleam on thr regular, what functionality cant i call? Gleam can call any erlang function, and can somewhat handle the idc types. [ im sure it has another name ]. Did i miss something that gleam fails on, because this is one of my concerns.
- innocentoldguy 10mo ago
  - No state machine behaviours. Gleam cannot do gen_statem. - Limited OTP system messages. Gleam doesn't yet support all OTP system messages, so some OTP debugging messages are discarded by Gleam. - Gleam doesn't have an equivalent of gen_event to handle event handlers. - Gleam doesn't support DynamicSupervisor or the :simple_one_for_one for dynamically starting children at runtime.
  - worthless-trash 10mo ago
    I didn't know about the statem limitation, I have howerver worked around it with gen server like wrapper, that way all state transitions were handled with gleams type system. I have been meaning to ask about that on the discord but its one of the ten thousand things on my backlog. Maybe i could write a gen_event equivalent.. I have some code which does very similar things. Thank you for taking the time to respond.
    - innocentoldguy 10mo ago
      You're welcome. I'm sure at some point, Gleam will figure it all out.

market_hacker 10mo ago

i just implemented a project in elixir with LLM support and would never have considered that before. (i had never used elixir before) - So who knows maybe it will help adoption?

troupo 10mo ago

> what I wish Elixir would become (re:typing). Elixir is slowly rolling out set-theoretic typing: https://hexdocs.pm/elixir/main/gradual-set-theoretic-types.html https://hexdocs.pm/elixir/main/gradual-set-theoretic-types.h...

tasuki 10mo ago
I dunno, my unfounded guess is that gradual type systems are super complex and very hard to get right. Why use something complex and half working, when you can have the real thing?
- troupo 10mo ago
  They are working towards "the real thing", whatever your definition of real is. BTW in the 90s people tried to come up with a type system for Erlang, and failed: --- start quote --- Phil Wadler[1] and Simon Marlow [2] worked on a type system for over a year and the results were published in [3]. The results of the project were somewhat disappointing. To start with, only a subset of the language was type-checkable, the major omission being the lack of process types and of type checking inter-process mes-sages. Although their type system was never put into production, it did result in a notation for types which is still in use today for informally annotating types. Several other projects to type check Erlang also failed to produce results that could be put into production. It was not until the advent of the Dialyzer [4] that realistic type analysis of Erlang programs became possible. https://lfe.io/papers/%5B2007%5D%20Armstrong%20-%20HOPL%20III%20A%20History%20of%20Erlang.pdf https://lfe.io/papers/%5B2007%5D%20Armstrong%20-%20HOPL%20II... --- end quote --- [1] Yes, that Philip Wadler, https://en.wikipedia.org/wiki/Philip_Wadler https://en.wikipedia.org/wiki/Philip_Wadler [2] Yes, that Simon Marlow, https://en.wikipedia.org/wiki/Simon_Marlow https://en.wikipedia.org/wiki/Simon_Marlow [3] A practical subtyping system for Erlang https://dl.acm.org/doi/10.1145/258948.258962 https://dl.acm.org/doi/10.1145/258948.258962 [4] https://www.erlang.org/doc/apps/dialyzer/dialyzer.html https://www.erlang.org/doc/apps/dialyzer/dialyzer.html
- foxygen 10mo ago
  I hate how people talk about type systems as if there were no trade-offs to be considered. A Hindley–Milner style type system would effectively kill half the features that make Elixir amazing, and worse, would break pretty much all existing code.

devalexwells 10mo ago

I've also been wanting to make Gleam my primary language (am generally a Typescript dev), and I have not had any issue with using it with LLMs (caveat, I'm obviously still new with it, so might just be ignorant). In fact, I'd say most of the Gleam code that has been generated has been surprisingly reliable and easy to reason about. I suspect this has to do with the static typing, incredible language tooling, and small surface area of the language. I literally just copy the docs from https://tour.gleam.run/everything/ https://tour.gleam.run/everything/ into a local MD file and let it run. Packages are also well documented, and Claude has had no issue looping with tests/type checking. In the past month I've built the following, all primarily with Claude writing the Gleam parts: - A websocket-first analytics/feature flag platform (Gleam as the backend): https://github.com/devdumpling/beacon https://github.com/devdumpling/beacon - A realtime holiday celebration app for my team where Gleam manages presence, cursor state, emojis, and guestbook writes (still rough): https://github.com/devdumpling/snowglobe https://github.com/devdumpling/snowglobe - A private autobattler game backend built for the web While it's obviously not as well-trodden as building in typescript or Go or Rust, I've been really happy with the results as someone not super familiar with the BEAM/Erlang. EDIT: Sorry I don't have demos up for these yet. Wasn't really ready to share them but felt relevant to this thread.

constructive 10mo ago

[flagged]

nodra 10mo ago
I don’t know anything about gleam. I couldn’t find anything as “shoving political ideologies” on their code of conduct https://github.com/gleam-lang/gleam/blob/main/CODE_OF_CONDUCT.md https://github.com/gleam-lang/gleam/blob/main/CODE_OF_CONDUC... Examples?
- constructive 10mo ago
  homepage