[bmitc]

For what it's worth, I am actually a fan of Racket, or at least was. It's what I reach for when I want a Scheme. But I lost enthusiasm for the language when the Rhombus project was announced. I now mainly use F# and Elixir for my side projects. Racket doesn't really provide anything over those two languages for most use cases.

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.

[gus_massa]

Which are the three things you would miss the most if you had to use Racket? It's interesting to know the pain points.

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.

[bmitc]

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.

[gus_massa]

Thanks for the reply! Sorry for the delay.

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

[bmitc]

It's been a bit since I looked at this last, but the notebook kernel would be written in a .NET language but can freely defer to whatever else underneath the hood. So F# could provide the glue to the notebook interface while deferring to some Racket server, such as a REPL server. I might investigate this myself.

[gus_massa]

If you ever decide to try, please post it in the Discourse group. People will be happy to heard about it and perhaps someone may help.

(I'm too busy to help just now, and I never made the VB6 -> VB.net transition.)