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).
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).