It seems that the one of the motivations for starting this effort, besides performance, was to move away from a C code base. Is Chez Scheme primarily written in Scheme?
Actually, Gerbil used to be written on Racket. As you can see, it now benefits from Gambit's strengths without having to re-implement them...
What that other Scheme is based on is a secondary consideration. Chez Scheme is also said to be implemented very well, however.
Racket was a great tool to teach people lisp and initiate them into that paradigm.
Is the main syntax still good for long term use?
And even in the original announcment it was stated " * `#lang racket` is not going away and will always have its current parenthesis-oriented syntax. In the same way that Racket still supports `#lang scheme` and `#lang mzscheme` and even `(module <name> mzscheme ....)` and even top-level programs, the Racket compiler and runtime system will always support `#lang racket` programs. We believe that Racket's `#lang`-based ecosystem makes it uniquely positioned for trying new language variants while preserving and building on our past investments."
They have only made that statement stronger since then.
Renaming doesn't help the case much here, if Racket's future is abandonware.
[1] https://www.gnu.org/software/guile/
[2] https://www.gnu.org/software/guile/news/gnu-guile-300-releas...
For example ephemerons, that need some magic to cooperate with the garbage collector. https://cisco.github.io/ChezScheme/csug9.5/smgmt.html#./smgm...
In Common Lisp, one has pthreads-like concurrency capabilities which seem very well suited for fine-grained parallelism as well as for server tasks. I am thinking in such things like parallel backtracking and optimization algorithms for robotic control or board games, for example.
However, threads are notoriously difficult to handle cleanly and safely in larger programs. Here, Clojure (which in my eyes is a very Scheme-like Lisp) offers a very elegant solution with its concurrency primitives of Futures, Atoms, Agents, and STM. After some experimenting, I believe they are very, very attractive for many concurrent server tasks (like a web server), but not that well suited for computing-intensive parallel algorithms like the ones I mentioned above, which I am highly interested in. Part of the reasons are that such algorithms can become quite GC-heavy. Also, the Clojure compiler has limits on how much primitive types can be passed as parameters in one functions. This means that a complex backtracking algorithm in Clojure can still be two orders of magnitude slower than in C (which is somewhat disappointing, but one has to remember that Clojure was not designed for this).
Racket has had, so far, only limited concurrency capabilities. It had Futures, however they could easily become blocked by GC. It also has Places, which are a very safe and clean solution of splitting parallel computations into separate processes. However, I think that places are not the first choice for heavily parallel algorithms with strong interdependencies.
Now, Racket can run on top of Chez, and Chez has fine-grained concurrency capabilities on top of pthreads, which seem to be on par with Common Lisp. Also, Racket has strong support for functional and side-effect free programming, including some data structures. In my impression, this seems to open a wide range of new possibilities, including providing look-alike primitives for Clojure's Futures, Agents, and Atoms. I would be very interested to know more whether this impression is correct.
