[nickjj]

> Only (small) gripe is that Elixir is not a fast language.

Which is interesting because Elixir isn't well known for being super fast when it comes to CPU bound tasks, but for a lot of semi-CPU intensive things you'd end up doing in a web app, it's still very very efficient.

For example I wanted to generate 5,000x 19 random character discount codes and my first attempt took 730ms to generate the codes while being a complete newbie to the language and cobbling together Enum.reduce / Enum.random while concatenating strings. Within an hour of asking if someone had a better way of doing it, I got multiple solutions from community members that were able to produce the same results in 25ms while still having very readable code (arguably more readable than my original implementation), and even one person came up with a solution to do it in 3ms.

It's almost hard to imagine being in a position in a web app where 3ms would be considered too slow to generate 5,000 unique discount codes with a custom character set.

[sprite]

Would love to see the 3ms solution. Post a gist if you have it available.

[nickjj]

Sure. Here's a gist with 3 versions (original, the 25ms version and the 3ms version): https://gist.github.com/nickjj/99ea84f460f41dae4139d0610ce80...

The reason I didn't use the 3ms version was due to it having too many concepts that are unknown to me. At the end of the day I would still need to maintain the code and the 25ms version is a lot easier to change (for me at least).

But, if I had very strict time requirements, I could just drop in the 3ms version at any time to get the speed boost which I think is reasonable. I only need to bring in the operational complexity when the demand calls for it. Otherwise the more human readable version is fast enough for my use case.

[dnautics]

I suspect the 3ms version is still hamstrung by the system rng :) I might try to make it even faster if you don't mind!!

[nickjj]

Sure, go nuts. Feel free to ping me on Twitter at @nickjanetakis and / or reply here if you can improve it.

[sprite]

Thanks.

[SMFloris]

Totally agree with what you said, but there is a caveat no one tells you about when you start Elixir. Coming from CUDA the extra speed you might get with concurrency in Elixir seemed very enticing for me so naturally I began experimenting. In Erlang/Elixir processes are really lightweight, but they do still bring some overhead and, in most cases I experimented with brought no speed advantage whatsoever and were in fact slower.

For example, lets say you want to compute the first million fibonacci numbers using the series' nth number formula. The function below calculates the nth fib number in the sequence; Then, to keeps things simple, we look around in the Elixir documentation and find Task which accepts a closure, is async and spawns a new process. Great you think, with the extra speed from parallelising in blocks of lets say 1k fib numbers we'll surely be faster.

def nthFib(n) do round(:math.pow(@phi, n) / @sqrt5) end

1..1000000 |> Task.async_stream(MyModule.nthFib) |> Enum.map(fn({:ok, result}) -> result end)

Nope. In fact, doing it naively with [0, 1, ... fib[i-1]+fib[i-2] ...] is faster. This was a bummer for me.

If you're interested and want to test something on hackerrank yourself, take a look here for a post I made while first experimenting with Elxir's processes on overoptimizing the first Euler problem. Noob thread here: https://elixirforum.com/t/hackerrank-optimizing-euler-proble...

Of course it might be just me, trying to apply the same principles I learned using CUDA. In my defence, those principles served me well over the years no matter if I was using CUDA or solving concurrency problems somewhere else. If anyone is interested in pitching in, I'm open to ideas, but for now I'm going to continue thinking that Elixir is fast enough for most use cases, just don't get your hopes up thinking its a silver bullet.