"Why did you choose Chez Scheme over other Schemes to rebuild Racket?
The biggest weakness of the Racket BC (“before Chez”) implementation are its back-end compiler structure, its inefficient internal calling conventions (over-adapted to C), and its poor implementation of first-class continuations. Those are exactly the strengths of Chez Scheme. Furthermore, Racket’s evaluation model was always closely aligned with Chez Scheme, such as the emphasis on interactive evaluation and compilation.
It was clear up front that Chez Scheme lacked significant features that Racket needs, such as support for continuation marks and reachability-based memory accounting. However, the high quality of the Chez Scheme design and implementation, in contrast to old Racket’s implementation, made adapting Chez Scheme more appealing than retrofitting Racket’s old implementation further."
I have fond memories of Racket, my intro to CS course used it. I already knew how to program, but I was really only familiar with C and it stumped me, in a good way.
Sadly I have never used Racket since. The kind of stuff I'd use it for is well-covered by python.
> Made me think why they don't just build Racket entirely in its self!
I'm not sure either, but I remember it might be because Chez Scheme has a parallel garbage collector that they could reuse, and being Lisps they could easily maintain backwards compatibility.
I think that "stumping" characteristic is really important in intro-level CS courses. My university actually had two choices for CS100: JS or Racket, and as a TA I saw the Racket class as significantly more successful at setting students up for success.
Most students come in with some programming experience. A handful come in with a lot, the rest have none. The latter two groups fared about equivalently when compared with their counterparts in the other language intro. But the big group of students who had just enough knowledge to be dangerous benefited greatly from the Racket course, and my hypothesis on the subject is that the alienation from what they were used to 1) stopped them from checking out because they thought they knew it all already and 2) forced them to really evaluate their knowledge and separate the language specifics from fundamental truths.
This was the best feature of Indiana University’s Scheme-based curriculum - it leveled the playing field and caused us to start to think about programming not as engineering, but as a type of mathematics over data.
There still is a bit of a runtime system that you'd write in something like C - you'll see it in the "c" directory of the linked chez repository. Chez is reportedly very fast, it's much easier to use that than write your own from scratch.
I don't know the Racket situation (although I am using their chez fork), but I know that the Idris language chose to move from having their own C based runtime system to chez for the Idris2 rewrite. The reasons that I've seen were that it was much more performant than they could achieve on their own.
I suspect something similar is at play here. That the racket team wanted to concentrate on what makes racket special and leverage Chez for performance.
From what I have read, Chez is a quite performant implementation (benchmarks https://ecraven.github.io/r7rs-benchmarks/) and does a lot of things correctly (according to spec) and cleanly. Basing Racket on Chez takes advantage of the things Chez does well and probably saves a lot of time. I have too little knowledge about Racket's internals, to give a better and less general answer.
