# Racket meet-up: Saturday, 6 June 2026 at 18:00 UTC **URL:** \ **Category:** General\ **Tags:** event, meet-up\ **Created:** [June 3, 2026, 8:52pm UTC](https://racket.discourse.group/t/racket-meet-up-saturday-6-june-2026-at-18-00-utc/4275 "2026-06-03T20:52:33Z")\ **Posts on this page:** 1\ **Showing post:** 3
**Author:** ![babysitter](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/babysitter/32/2126_2.png) [@babysitter](https://racket.discourse.group/u/babysitter)\ **Post date:** [June 6, 2026, 9:35pm UTC](https://racket.discourse.group/t/racket-meet-up-saturday-6-june-2026-at-18-00-utc/4275/3 "2026-06-06T21:35:33Z")
Thanks everyone who joined the Racket meetup! We started by talking about Racket meetups in general, especially offline/local ones. There is already a Bay Area meetup coming up: [Bay Area Racket Meetup · Luma](https://luma.com/35gm6zha), and an experimental pub meetup in Scotland: [UK Racket meet-up · Luma](https://luma.com/vif8gkn9). Everyone is encouraged to try organizing an offline Racket meetup in their own area. We also mentioned the RacketCon 2026 call for participation: > [@RacketCon 2026: call for participation](https://racket.discourse.group/t/racketcon-2026-call-for-participation/4211): > > The (sixteenth RacketCon) really will be in Oakland, CA on October 3-4 (Sat-Sun). RacketCon is a public gathering dedicated to fostering a vibrant, innovative, and inclusive community around the Racket programming language. We aim to create an exciting and enjoyable conference open to anyone interested in Racket, filled with inspiring content, reaching and engaging both the Racket community and the wider programming world. We are looking for speakers If you would like to give a talk on some… Some projects we discussed: - Racket on WebAssembly: [https://racket-wasm.netlify.app/](https://racket-wasm.netlify.app/) - `uxnsh`, a project related to 100 Rabbits / uxn / Varvara, with a memory implementation in pure shell: [Dominik Joe Pantůček / uxnsh · GitLab](https://gitlab.com/racketeer/uxnsh) - Viridithas, a strong chess engine written in Rust by a UK developer based in Edinburgh: [GitHub - cosmobobak/viridithas: A superhuman chess engine. · GitHub](https://github.com/cosmobobak/viridithas) Naturally, we also talked about AI: how people are using it, what helps it produce decent results, and how important fast feedback loops are. Error messages came up as a particularly important part of this, with Rust as one example. This recent paper on verbose errors was mentioned: [https://arxiv.org/pdf/2606.01522](https://arxiv.org/pdf/2606.01522) The chess engine comparison led into a broader AI discussion: chess engines used to be weak, but with better algorithms and more hardware, even a phone can now beat the world champion. We discussed whether AI might follow a similar path, including the possibility that in five years useful models could be locally hosted on ordinary machines. We also talked about the current economics of AI: hardware scarcity, subsidies, token costs, and whether the promised returns on AI investment are realistic. This little site was mentioned: > **[Is AI Profitable Yet?](https://isaiprofitable.com/)** Related links from that discussion: - Former Google CEO Eric Schmidt getting booed while talking to graduates about AI: [https://youtu.be/tNH43a1EI7s](https://youtu.be/tNH43a1EI7s) - Collapse OS and concerns about hardware availability by 2030: [Collapse OS — Bootstrap post-collapse technology](https://collapseos.org/why.html) On the programming languages side, we mentioned that guaranteed Rust tail-call optimization has been merged into nightly: > > > This PR implements codegen of explicit tail calls via \`become\` in \`rustc\_codegen…\_ssa\` and support within the LLVM backend. Completes a task on (https://github.com/rust-lang/rust/issues/112788). This PR implements all the necessary bits to make explicit tail calls usable, other backends have received stubs for now and will ICE if you use \`become\` on them. I suspect there is some bikeshedding to be done on how we should go about implementing this for other backends, but it should be relatively straightforward for GCC after this is merged. > > During development I also put together a POC bytecode VM based on tail call dispatch to test these changes out and analyze the codegen to make sure it generates expected assembly. That is available \[here\](https://github.com/xacrimon/tcvm). We also briefly discussed the take that “every language is either a C or a Lisp”, with JavaScript described as more Lisp-like and Python as more C-like, mostly in terms of how expressions and statements work. Finally, Justin Slepak showed a demo of implementing reduction rules inspired by the WebAssembly abstract syntax paper: [https://dl.acm.org/doi/pdf/10.1145/3062341.3062363](https://dl.acm.org/doi/pdf/10.1145/3062341.3062363) He followed the small-step reduction rules from the paper and asked for ideas on improving the solution. Thanks again to everyone who came along and contributed! --- _[View the full topic](https://racket.discourse.group/t/racket-meet-up-saturday-6-june-2026-at-18-00-utc/4275)._