This post is a dumb rant, but I needed to vent.

Some of the feedback I’ve received on Franz so far has been that folks need support for more compression and serialization formats. In that vein, here are some Racket libraries I’ve released in the past couple of weeks:

I’ve been using Apache Kafka for about a year now and I’ve wanted a desktop client from the beginning. I couldn’t find one I liked – the best I’ve found is Confluent’s Cloud UI, but that’s neither a desktop app, nor is it a great experience1 – so, a couple months ago I started building a native macOS GUI for Kafka in my spare time and, today, I’m proud to announce the first beta release of Franz.

I’m currently working on a macOS app that’s built with Racket and allows the user to write small scripts to process and filter some data. While Racket is definitely my preferred language and I could easily use it for these scripts, my target audience for this app would probably appreciate a more familiar language. I decided to use Lua. So, last weekend I was faced with a choice1 between writing FFI bindings for Lua or implementing a #lang in Racket.

I’ve been playing with embedding Racket CS in desktop apps off and on for a while and today I recorded a little screencast demoing some of the stuff I’ve been working on. Here it is on YouTube:

Earlier this week, Jesse Alama brought up the topic of scheduling cron jobs with koyo and we both agreed that it would be nice if koyo had built-in support for that sort of thing. So, I wrote crontab, a little library for parsing cron-style schedules and executing code based on them. On top of that functionality, I’ve added a new koyo/crontab module to koyo that integrates with the component system.

For the past month or so, I’ve been working on implementing a pure-Racket client for Apache Kafka. Yesterday, it reached a point where it can do the bare minimum you would expect from it: produce data and join consumer groups to consume data. Kafka has a fairly large feature-set so there’s a ton left to do, but I figure this is a good time to announce the library and get feedback.

Racket provides support for concurrency via lightweight threads, which the web server leverages to handle requests, spawning one such thread per incoming request. At the runtime level, these threads run concurrently but not in parallel (i.e., only one thread is active at any one time). Parallelism is available in Racket via Places: distinct instances of the Racket runtime running in separate OS threads that communicate via message passing.

The web server doesn’t do anything with places, so, by default, all Racket web servers run in a single OS thread. That isn’t a big deal since you can run one web server process per core and place a reverse proxy like Nginx in front to load balance between the processes. But what if you don’t want to do that? Is there a way to use the web server in conjunction with places despite the web server lacking explicit support for them?

I recently ran across Matthew D. Miller’s “Survey of the State of GUI Programming in Lisp” series on implementing a small GUI application across various LISP implementations. The first article in that series uses racket/gui, so I figured I’d take a stab at porting that implementation to gui-easy. You can find my port here.

Yesterday, I gave a talk about gui-easy at the eleventh RacketCon! You can find a recording of the talk on YouTube and a transcript below. Day two of the conference is starting in a little under a couple of hours so join us if you like!