The random tests are generating the input message as a charlist, not a string (binary).

Oh, of course, thanks :)

Elixir translation

Thanks. Please provide a link to your translation to facilitate the job of reviewers :)

Elixir translation added

thanks! approved;P

Cool one!

Answer to myself and maybe others:

The tests do not want to compare the instances, as they (hopefully) are always different.
Take care of this early and all will be fine :)

Maybe this was the same error I'm running into:

Test.assert_equals(Vector.new(1,2,3), Vector.new([1,2,3]))

yields

#<Vector:0x0000559eb6bc3b08 @x=1, @y=2, @z=3>, instead got: #<Vector:0x0000559eb6bc3f68 @x=1, @y=2, @z=3>

in my implementation, although the initialization itselfs seems to do, what it is supposed to.

fixed

Maybe a bit too picky :), but the description for Elixir states an array as result when expecting a tuple: {area, volume}

I solved this with Elixir, but experienced, that it depends on a random test, if you pass or not.
I tried several times now and the test case passes. when I do an attempt, a test with randomized data may or may not pass.

It all seems to boil down to accuracy (round nearly always fails for my solution, as floor passes most of the time, but not always)
My first solution never worked with any method and was always one second off with random values.

Thank you for your input.

You are completely right with the specs, though we maybe should handle k=0 in some way, as it yields an unwanted result in the implementation.

I corrected the specs along with the random range for n:

:math.pow(2, 31) |> round |> :rand.uniform |> Kernel.-(1)

I had some issues at first, when setting up the pipeline for the erlang calls.
This still feels a bit clunky to me, but seems to be the way to go here.

Thanks for your feedback, I myself am still not overly happy with this construct.
Normally, I got used to defining small "speaking" functions with guards and pattern matching in function heads :)

As I gave up on PHP in favor of Elixir for some years now, but was "raised" by my former co-workers for like 10 years with a "don't ever use ternaries (for they can make code even more obscure)" policy, I think, the best way (regarding readability) would be, to use a small additional function for this, if one wants to avoid ternary operators.

n = :rand.uniform(999999999)

Why not 2³¹-1?

non_neg_integer and pos_integer would be better typespecs for n, k and the result.

While this solution does work, it's best to try to avoid using else and elseif is you can. Reducing conditional statemens will help with readability not only for yourself, but also your colleagues.