I agree that Racket development is less interactive than CL development partly because of the slower compile times and partly because of the way the editors choose to reload modules on change. Nothing inherent prevents fast reloading[1], though, and Racket development is still plenty interactive[2].

I would say the package story is more complicated in CL as a consumer of packages. As a package creator, they're similarly complex.

[1]: https://www.youtube.com/watch?v=wWj7OPvXGgA [2]: https://www.youtube.com/watch?v=7uGJJmjcxzY&t=495s

Racket is definitely slower than Common Lisp. But it is one of the fastest Schemes on the market currently^1. But it also has the ability to create static executables, runs on M1 macs, has a statically typed sister language, a build in package manager, and gui library. And it's faster than other dynamically typed languages like Python when looking at pure implementations (not written in C). So there are still a lot of reasons to use it over Common Lisp if any of those things appeal to you

1.https://ecraven.github.io/r7rs-benchmarks/

> Last I checked it was pretty slow

I agree it is slower than the fastest CL implementations, depending on what you test, because some of the features present in the language make optimizations harder. The compiler is definitely also slow. As far as dynamic languages go, however, Racket is very fast in general and you can push it very far.

> use in production was not its main focus.

What makes you say this/what do you think it's missing as far as "use in production" goes? Instrumentation? Something else? I've deployed both production web apps and desktop apps with Racket, and the experience has been as good or better than other languages I've deployed similar things in.