5 ms·

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

by 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.
        lawn 10mo ago
        Yes, my point is that it's not a good experience.
        lpil 10mo ago
        I would be very interested in hearing about your experience writing Gleam and the problems you have! We regularly collect feedback and haven’t got problems reported here, so your feedback saying otherwise would be a useful data point.
        lawn 10mo ago
        I might try to collect my thoughts somewhere when I get some time over. Thank you for Gleam btw, I do really like the rest of the language.
      - 10mo ago
- lpil 10mo ago
  You can generate those conversions, most people do. But also, you shouldn’t think of it as writing the same type twice! If you couple your external API and your internal data model you are greatly restricting your domain modelling cability. Even in languages where JSON serialisation works with reflection I would recommend having a distinct definition for the internal and external structure so you can have the optimal structure for each context, dodging the “lowest common decimator” problem.
  - miki123211 10mo ago
    I understand your point, and I agree with it in most contexts! However, for the specific use case where one assumes that the client and server are running the exact same code (and the client auto-refreshes if this isn't the case), and where serialization is only used for synchronizing between the two, decoupling the state from it's representation on the wire doesn't really make sense.
    - lpil 10mo ago
      Totally. This is where I would generate them.
  - premek 10mo ago
    >You can generate those conversions, most people do. Hi, what do people use to generate them, I found gserde (edit: and glerd-json)
    - okkdev 10mo ago
      The language server code action :)
    - lpil 10mo ago
      There’s several options, depending on what you want. The most commonly used option is the language server.
      - premek 10mo ago
- worthless-trash 10mo ago
  Also. The lisp cam now generate serialisers and deserializers for some types iirc.
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.

by lpil 10mo ago

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.
      - lawn 10mo ago
        Yes, my point is that it's not a good experience.
        lpil 10mo ago
        I would be very interested in hearing about your experience writing Gleam and the problems you have! We regularly collect feedback and haven’t got problems reported here, so your feedback saying otherwise would be a useful data point.
        lawn 10mo ago
        I might try to collect my thoughts somewhere when I get some time over. Thank you for Gleam btw, I do really like the rest of the language.
    - 10mo ago
lpil 10mo ago
You can generate those conversions, most people do. But also, you shouldn’t think of it as writing the same type twice! If you couple your external API and your internal data model you are greatly restricting your domain modelling cability. Even in languages where JSON serialisation works with reflection I would recommend having a distinct definition for the internal and external structure so you can have the optimal structure for each context, dodging the “lowest common decimator” problem.
- miki123211 10mo ago
  I understand your point, and I agree with it in most contexts! However, for the specific use case where one assumes that the client and server are running the exact same code (and the client auto-refreshes if this isn't the case), and where serialization is only used for synchronizing between the two, decoupling the state from it's representation on the wire doesn't really make sense.
  - lpil 10mo ago
    Totally. This is where I would generate them.
- premek 10mo ago
  >You can generate those conversions, most people do. Hi, what do people use to generate them, I found gserde (edit: and glerd-json)
  - okkdev 10mo ago
    The language server code action :)
  - lpil 10mo ago
    There’s several options, depending on what you want. The most commonly used option is the language server.
    - premek 10mo ago
worthless-trash 10mo ago
Also. The lisp cam now generate serialisers and deserializers for some types iirc.

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.