> Sooner or later you come across something you need and there is no library for it. Then you are forced to start messing around with FFI and whatnot. I agree

> Sooner or later you come across something you need and there is no library for it. Then you are forced to start messing around with FFI and whatnot. I agree that it's always a little risky to bet on a young language. But I think Gleam is doing a good job of positioning itself as a smaller risk by sitting on the tried-and-true BEAM virtual machine and Javascript runtimes. If worst comes to worst you could export your compiled Gleam as Erlang or JS and it's quite readable. And Gleam's FFI with Erlang, Elixir and Javascript is pretty good. I don't think it will take long for a wide variety of packages from those platforms to become available on the Gleam package manager. Doing your own FFI is hardly intimidating - it's essentially just writing type definitions for the functions you need. Another factor giving me hope is that the language appears to be mostly 'done'. The author has carefully considered a minimal feature set and appears to be sticking to it, making it one of the simplest (typed) languages I've ever used syntax-wise. I think this bodes well for future growth, stability and maintainability.