In the case of the problems I've done that were like that what mattered was finding an asymptotically efficient algorithm. For example there might be a fairly obvious exponential time algorithm but it won't meet the execution time constraints, so you need to find a much less obvious linear or quadratic time algorithm. For problems like that constant factors (like Rust being 2-5x faster than Python) typically wouldn't matter.
For that type of problem: ie. it's more finding the algorithm than the code itself that matters, the solution will probably be less than 1000 lines of code and there's only one person working on it, I think it's hard to beat Python. Worrying about static typing let alone memory management will probably only slow you down and maybe even interfere with the thought processes needed to find the right algorithm.
I say that despite actually not liking Python very much and this advice is the exact opposite of what I would give someone looking for a language to use on a large code base that needs to be maintained over time by multiple developers.
for what you describe i would actually pick common lisp (sbcl). you can get c-like speed. plus there is a good new book on algorithms and ds using common lisp
For that type of problem: ie. it's more finding the algorithm than the code itself that matters, the solution will probably be less than 1000 lines of code and there's only one person working on it, I think it's hard to beat Python. Worrying about static typing let alone memory management will probably only slow you down and maybe even interfere with the thought processes needed to find the right algorithm.
I say that despite actually not liking Python very much and this advice is the exact opposite of what I would give someone looking for a language to use on a large code base that needs to be maintained over time by multiple developers.