Mmm... Erlang isn't particularly good for scripting. It has an elaborate deployment process. It doesn't like OS interfaces very much, and usually tries to offer alternatives, which are often better designed, but it also means there's a thick layer between you and the system you are scripting. While Erlang support for native code is a lot better than, say, in Python, it's better in terms of quality of the output not in terms of how easy it is to accomplish. In scripts you rarely care about quality or generalizations.
I don't see how working with types in scripts would be helpful. To me this looks like a bad idea. Everything being a string is a very valuable feature of Unix Shell. Once you have to spell out types interactively your life becomes a misery. I had similar experience having to do some testing for a mostly Linux-based product on MS Windows (an iSCSI portal that I needed to check if the MS side can connect to).
Using PowerShell is like talking to a very pedantic and a very stupid army bureaucrat, where each time you speak you have to define every word you use afresh, declare the titles of all people involved in a conversation up-front and in the end, all while being unable to connect two obviously related pieces of information because the said bureaucrat has no folder that can contain both.
So, IMO, Erlang or any other Beam language would be awesome for infra automation, and it only gets better the bigger is the organization that infra is supporting. I'm not sure there's any benefit to having ML-style explicit typing in a Beam language though. To explain this better: in the times Flash was relevant, AVM -- Flash' virtual machine was written in such a way that it had to perform runtime type checks almost every other instruction. If you could prove types statically (which Haxe did), then you could generate much tighter bytecode which lead both to smaller memory footprint and somewhat faster execution.
I don't think Beam works in the same way. So, being able to statically prove something about your code doesn't give you the same kind of benefits. And the remaining benefits could be eclipsed by the effort necessary to support the code containing type assertions (i.e. the extra testing that you need to do to assure the type assertions are correct, the increased refactoring cost and valid functionality prevented by lack of insight on the part of the programmer writing type assertions might not be worth the correctness guarantees given by these assertions).
Rust was partially inspired by F# and OCaml and actually had a much more ML-like syntax early on. Probably something similar goes for Typescript. And actually, the same for Gleam as well.
F# doesn't really relate to Haskell at all. They are very different languages. F# is a multiparadigm language that easily supports concise code in the imperative, OOP, and functional styles.
It sounds like you maybe don't know much about F# if you think it's like Haskell, which is okay. But that's also why I would recommend checking it out.
F# is not Haskell at all. If you want to write non functional code you can. It's functional first but it has side effects, mutable variables and a host of features you get in other languages. I really recommend trying it.
However, to script something small/casual I would like all the rest of Rust but with automatic garbage collection, without having to worry about lifetimes.
