You could ".rev()" the range, replace the "filter" with "find" and leave out the "last()".
More concise and less iterations since you start from the end of the range instead of evaluating the entire range and then returning the last element.

For Rust are you compiling+running the solution in Release mode and are the compile times also counted against timeouts?

I don't think there ever will be RE in rust::std considering there is a really good crate for that.

Considering str::replace does one copy and full iteration of the string buffer for EACH call. This may be OK for strings up to a few hundred chars and <10 replace calls, but for anything even approaching real-life scenario a loop is WAY better for performance than multiple str::replace calls.

Then I'd have to have a mutable "counter" variable AND I would have to increment that in the loop body.
This all makes the loop construct a not really desirable solution here.
In this scenario it's much easier and cleaner to have a for-loop with an infinite iterator.

Considering the integers in the input and output are positive it would be nice of you to use u32 or u64 in Rust instead of i64.

It should say "If a AND b are empty the result is evident by itself", meaning "true" because nothing is equal to nothing squared. The problem does not however make sense if one or both arguments are not lists/arrays (i.e. nil/None/null in languages where that can happen).

You need neither the "use std::fmt;" nor the "String::from" part because the format macro already returns a String.

The "return" is not needed here as a function returns its last expression anyway which in this case is the result of the "if-else" block because there're no semicolons after the return lines or at the end of the if-else block.

For the Rust solution the function should really return an Option so as to uphold Rust's error handling model. Should there be an empty list given as an argument with the current type signature of the "last" function, your only option is to panic, which is more like worst practices... Such an error should be propagated to the caller to deal with it but with the return type being just "T" this is not possible.