What is your definition of slow or fast?
For example with Elixir it was possible to generate 5,000x random 19 character codes in 3ms on a 5 year old i5 3.2ghz desktop workstation. I don't know how long it would take with Ruby but for such a text / CPU intensive task, I'm quite happy with the performance.
Also parsing templates with EEx is ridiculously fast, because it's not treated as a string.
spec-builder git:(master) ruby -e "require 'benchmark'; puts Benchmark.measure { 5_000.times { rand(36**19).to_s(36) } }"
0.005459 0.000009 0.005468 ( 0.005464)
It would be interesting if you wanted to come up with a Ruby version that adheres to the random code spec which should be able to be determined from looking at the first 2 versions. It's basically only a subset of characters that can be used and the code should be output as XXXX-XXXX-XXXX-XXXX.
I personally use the 25ms version because I find it to be the best one if you factor in both speed and readability. I'm sure there's better ways but I'm only an Elixir beginner.
Also for the record I didn't write the 2nd or 3rd versions of that gist. I asked around in the community and that's what others have put together.
The issue becomes hard to fix because all of these small costs add up but none will show as up a single bottleneck in practice, making profiling a blunt tool for this kind of performance problem. Elixir isn't immune to this either but the functional aspects of design do help keep some of these choices local to the code that chooses to trade some time or memory away for other conveniences.
An example I saw recently of this sort of adoption is map access, which is entirely okay if the trade-off is understood. I put in some time to show that much of the understanding of performance profile of the Access behavior gets colored by these expectations that the small things don't matter: https://lobste.rs/s/bctcke/performance_elixir_s_access_behav...
https://www.bignerdranch.com/blog/elixir-and-io-lists-part-1...