> 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

> 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. [0] See an NIF as it is used https://github.com/davisp/jiffy/blob/master/src/jiffy.erl#L176 https://github.com/davisp/jiffy/blob/master/src/jiffy.erl#L1... the corresponding C boilerplate to interface with Erlang https://github.com/davisp/jiffy/blob/master/c_src/jiffy.c https://github.com/davisp/jiffy/blob/master/c_src/jiffy.c and the implementation of the guts of that NIF: https://github.com/davisp/jiffy/blob/master/c_src/decoder.c#L731 https://github.com/davisp/jiffy/blob/master/c_src/decoder.c#... [1] http://www.erlang.org/doc/tutorial/nif.html http://www.erlang.org/doc/tutorial/nif.html