The doc contains cheatsheets such as "Gleam for X users" where X is currently Erlang, Elixir, Rust and Python. I think this is a fantastic idea and could be adopted by other language communities!
Might I ask for some more guidelines on how to incrementally incorporate Gleam into existing projects in BEAM languages? A guide on interpolation with a phoenix codebase and toolchain would be wicked cool.
This is certainly something I want to have in future. Being able to add Gleam to an existing Elixir project is something a lot of people have asked for. It is possible today (Quinn did a great talk on this[1]) and there are libraries to help[2], but it's all a bit rough and ready currently.
The focus for now is on Gleam tooling, but once we have that down we can work more on Elixir tooling for Gleam.
> The doc contains cheatsheets such as "Gleam for X users" where X is currently Erlang, Elixir, Rust and Python. I think this is a fantastic idea and could be adopted by other language communities!
The Rust ndarray library as a "ndarray for numpy users" [0] which I thought was a very nice idea to help people from the python world convert their numpy code to Rust.
I agree, the cheatsheets are great. As a Python developer. the python sheet makes me file like I could dive write in and write a gleam program by having python in mind mind and looking up the gleam equivalent for each line of code.
But where it describes the map-dictionary duality, it says: "There is no map literal syntax in Gleam, and you cannot pattern match on a map. Maps are generally not used much in Gleam, custom types are more common."
But it doesn't say why or how this would be done. It seems that, if this point is going to be mentioned, there should be enough context to make it actionable.
Might I ask for some more guidelines on how to incrementally incorporate Gleam into existing projects in BEAM languages? A guide on interpolation with a phoenix codebase and toolchain would be wicked cool.