that's not the test that failed, your prints are misleading. if the rust tests are to be blamed in some way it's that they aren't separating the tests, which makes it easier to mix them up, and more generally that they invite mistrust by not showing what they're doing, relying instead on the solver to figure out what happened which isn't ideal when the test code is hidden

(also you absolutely should not be using f64, that would fail for large numbers since you're effectively reducing the number of available bits)

is this working in Rust?

on the third test of sumbimiting it has a 36100(190x190) on b, and there is no 190 in a.
yet it seems to expect that test to be true

and when trying the aceepted aswers on that test in my machine they fail on that array as well

the problem is the piecemeal allocations, maybe the runtime will make it not terrible,
but im sure not relying on that for hot code.

however i agree with how clean it is, i need to reach that level of iterator wizardry.
and if you could pre allocate the String vec then is not a issue
but then in this specific case simple concatenation in a big string would end being simpler.