My info is a bit out of date, but I'll try to go through big block of concerns...

> 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…)?

( https://pkgs.racket-lang.org/ is one way of sharing an open source package, through a public repository analogous to PyPI. There is a small delay upon uploading a new package/version, because the server builds the package, runs the package's tests, formats the package's documentation, etc.)

I don't know why it would take 18 hours, and I don't see a bug report linked.

Maybe the author was just doing a commit to their own random GitHub repo, without telling the Racket packages repository, and so waited for the packages repository to do a periodic scan of all third-party packages' random Git/Web sources for new versions? (I'd always go to the Racket package repo Web UI, and push a button of some kind there, and the new version would go through promptly.)

> Do I want to worry about packaging and deploying Racket code or could I simply do the same in most other languages without any fuss? I tried packaging Racket in Nix, it did not go well.

What didn't go well? Racket runs on a wide variety of systems. I once experimentally packaged it for plastic OpenWrt routers, and it was straightforward. https://www.neilvandyke.org/racket-openwrt/

> Do I want to invest trust in a programming platform that considers umask of optional importance? https://github.com/racket/racket/issues/4511

That was a helpful bug report, and looks like Matthew Flatt followed up on it promptly, and the bug report even got Matthias Felleisen's interest.

Then, given Racket's emphasis on cross-platform and backward-compatibility, Matthew's decision to add the semantics support without breaking production for all of the existing users. That seems reasonable and predictable to me.

> Do I want to force users to adopt an application written in a language that uses at the very least 122M resident memory on my workstation? Or do I consider Python or Guile which both use less than 10M?

I don't know how the author is running their code, so this might be the best Racket can do with the code, or maybe...

DrRacket (IDE) can run code with very heavy debugging instrumentation, and you can also do similar things from the command line.

DrRacket also has a feature that limits memory usage to a specified amount, IIRC defaulting to 128MB, which is great for alerting programmers on workstations with multi-gigabytes of RAM that they might be doing something inefficient.

Code can be run from source files (silently compiling/recompiling on demand and caching for later runs), from the compiled form, or into a more packaged form (which IIRC does some tree-shaking).

What libraries you pull in can also mean surprises (e.g., I see a later comment by author in which they mention a third-party package having inappropriate dependencies).

If you want to run in really tight memory, that will affect how you program, and will include an awareness of the garbage collector.

But also, small executable size probably isn't a top priority for Racket.

> Do I want to force users to package Racket which itself has no clear custody of its build inputs - can you produce a Racket tarball yourself that is exactly like the one on the release site? Who knows what’s in those tarballs!

I suspect the author is talking here about what's now called "reproducible builds".

> Do I want to invest in a community without a mechanism to apply community feedback constructively? RFCs?

The author got Matthew Flatt and even Matthias Felleisen giving prompt attention to the bug report they linked.

They'll find similar responsiveness on the mailing list.

> 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?

Depends what you need to do. The normal case, with programmers who are performing at normal levels and with normal practices is just to using PyPI (or NPM, or Cargo, or whatever), and bang out a solution to a normal problem.

But if you need to do something unusual, or you have programmers who are super-effective and can even judiciously bang out that reusable code as needed (better than the reused packages), then consider getting out of their way -- whether they just do it in Python or NodeJS, or they say this will go better in Racket, Rust, or something more exotic.

> Do I want to wonder about what was meant by “contributions welcome” when most of the core racket codebases at best have a README, at worst have no contributor documentation?

Documentation is one of Racket's strengths. From near the top of https://docs.racket-lang.org/ , see, for example, the document "Building, Distributing, and Contributing to Racket".

> Do I want to invest in a platform where leadership is building Rombus a.k.a. Racket2 instead of focusing on making core Racket just that much better and easier to adopt? (see also: Future of Racket.)

That's a good question. Racket is solid for production, has features that other languages still haven't discovered or done as well, and the author saw the prompt attention to their bug report. (The Rhombus thing has been going on much longer.)

> 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)?

Talk to the developer of that third-party package?

> Do I want to ship multi-gigabyte docker images because of the above kitchen sink package?

Talk to the developer of that third-party package, and there might be additional things you can do.

> 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'll need to understand first-class continuations to work on all the Racket internals as a compiler developer. But I don't recall ever seeing a non-internals use of that.

For the syntax extension mechanisms, you can learn that as-needed and at your own pace, because it's for things that most languages can't do (and does it better than languages that can). And you can definitely learn them incrementally, and start with the higher-level forms, which might just do what you need.

Units/signatures are ancient, and you probably don't need to use them. Just use the very nice module system (including submodules), and then decide whether you need more.

> Do I want to add business risk by writing a product in Racket? Does anybody work as an industry Racket coder at all? Would I struggle to hire more talent?

It's probably needless additional risk/unknown to use for business unless you have more or more people who are able to dig in and figure out technical stuff without Stack Overflow. (Though there are helpful forums, but you'll need to rise to the occasion more often.)

And one of the the secret weapons of beloved fringe languages/platforms is that they attract those mythical "10x" programmers on basis of technical/aesthetic/community merits rather than employability, so there's more of them than there are great jobs using Racket...

> Do I…. yeah there’s more but let’s move on ;)

(End of the contiguous block, switching to sparse quoting.)

> Where did the racket-money mailing list go?

https://www.neilvandyke.org/racket-money/

It's quiet most of the time, but picks up when a new person joins or there's a question/idea.

> Or really all the production users? I only found one production user.

There's more than that, including doing spectacular productivity and importance, but there's not many.

One thing the author of the blog post might be realizing is that the Racket professors are generally super-capable, they support production users like most professors couldn't, they'll provide technical support to any random person around the world. They'd love more commercial uptake, but that's been far from their top priority.