I've been using Racket for about 8 years now, and it is now my goto language for anything that needs a gui. It took writing 3 or 4 not-so-little guis to feel comfortable working with Racket's object system, but now it basically goes at the speed of thought.
Lately I've been using Racket to prototype the interaction design for a game, and I had written some placeholder text. I had put fake interpolation in for {player-name} and things like that, and then I realized that #lang at-exp would let me just ... do that, as described in the original article.
I had to laugh, because I maintain a bunch of Python code, and if Python has batteries included, Racket comes with a retrofittable fusion battery pack.
One other little anecdote, is that I've been porting an old plt-scheme codebase to Racket CS. In the second phase I have started replacing an ancient C++ rendering layer with the racket gui canvas functionality. During the process I moved hundreds of runtime type checks in the C/C++ layer to the Racket contract system. It was as if the Racket team had somehow secretly obtained access to the codebase I was working on and had designed the perfect abstractions to solve the problem.
I have one kid using scratch now, and one older graduated to godot, roblox/lua, some javascript/web.
I would love to get them into lisp (already done a bit of Janet along with me), but it really needs to be something they can write their game ideas in, and share/show-off to friends.
Racket has had significant engineering and design time spent directly on the use case you describe. See this old thread from John Carmack about his son learning with Racket https://news.ycombinator.com/item?id=10111479. Things have continued to improve since then as well.
From my own experience, it is absolutely possible to get good interaction with low latency in Racket, but of course
as with any language you have to have enough experience to know how to avoid performance pitfalls.
For some of the gui work I've done I needed to mix threads and semaphores to get things to be really responsive when there could be a long running process triggered by a UI interaction, but in Racket it has been vastly easier and safer than in other languages.
In the annual lisp game jam it seems a lot of the submissions and the most polished ones are using fennel, which is a lisp that compiles to lua from the same creator of Janet. Then for lua (and fennel) there is high quality game engines LÖVE (2d games), TIC-80 (retro 2d), LÖVR (3d).
With regard to Racket more generally, I'm probably not the best person to ask since I had a very high friction start where I just banged my head against the wall until things made sense.
Lately I've been using Racket to prototype the interaction design for a game, and I had written some placeholder text. I had put fake interpolation in for {player-name} and things like that, and then I realized that #lang at-exp would let me just ... do that, as described in the original article.
I had to laugh, because I maintain a bunch of Python code, and if Python has batteries included, Racket comes with a retrofittable fusion battery pack.
One other little anecdote, is that I've been porting an old plt-scheme codebase to Racket CS. In the second phase I have started replacing an ancient C++ rendering layer with the racket gui canvas functionality. During the process I moved hundreds of runtime type checks in the C/C++ layer to the Racket contract system. It was as if the Racket team had somehow secretly obtained access to the codebase I was working on and had designed the perfect abstractions to solve the problem.