Thoughts on adding Gleam #82

Activity

1. onno-vos-dev commented on Jan 3, 2025

   

   onno-vos-dev

   on Jan 3, 2025

   Member

   More actions

   Hi @SundayPowerEndre While I'd be (cautiously) open to adding support for Gleam, isn't one of the strengths of Gleam that it can anything? Either Gleam, Elixir or Erlang without any real "hassle"? I'd like to understand better what problems you're running into before diving down the rabbit hole of adding native Gleam support and produce a aws-gleam package 😅

   Multilingual
   Gleam makes it easy to use code written in other BEAM languages such as Erlang and Elixir, so there's a rich ecosystem of thousands of open source libraries for Gleam users to make use of.
   
2. SundayPowerEndre commented on Jan 3, 2025

   

   SundayPowerEndre

   on Jan 3, 2025

   Last edited by SundayPowerEndre

   Author

   More actions

   Hey @onno-vos-dev,

   Thank you for responding so quickly! I completely understand your concerns. And I'm not even sure I think it is a good idea to have an aws-gleam package 😅 It was just something I wished I had ^^

   I discovered this package after building my own solution to access my roles in EC2. The main hassle was that I couldn't find any native Gleam solutions. I was initially looking into finding a Gleam implementation of the default credential provider, so it would be typed. The real problem was that I wanted to be able to have a typed SDK in the same way that I am used to in Java/TS/.NET etc.

   The reason I suggested a separate package was that I thought it might be better to separate it into its own package since Gleam is a statically-typed language. This separation would benefit from having all functions explicitly typed in Gleam. However, implementing this with the code generator might be a bit overzealous 😅.

   I can immediately think of three potential solutions that would make it a lot nicer to run Gleam on AWS:

   Create an aws-gleam Package with Elixir Integration: We could develop a new aws-gleam package that includes an Elixir or Erlang project built from the code generator, along with Gleam type definitions. Then we can use Gleam Externals, which would be closest to what I think you mentioned should be Gleams strength.

   Develop a Go to Gleam Code Generator: Alternatively, we could create a code generator that transforms Go SDK types directly into Gleam's type system within an aws-gleam package. Which honestly sounds quite ambitious and like it requires a lot of work..

   Build Type Definitions for DefaultCredentialProvider: We could include only the default credential provider with Gleam types in this project and let someone else (e.g., me) handle implementing the AWS SDKs for Gleam. Having the Default Credential Provider is a very good starting point for building the other SDKs as independent separate packages.

   I am still not certain that it is the right way to go about this, but i am curious to hear what you think
3. SundayPowerEndre commented on Jan 19, 2025

   

   SundayPowerEndre

   on Jan 19, 2025

   Author

   More actions

   Hey, i have been testing the FFI approach more, it is not a very smooth experience to get it to work initially.

   This strengths my thought that either a native gleam codegen solution, or atleast a properly handled AWS Credential Provider in Gleam would be the way to go.

   Since you seemed quite reserved to add Gleam, i'd really appreciate your feedback on what you think is most viable.

   Hope to hear back from you