Optimising Common Lisp to try and beat Java and Rust on phone encoding 2/2

There are a lot of interesting comments in the Lisp subreddit regarding the second part of the blog: <a href="https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;lisp&#x2F;comments&#x2F;q5f7u5&#x2F;revenge_of_lisp_part_22_optimising_common_lisp_to&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;lisp&#x2F;comments&#x2F;q5f7u5&#x2F;revenge_of_lis...</a>

In case anyone else is wondering what the author means by &quot;phone encoding&quot;: it&#x27;s an algorithm trying to map telephone numbers to words (via the letters usually printed on telephone keypads). Would have been better to call it &quot;phone <i>number</i> encoding&quot; IMHO...

The Rust code is bar far not optimized. For example while loading the dictionary, why creating a Vec and returning it instead of operating on a max word size array and reusing it. Also why not write everything at the end. I&#x27;m not a Rust Professional also, but maybe get a review by one please before benchmarking against something else.

Those are pretty impressive results for what didn&#x27;t amount to a huge amount of changes (mostly just adding some types).

And here come the Rust fan boys telling us the correct way to write the code so it will be faster than anything ever written, much safer than anything ever written and better than any programming language ever written.