Racketfest 2021 Amateur Night logo


Racketfest is a time to learn & share what’s great about the Racket programming language and its philosophy of language-oriented programming. The next edition will be held on two evenings (or mornings, or afternoons, depending on where you are): Friday and Saturday, March 26 and 27, 2021, in Gather.

Time & Place

The 2021 Amateur Night edition of Racketfest will be spread over two days, in two 4-hour blocks:

Night One
Friday, March 26, 2021 from to Central European Time.
Night Two
Saturday, March 27, 2021, again from to Central European Time.

Racketfest is traditionally euro-centric, but this year, thanks to doing the event online, we are able to expand the offering. The should make it possible (or, at least, not wholly unreasonable) for those in the Americas, East Asia, and Australia/New Zealand to participate as well.


Racketfest 2021 Amateur Night will feature primarily short talks. If you want to give a talk, please let the organizers know by March 15, 2021. Just send a brief email to organizers@racketfest.com.

The idea behind an amateur night is to step up and show something you can do in Racket. If you do it in Racket, it counts! Don’t be shy! Just send a note to the organizers with a title and, if relevant, a time preference. Record a video, screencast, audio, or a Slideshow presentation. Be ready to come to the meeting and get some feedback from your fellow Racketeers.

If you just want to spontaneously show up and show something, that’s OK, too. Get feedback on that Racket project you’ve been working on, sound off on what you’d like to do with Racket, ask for help (and get live feedback from top Racket talent!). The sky is the limit.

We will have a standing art gallery for those who have made some art in Racket. To submit your piece, send email to organizers@racketfest.com



All times are Central European Time (CET).

Refresh this page! As plans develop, this list will be fleshed out.

Night One: Friday, March 26, 2021

Doors open
  • Jens Axel Søgaard: New work with MetaPict
  • Mike Sperber: Teaching Language Infrastructure—Work to Do!

    The HtDP and DeinProgramm languages are wonderful tools for teaching—they support the pedagogy of systematic design, give excellent feedback, and DrRacket is an uncluttered environment appropriate for beginners.

    Yet, the user experience has fallen somewhat behind: The test-results window is clunky, Check Syntax isn’t concurrent with editing, links to documentation don’t quite work. This is all despite the fact that DrRacket in principle can do these things well.

    Remedying these problems means digging deep into historically grown code that is hard to change: I’ll talk about what the issues with the code are, what I’ve done recently both to improve the general infrastructure and to make the teaching languages use it, and what might be in store.

  • Joel Dueck: Beeswax: An Early-Stage Templating Language

    Many Racket templating facilities involve using read/eval on text files loaded at runtime. Beeswax is a Pollen-friendly DSL that turns document templates into normal Racket modules and functions. I’ll talk about why this might be great, how I made it, and things I still haven’t figured out.

  • Ryan Culpepper: The database library, the FFI, and Racket CS

    One problem the Racket database (db) library has faced is that an FFI call blocks all Racket threads from running, so a long-running query on a sqlite3 or ODBC connection can make an entire Racket application or server unresponsive. The old fix was to run queries in a separate place, but this has high overhead. Racket CS supports an alternative: running (restricted) Racket code in OS threads with shared memory. I’ve recently added support for this alternative to the db library; it requires some changes to the code, but it seems to have much lower overhead.

  • Oliver Caldwell: Conjuring up a Racket in Neovim with a hint of Fennel

    Come with me on a journey into unfamiliar territory for Lispers, we’re going to interact with a Racket REPL from Neovim! Then we’ll take a peek behind the curtain at the other Lisp that drives the whole experience (no Vim Script here!) and the other Lisps we can talk to. I hope you enjoy this Lisp polyglot buffet!

  • Daniel Brunner: A Racket-powered shop, with training

    My brother an I run a small software company in Germany. The main focus of our work is on business software like Enterprise Resource Planning. But, we both love parentheses as well. In this short talk I will show some of the applications we developed for our customers using Racket (and other Lisps). In addition to using it for commercial software, I also use Racket for teaching programming to our apprentices. Therefore I’ll close my talk with with some comments on why this makes sense from my point of view.

  • Alex Harsányi: ActivityLog2: A Racket-powered fitness app
  • Gregor Kiczales: Automated checks for design recipes
  • Adam Geller and Justin Frank: Modeling the WebAssembly language using Redex

    Redex is a domain-specific language for writing mechanized language models embedded in Racket. Having a Redex model lets us quickly run our research. In addition, a Redex model is generally very similar to how formal language models are expressed on paper.

    In this talk, I will show how we used Redex to model WebAssembly, a low-level language meant to run alongside JavaScript in the browser for performance critical applications, and how the Redex model is useful in our research.

Night Two: Saturday, March 27, 2021

Doors open
  • Aki Iskandar: Creating APIs in Racket for web & mobile applications
  • Suzanne Soy: Why do we need macros? First-class environments as an alternative.

    Macros are used to abstract over patterns in the code, from the elimination of repetitive boilerplate to the automatic generation of complex code.

    This is exactly the job of functions: packaging a frequently-used idiom into a reusable library function. We use macros to write abstractions that cannot be written as functions:

    1. adding/reading bindings to/from the environment (let, define-struct, anaphoric, match, …)
    2. changing the order of execution (if, match, for/list, …)
    3. syntactic sugar (infix operators, anything written using syntax-parse’s ~datum or ~literal, identifier prefix/postfix annotations, …)
    4. optimisations, i.e. semantics-preserving compile-time transformations of the program
    5. tracking and propagating annotations on the code (types, source locations, tooltips, …)

    These concepts can only be manipulated by macros because they are second-class citizens that cannot be assigned to variables, passed around by functions, and manipulated at run-time. The following features would allow these concepts to be within the reach of functions:

    1. first-class environments (an extra env parameter threaded through all functions)
    2. lazy by default, continuations, effects
    3. #%app, extensible parser, polysemic bindings (in both as a (let x = v in body) keyword and a (for x in list do body) keyword), first-class sub-expressions
    4. markers around values that should be computed at compile-time, and a perfectly hygienic rewriting metalanguage that is closer to Coq’s tactics than to macros.
    5. same: markers to track what should be done at compile-time

    This talk will give an overview of how making some concepts first-class allows most macros to be rewritten as functions.

  • Sorawee Porncharoenwase: What’s new in Rosette 4.0

    We are working on Rosette 4.0! This version has a new technical core, which is faster and supports new features, including a more powerful synthesis library. In this talk, I will give a quick tour of the upcoming version.

  • Matthijs de Jonge: Live coding with rs—MIDI sequencing in Racket

    rs is a live coding tool that lets you sequence MIDI instruments using Racket. This talk will show you can use it, how it works and what some of the benefits are of using the programming language we all know and love for making music.

  • William Bowman: Sweet BNF grammars with scribble-bettergrammar

    I’ve been teaching compilers with a nanopass architecture, and typesetting a lot of eBNF grammars in the process. As a language-oriented programmer, I naturally wrote a language for typesetting them. The language can hyperlink Racket identifiers that appear in grammars, compute and render differences between grammars, render n-way diffs with tabbed interface, and convert the typesetable grammar to a Redex language.

  • Eric Clack: Why learn Racket? Why teach Racket?

    At code clubs for young people (6-16 year olds) people typically start with a block-based programming language such as Scratch. When they are ready they move on to a text-based programming language, usually Python.

    But what about Racket? It’s got a great environment, it’s good with graphics, pretty concise (so not too much typing) but I’ve not seen it at any code club.

    So can I make a case for learning Racket, and teaching Racket? Will I convince some young people to try it?

    A bit of background: I mentor at Brighton Coder Dojo and we’ve written a number of tutorials for young people new to Python. I’ve also created various Racket games examples over the years, with an idea that they may work at our code club. But I’ve never used them. Maybe because I’ve never tried to answer the question: why learn Racket?

  • Laurent Orseau: url2script

    url2script is a DrRacket quickscript that makes it faster to install other quickscripts published on Gist and elsewhere, just from their url. Once url2script is installed, no package installation and no copy-paste of code are needed. Scripts can be easily updated as well, if the owner changes the published script.

  • Vincent Lee, Al Winfy, and Benedek Szilvasy: R16: A trick bot for Discord
  • Eric Eide: Discover Deep Programming Language Bugs with Xsmith

    Xsmith is a Racket library for creating fuzz testers that exercise programming language compilers and interpreters. In other words, Xsmith is a library for creating random program generators. Xsmith aims to help testers generate well-formed, well-behaving programs and thereby search for deep bugs in a programming language implementation: i.e., errors that cause correct programs to produce incorrect results. This talk briefly describes Xsmith and a few of the bugs discovered with the help of Xsmith to date.

  • Lîm (Danny) Tsú-thuàn: Macro as type

    We build our own environment for a type system, but reusing macro environment is possible. In this talk, I present how to convert programs to do so, and show possibilities, limitations, and future works.


The following people are generously supporting Racketfest:


Videos from the event are here.

Professionalism Policy

Racketfest borrows from the spirit of Racket, whose community aims to improve the world through programming. Racket started with the goal of introducing everyone to the wonderful world of program design, with a spirit of full inclusion and no emphasis on any specific group. Over time it has grown into a full-fledged professional community with a well-known reputation for helpfulness and openness on its on-line communication channels. We want that openness and friendliness to extend to Racketfest.

For this to happen, Racketfest needs to be a space that where everyone can participate without fear of personal harassment. Harassment is understood here as unwelcome or hostile behavior, which, in turn, we understand as behavior that focuses on people instead of ideas. The ACM’s anti-harassment policy lists some unacceptable behaviors. Responses such as just joking, only teasing, or being playful, are unacceptable.

In short, be professional and kind. We’re all here to learn and share.

Anyone witnessing or subject to unacceptable behavior should notify the Racketfest organizer (Jesse Alama).

If a Racketfest participant engages in harassing behavior, the Racketfest organizer may take any action they deem appropriate, ranging from a verbal warning to expulsion (without refund) from the conference.

(The wording of this policy is derived, with permission & thanks, from that of RacketCon, which in turn was derived from the SNAPL conference.)