Over the last 6 months, I have been learning Racket in my free time. One of my first posts on this blog laid out my reasons for choosing Racket. The relatively low barrier to entry (e.g., easy installation of Racket and packages, DrRacket IDE, good docs, etc.) allowed me to build momentum with Racket and I was feeling satisfied with my choice of Racket as an alternative to Python.

My enthusiasm for Racket led me to spend most of a recent weekend watching a livestream of RacketCon. In the 'State of Racket' talk, Matthew Flatt proposed that it is time to start moving forward with the development of Racket2 [1] and made a few suggestions, including changing the surface syntax to use infix notation. The proposed change to the surface syntax kicked up quite a duststorm on the Racket mailing list (e.g., here, here, and here) and trickled over to Twitter.

I had a surprisingly strong reaction to the proposed changes to Racket and eventually realized that I have come to love Scheme syntax. I find that it fits my brain and I expect it to make me a more productive programmer. A potential move away from Scheme syntax in Racket2 would not preclude me from continuining to use #lang Racket as part of the Racket ecosystem; a point made frequently by the Racket core developers. I don't doubt their earnestness, but, even the possibility that Racket might become a 2nd-class citizen in its own ecosystem one day considerably dampens my enthusiasm for learning Racket. Moreover, this whole discussion has reinforced my lingering concern that the emphasis on programming language research might not make Racket the best choice for a general-purpose programming language [2].

While these research problems may not be forefront on the minds of all Racket users, keep in mind that Racket exists because of research and remains supported almost entirely by research. -Matthew Flatt

Thus, over the last couple of weeks, I've been reading about Scheme implementations to choose an alternative to Racket. The two resources that I found most useful were Awesome Scheme and a blog post on Scheme for scientific computing. I initially narrowed my choice down to Chicken Scheme and Chez Scheme.

Chicken is an obvious choice for me given that it is beginner friendly with a good community. The tagline describes Chicken as "a practical and portable Scheme," which is appealing as a general-purpose programming language. Chicken has a relatively large package ecosystem and an easy-to-use package installer. The main drawback right now is that a seemingly large number of packages (called eggs) have not yet been ported to Chicken 5, which was released less than a year ago and included breaking changes to package management.

Chez Scheme has only been available as an open-source language since 2016. The package ecosystem lags behind other prominent Scheme implementations. However, Chez has a reputation as being solidly engineered and blazingly fast. Chez has a great REPL that is a joy to use. Moreover, it is based on the Revised⁶ Report on Scheme (R6RS) and philosophically aligned with Racket [3].

As of today, I'm moving forward with learning Chez Scheme. If Racket moves toward non-Scheme syntax, there could be considerable opportunities for Chez to grow its community. My gut feeling is that jumping on the Chez bandwagon now could pay off nicely in a few years. I'm in no hurry to put Chez to work for me, though. I have time to learn and grow with the community.

[1] Racket2 is a placeholder name for a language that would evolve from Racket and include breaking changes.

[2] Alternatively, I'm looking for other ways to rationalize my move away from Racket.

[3] Chicken is based on R5RS.