1. Initial solution doesn't compile correctly because
   
   a. The function is not exported
   
   b. The return value is a non-existent variable
2. Tests feedback were very unhelpful:

     expected [ Array(9) ] to deeply equal [ Array(9) ]
   

LGTM
Can this be merged?

I think sort_unstable would be a bit better

Whatever is needed, should be done, I think. Tests should include:

• More ingredients available than required for the recipe
• Missing ingredient types needed for the recipe
• Ingredients present, but in insufficient quantities

It is possible to generate such tests deterministically, and it would behoove a translator to implement such. I do not have the time right now, otherwise I'd fork and write one myself, but I'm sure Pearce is up to it.

Edit: Here's a sample algorithm:

For each test:

• Clone the list of all ingredients, shuffle it
• Partition it at a random index.
• The first partition becomes the available ingredients. Add random amounts to each.
• For a positive test:
  • Sample between 1 and all available ingredients as the recipe.
  • Choose amounts less than or equal to the amount of the respective available ingredient
• For a negative test:
  • Do as in the positive test, but then do one of the following
    1. Add random ingredients from the second partition (that are not in the available ingredients)
    2. For random ingredients in the recipe, increase the amount beyond that in the recipe
• Choose a ratio (e.g. 3:1) for positive and negative tests. Either you can generate all test cases with known numbers (e.g. 75 positive, 25 negative) and shuffle them or you can gen_bool(0.75) to generate a positive case, otherwise a negative one. The first option lets you choose the exact number of each test, the second one relies on sufficent cases to produce the desired ratio.

true but then you'd need two separate cases as opposed to one

I'd do it the other way around: generate available, and sample a random subset of those to form a recipe which is guaranteed to add up at least once. You can then play with the numbers for each ingredient.

You can get closer to a 50/50 split without much complexity by either one (or both) of these two means:

1. Do not use the same range of lengths for both hashmaps. Skew recipe towards having a smaller length and available towards having a larger length. Most translations don't use the same process to generate both from what I've seen.
2. Generate available after generating recipe. This allows you to subsequently specify that, say 50% of the time, you merge all the keys (ingredients) of recipe into whatever you got from INGREDIENTS.choose_multiple before collecting to a dictionary. I don't know if this is convenient in Rust, but it was easy to do in C#.

So far the chance of not getting a 0 is 4-5%; I think you should at least incorporate the first approach since most translations do it and it helps even the odds a bit.

Done and done. Pass by value makes it easier for the consumer, but by reference is the better api decision, and at this kata level they can handle it.

Ingredient diversity and count have been reduced for random tests. It's still likely to be mostly 0s, but before there was a decent chance they'd all be 0s. A more nuanced approach would be possible, but require complexity beyond what I think is necessary.

• Missing assertion messages
• I'd suggest passing references instead of owned values to the solution function. They only need to be read-only, after all. At the very least this saves you a clone().
• Have you checked how many random tests produce recipes that can't be baked even once due to missing ingredients? Not that this makes a functional difference, but having a statistically large portion of the tests require the same result (0) would be kinda boring.

Rust's assert_eq displays what is left and what is right

It does not whow which is expected and which is actual tho, and from a default message users cannot easily figure out what they returned, and what kata wants? Or can they?

Unless by "right" the message means what is, well, right.

[...] and is used by itself for many Katas

There is many bad kata ;)

This one seems to be dead so I made one: https://www.codewars.com/kumite/65ff3b40e827ae02791d1c56?sel=65ff3b40e827ae02791d1c56

• Done
• Done, but is that strictly necessary? impl Into<String> is more flexible and a superset of &str.
• Rust's assert_eq displays what is left and what is right, and is used by itself for many Katas.
• Done

I don't know

Rejected because no answer to requests for more than one year. I think this is not approvable as is. It's always possible to create a new fork and make the required changes.

I feel like this is collecting two times, hence allocating on the heap twice?

Lol