Usually the intuitive way to use strings ends up being multiple orders of magnitude slower than using a combination of macros and IO lists.
I've had some implementations of things go from taking 700ms down to < 10ms by doing nothing except replace using the String and Enum modules with an IO list and macros to remove an Enum.reduce call. Problem is, I had to ask for help to get there because it wasn't in the realm of possible for me otherwise.
This was to solve very easy problems like generating a bunch of random discount codes with a custom charset. The Python solution was really fast, super straight forward and less lines of code. I run into a lot of things like this with Elixir.
I want to use Elixir so bad for anything web based, but I find it really hard to write it, both at understanding it and having to typically deal with writing a lot more code vs Python / Ruby.
The secret for working with strings in functional languages (or in languages with immutable strings) is to realize most operations, such as concatenation, end up copying the strings. So instead of saying “string1 concat string2 concat ...”, it is better to collect a list of strings and build one final string only at the end. Here is an Elixir specific article that goes more in-depth into this: https://www.bignerdranch.com/blog/elixir-and-io-lists-part-1...
Other languages may provide specific data-structures for this purpose, such as ropes, but in a nutshell that’s all there is to it.
I never had to think of anything like this in Python. The intuitive / easiest to read code usually ended up being efficient enough that I didn't need to even think about improving the performance.
See http://erlang.org/doc/tutorial/nif.html:
> As a NIF library is dynamically linked into the emulator process, this is the fastest way of calling C-code from Erlang (alongside port drivers). Calling NIFs requires no context switches. But it is also the least safe, because a crash in a NIF brings the emulator down
It’s only a problem if the NIFs crash (rate in my experience), or they take too long and cause the VM to hang (easier to do for big computations). Now with the newish ability to mark a nif as dirty which helps the scheduler know a nif can have longer runtimes that could block the VM.
P.S. Elixir/BEAM often also achieve resilience via connecting multiple nodes as well.
By using macros it’s relatively trivial to create sections of code that can compile to a computation graph and have a compiler create native code/nif for it.