> I'm the last person on Earth to tell someone to be patient, but if you actually want to ship a company's production code in Gleam or Crystal, I highly suggest

> I'm the last person on Earth to tell someone to be patient, but if you actually want to ship a company's production code in Gleam or Crystal, I highly suggest you put up 2-4 small projects first As someone who has used Nim in-anger and production at a couple companies now (and am currently using it to build our firmware for our industrial IoT sensor platform), I can wholeheartedly agree with this. The first couple things I built in it at previous positions were small internal tools. They went well, team members contributed to them as well, things were good. It was that, plus the unique constraints of this firmware project that allowed us to have the confidence that it would work well -- and it has. Of course, Nim is sort of cheating, as it being able to be compiled-to-C-sources means we have an out at any point we want, both in terms of being able to easily bind and use driver code from vendors, to wrapping up a Nim object file with a nice C header to call from some C/C++ code if need be. Now: our backend is Java, and our front-end is Typescript and React. Pick your battles! If we were swinging for the fences with some other niche server side, and Elm or something (as much as I enjoy playing with it) for the client-side, as well as trying to use something non-standard for the firmware itself, I'm sure we would've failed immediately. But we have our devices out in the wild in rural Papua New Guinea where no one's going to be flashing our boards for us, and they're working fantastically :)