[bmitc]

My point, based on the assumption that indeed Arc runs on an old Racket version, is that it doesn't serve as a good example, in my mind, in terms of what you could build with Racket today.

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.

[gus_massa]

[Another try in case this is the type of answer you wanted.]

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.

[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]

Racket has a strong respect for back compatibility, so it should work in the current version. There has been a lot of improvements in the compiler (in particular changing the "back end" from C to Chez Scheme) but it's stil back compatible and sligthly faster.

[bmitc]

It is my recollection that the official Arc uses incompatible features. I can't remember where I read this, so it's entirely possible I am incorrect.

[gus_massa]

Arc mutates inmutable pairs (cons), it worked initially because at the C level mutable and immutable pairs were the same struct. Now there is a primitive unsafe-set-immutable-car! [1] for cases like this. It's a weird primitive and should be used with a lot of care as explained in the docs.

[1] https://docs.racket-lang.org/reference/unsafe.html#%28def._%...