Not really, most of my programming experience is for devops/sysadmin scripts with shell/perl. I can read python/ruby from supporting application teams, but never programmed a large project or application with it myself. Last I used C was 25 years ago in some college courses and was never very good with it.
If you type a lot for a work, spending the time and money for better tooling is not only healthy but should be encouraged. Unhealthy, is when you try to track down an after market Key Cult for $2,000 and spend $500 on switches because you feel like you have to try them all.
I do like me some static typing but it took me a while to realize that the guards and pattern matching provides runtime guarantees and not just compile time guarantees.
You're not missing anything if you can and don't mind building a framework of tools that run long running processes, handle the start up, failure and state of those processes and be able to introspect the status and internal state of those processes in a standard way.
The way isolated processes can be created and managed allows for the "let it crash" ideology in Erlang. For example, when you visit a Phoenix Framework site, you have your own process. If I was visiting the same site and encountered a state that crashed my process your process would be unaffected. The "exception" would only affect me until you ran into the same state that caused the crashed.
If I reported the crash to the developer, the developer could fix the bug and soft start the entire application without affecting your process. This isn't possible because of the language per se but really because of the entire Erlang ecosystem around fault tolerance.
reply