What about the battle-tested Linux kernel? If you compile your racket apps to a native binary, you can run it directly on the Linux kernel, and benefit from 25 years of use in production! People deploy Golang and Rustlang apps everyday in prod using that approach it seems to work well for them. Note, both languages are younger than Racket.
Compiled Racket programs are nowhere near the speed of Rust or Go. Racket's GC is objectively much much worse than the JVM.
Of course you can serve millions of users with Racket, like HN. But the JVM today is much better choice. The JVM's GC is world-class and the number of man-hours put in it is probably many orders of magnitudes more than that of Racket's.
If you need performance and want to avoid the jvm, there are also lisps like Chez Scheme and various Common Lisp implementations (sbcl, in particular, can produce really well-tuned numerical code).
As a broad approximation from the results of The Computer Language Benchmarks Game, Racket is 5 times faster than Python and 5 times slower than C. https://benchmarksgame-team.pages.debian.net/benchmarksgame/... (I can't find a direct comparison of Python-vs-Racket in the site.)
The difference with Python is probably bigger in programs with a big numeric part, and much smaller in programs with a lot of string. Take that number just as a general guide, not as a precise scaling factor.
Racket vs Python is a "common" comparison. I write the same comment once or twice per year :). (Probably because both are high level and have the batteries included. (The syntax is slightly different :) ))
What about the battle-tested Linux kernel? If you compile your racket apps to a native binary, you can run it directly on the Linux kernel, and benefit from 25 years of use in production! People deploy Golang and Rustlang apps everyday in prod using that approach it seems to work well for them. Note, both languages are younger than Racket.