|
That's hard to say. Racket is a rather complete language, as is F# and Elixir. And F# and Racket are extremely capable multi-paradigm languages, supporting basically any paradigm. Elixir is a bit more restricted in terms of its paradigms, but that's a feature oftentimes, and it also makes up for it with its process framework and deep VM support from the BEAM. 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...