> Do I want to iterate every 18 hours waiting for the pkgs.racket-lang.org build server to finish building my package? Then do it again because the build failed (my mistake, but now my users have to wait until later that week…)?

I agree it should be improved, but I think that deploying to the package system is something that happens not very often. The idea is to keep only a safe and stable version there.

> Do I want to write 4x the code (in Racket) because I forgot my secret move was actually all the pypi packages that I took for granted in Python?

It would be interesting if the author post in github a feature request for the 3 missing packages that are more painful. (3 is a good numbers to find someone else that care about one of them, more than 3 or 4 would be annoying)

> Do I want to wait 10+ minutes for my package to build in CI because some other package maintainer decided to pull in racket or racket-doc (which pulls in the entire big Racket distribution)?

Sometimes I use minimal-racket, and it's this is annoying. Most people just use the main distribution so this is not a problem. IIUC the author cares about a small footprint, so it's a special case. I use Ctr-C, but I guess there is a trick with raco pkg to do fix this automatically.

> Do I want to deal with being blocked due to not understanding how to use the less understood features of racket such as continuations, syntax-parse/syntax-case macros, units/signatures? You’ll want to know about all these things to write effective Racket code.

You can skip most of them to write effective Racket code.

I use continuations only as an emergency exit inside nested fors, no fancy stuff. (I agree the fancy stuff is weird.)

I think units/signatures is almost deprecated. It will be there forever to keep backward compatibility, but I expect new code to use modules instead of units.

About macros:

If you are programing alone just use syntax-rule. syntax-case is not so difficult unless you want to do weird stuff. I've done weird stuff in the past, but five years later I regretted it.

If you are programing in a team, it's important that the macros have good error checking, because otherwise in case of an error it will expand crap that will expend to more crap and after a few rounds of crap expansion the poor soul that is using it will get a unintelligible error about code they didn't wrote. Here is where syntax-parse is useful, to ensure the initial code makes sense and expand only good code and give a good error reporting otherwise. syntax-parse is almost a separate DSL, so it's a lot to learn. (You can write the same stuff with syntax-case, but syntax-parse automates a lot of stuff.)