Thoughts on adding Gleam

[SundayPowerEndre]

Hey 👋🏽

I have tried to run Gleam on AWS and found it to be a bit of a hassel. This project more or less seems like exactly what i was looking for.

I could be interested in contributing some to this project if it would seem feasible to make a Gleam target from the code generator.

Due to having limited understanding of the project, i was wondering the maintainers have any initial thoughts in regards to this?

[onno-vos-dev]

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.

[SundayPowerEndre]

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

[SundayPowerEndre]

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