Is any software of note built on top of either software? All i can think of are these forums which, while enormously culturally influential, seem unremarkable from a technical perspective.
* https://defn.io/2023/08/10/ann-franz-source-available/
HN itself runs on Racket.
In the way those Dyson bladeless fans pull more air through. In your case, many folks know you (some from UIUC too like me) and know your upvote is worth reading, ending up upvoting too.
Isn't it an ancient version of Racket, though?
This is a quite common pattern in the Lisp and Scheme world where examples of real world usage are given, but they're effectively outdated.
[1] https://docs.racket-lang.org/reference/unsafe.html#%28def._%...
In Racket the batteries are included. Two examples of programs I had to write like two years ago for work:
* A bot to reply emails that uses IMAP, SMTP and web scrapping. (It's not 100% automatic. It replies only the easy cases and adds labels so I reply the tricky ones.)
* An program to cleanup Moodle backups that uses gzip and xml. I compiled it and send it to my coworkers. (The backups have too much info, so before restoring it in another site it's better to remove the unused parts.)
In both cases, and all the features were installed by default. There are many user defined libraries that can be downloaded as packages, but I didn't need to use them.
And it's tough to get support as there's very few people who know the stack well enough, and those people are the busiest and also professors, so their time is limited.
For support you can ask in https://racket.discourse.group/ , most questions are answered the same day. I don't know if someone is available for consulting/hiring.
I would say that the key difference is that F# and Elixir are backed by industry whereas Racket is primarily backed via academia. Thus, the incentives and goals are more aligned for F# and Elixir to be used in industrial settings.
Also, both F# and Elixir gain a lot from their host VMs in the CLR and BEAM. Overall, F# is the cleanest language of the three, as it is easy to write concise imperative, functional, or OOP code and has easy asynchronous facilities. Elixir supports macros, and although Racket's macro system is far more advanced, I don't think it really provides any measurable utility over Elixir's. I would also say that F# and Elixir's documentation is better than Racket's. Racket has a lot of documentation, but it can be a little terse at times. And Elixir definitely has the most active, vibrant, and complete ecosystem of all three languages, as well as job market.
The last thing is that F# and Elixir have extremely good notebook implementations in Polyglot Notebooks (https://marketplace.visualstudio.com/items?itemName=ms-dotne...) and Livebook (https://livebook.dev/), respectively. I would say both of these exceed the standard Python Jupyter notebook, and Racket doesn't have anything like Polyglot Notebooks or Livebook. (As an aside, it's possible for someone to implement a Racket kernel for Polyglot Notebooks, so maybe that's a good side project for me.)
So for me, over time, it has slowly whittled down to F# and Elixir being my two languages that I reach for to handle effectively any project. Racket just doesn't pull me away from these too languages as it doesn't really offer anything over them, and I would also say that Racket is a bit too locked to DrRacket. I tried doing some GUI stuff in Racket, and despite it having an already built framework, I have actually found it easier to write my own due to bugs found and the poor performance of Racket Draw. However, I do reach for Racket anytime I want a Scheme for learning purposes.
I agree that sometimes the docs of Racket are complete but too short. When I had to write code to download a webpage, I had to guess how to use the 10 arguments of the functions, in particular how to split https://www.example.com/here/thispage.html I think that the docs of PHP has a huge collection of user submitted examples, that sometimes are good and sometimes are bad, but most of the times there is one that saves you a lot of time.
Porting Racket to the the CLR and BEAM (and JVM) would be nice. I'm not sure the garbage collectors have all the necessary support for weird stuff like weak boxes and ephemerons. IIRC ephemerons were backported from the Racket fork to Chez Scheme a few years ago.
A Jupyter-like interface would be nice. My wife is using Python in Google Colab an she loves it. About the Racket kernel in Polyglot: Should it be written in some CLR language or it can be a thin wrapper around the main Racket executable?
Edit:
I searched in Discourse, and I found these two posts about using Racket in Jupyter.
https://racket.discourse.group/t/racket-meet-up-saturday-7-m...
https://racket.discourse.group/t/running-racket-in-the-cloud...
(I'm too busy to help just now, and I never made the VB6 -> VB.net transition.)
Racket is used extensively in education and research relating to Scheme and programming languages in general. Lots of work on gradual typing, programming language semantics comes out of the Racket community. Many colleges around the world use Racket. Scheme/Racket is very pared down language and lends itself to this kind of work -- the principles of whatever you are studying shine through quite easily in a way that it may not if you were using C, Rust, Python etc. in the problem domain.
As noted elsewhere in the comments, Idris 2, an important dependently typed language outputs to Chez/Racket Chez. Previously it output C code which was then compiled.
See: https://en.wikipedia.org/wiki/Racket_(programming_language)#...
In general, Chez is probably a great language to use as a "base". It lends itself to embedding and is performant. Lua and some Javascript implementations come to mind as comparables. In general, we might not know much about Chez being used a lot in the wild because it could be tucked deep into various proprietary company products.