> One lesson I took from the first .com wave in the early 2000 was never to use a scripting language for application software again.
A couple of things:
Both Erlang and Python compile down to bytecode. Python compiles the first time you run a given script, Erlang won't execute Erlang source code; you must compile it to run it.
As go1979 mentions, Erlang has HiPE, which compiles Erlang down to the host platform's native code. If you find that your program is spending a lot of time in the Erlang code in a given module, you can -at any time- recompile that module with HiPE and reload it with either a system restart, or the hot code reloading machinery.
As an additional escape hatch, Erlang makes it rather easy to push performance-critical code out to a faster language -like C or C++ or whatever- and call that directly from Erlang. [0] Such code is called an NIF [1].
If most or all of what you're doing is hard-core number crunching, Erlang is probably not appropriate. If what you're doing requires tricky logic, needs to contain failures, or you're building a concurrent or distributed system, Erlang may very well be the right tool for the job.
Erlang's HiPE compiler is apparently AOT. The challenge seems to be dynamic typing. At points, it has to guess types. I assume compiled Python would have similar issues.
Performance might not be on the top list, but when it comes usually a full re-write might be the only way out, as it was on our case.
Depending on the overall business situation such re-rewrite can have a huge impact on the company, due to shift on the development resources.
Since then, I only advice languages that have either JIT or AOT compilers available to them.