Racket Blog

> I’m still not sure what you mean by “safe.”

Probably means "portable". If I'm reading it correctly, they want to be able to run Racket programs using a portability layer instead of writing a full interpreter. That would be something like using WINE vs. VirtualBox running Windows inside.

> Are you worried about Racket becoming unmaintained?

This is quite understandable concern, and even if it doesn't happen, having an "exit strategy" prepared is not a bad thing.

> Racket itself is written on top of Chez Scheme, so does that satisfy your safety condition?

Right, I forgot about it! After the rewrite/porting to CS Racket should have become easier to port to further platforms. I think much of Racket's reader and macro-expander was rewritten in pure Scheme.

@MichaelBurge - take a look at the blog[1] and follow links from there[2]. Racket was ported from a custom JIT-capable implementation to Chez Scheme. It took 4-5 years, but it was finished last year. The performance is now at the same level it was before, but a lot of C code is now written in Scheme.

[1] https://blog.racket-lang.org/2020/02/racket-on-chez-status.html

[2] migration done post: https://blog.racket-lang.org/2021/01/racket-status.html

Essentially all projects need help. My recommendation is to read the docs of the projects you use, and wait until you find a typo or a badly written sentence.

The advantage of a project you use is that you probably know the jargon, and can distinguish what is jargon and what is a typo.

Note that error messages and comment in code have also many typos, so it's another source of small fixes.

If you want a random project, you can try Racket. The docs are in https://github.com/racket/racket/tree/master/pkgs/racket-doc There is a friendly guide for contributions in https://blog.racket-lang.org/2017/09/tutorial-contributing-to-racket.html but I'd wish it were more simple.

I prefer to use "TortoiseGit" in Windows and "Git Cola" in Linux instead of using the git commands directly. It's much more simple and works 99% of the time.

Remember that posting an issue with a report of the error is also helpful. And if you explain that you want to send it as a pull request, people may help.

Racket is a great language. I got introduced to it through
reading "How to Design Programs" (https://www.htdp.org/), which
is a really beautiful introduction to programming that focuses on
big-picture program design, rather than just writing code, but in
a way that is accessible even to people who are new to
programmers.

I recently got a chance to use it for a medium-sized personal
project, and it is one of the most enjoyable programming
languages that I have ever used. Unfortunately, its performance,
and especially the start-up time, is not that great. (At least
this was true last time I checked.)

As someone who hasn't been following Racket news, I'm not sure if the new Chez
Scheme backend is expected to improve performance. I found this blog post
(https://blog.racket-lang.org/2018/01/racket-on-chez-status.html), which seems
to indicate that it is not, but that may be quite outdated. What is the goal of
porting Racket to CS?

Racket 7.4 now comes running on chez if you so wish. Check out [1]. In there there's also the links to the whys, hows and whats of the whole effort.

I've been using racket quite a lot lately, really like it. The thing I do not like about racket is the whole "racket 2" effort. Abandon S-exps? Really? To leave behind the 'popularity boundaries' of lisps? d'oh How about you drop your common USP that you share with the other lisps to become .. what, exactly.. irrelevant?

Cf. your 'dialect' point: In reality, the languages are just (supposed to be) DSLs for specific (sub-)problems of your problem-space. I don't mind, at all. You just require the libraries written in that other dialect from racket and use the stuff in there, et voila.

[1] https://blog.racket-lang.org/2019/08/racket-v7-4.html

To add to the other reasons - the CS compiler optimizes different forms and Racket is currently optimized for it's own compiler. To give a concrete example, taken directly from the racket blog [1]:

> For example, Racket BC makes dormant code relatively
cheap, so Racket libraries generate a lot of code. Future
Racket libraries will likely shift to take advantage of
Racket CS’s cheaper function calls and dramatically cheaper continuations. One day, probably, Racket BC will no longer be a viable alternative to Racket CS for most programs.

[1] https://blog.racket-lang.org/2020/02/racket-on-chez-status.html

Racket is being ported to Chez Scheme. That might solve the batteries included problem at least at the Racket level. However, if you don't like Racket, then I don't know if it will do anything since using Racket's libraries in Chez might be too kludgy to attempt.

https://blog.racket-lang.org/2019/01/racket-on-chez-status.html

Since you're a Chez fan, I'll also throw in its historical overview in case you missed it. That they had Scheme on 8-bitters really tripped me out. Talented team.

https://www.cs.indiana.edu/~dyb/pubs/hocs.pdf