Crystal focuses on developer happiness while still providing strong safety guarantees. It goes to great lengths to make complex concepts easy to use, taking away a lot of complexity. For example, static typing and compilation to native code make it intrinsically type safe and blazingly fast. Yet built-in type inference makes most type annotations unnecessary, resulting in easy to read and clean code. It feels like a dynamic language. Crystal’s runtime allows the programmer to write I/O operations as if they were blocking, but they're actually non-blocking under the hood.
Terminal UI libraries often rely on heavy dependencies (e.g., curses) or platform-specific hacks. Lua’s minimal standard library makes this even harder—how can we provide a portable, lightweight solution? In this talk we’ll explore terminal.lua (built on top of luasystem): a minimal, cross-platform terminal UI library for Lua designed to provide essential terminal primitives without external dependencies like curses. The work presented here includes developments made during its participation in GSoC 2025, as well as improvements made afterwards.
Lua intentionally keeps its standard library small, so handling terminals requires defining the true minimum set of capabilities needed for Unix, macOS, and Windows — while keeping the API simple, consistent, and predictable. The talk begins by outlining the problem: how to handle terminals portably and transparently in a lightweight language by creating a level playing field. We’ll then walk through the minimal core implemented in luasystem and how terminal.lua builds a higher-level layer on top.
We’ll discuss:
Low-level:
Higher-level:
Projects:
BLUE is an acronym for Build Language User Extensible. It is a functional declarative build-system fully written in Guile.
As opposed to other build-systems, BLUE works as a library that can be used by projects to manage their builds. It is entirely self-contained and can be embedded into existing projects. It provides an optional clean and extensible CLI and extension points for external tools.
BLUE aims to reduce frictions from the build-system by providing a rich extensible API with clear error messages and documentation.
Ever wondered what is so special about Lisp's REPLs? Curious how to debug your Guile project or write tests? Lost in all the tools and libraries and not sure which to use or how? We've got you covered.
Today we will go through the fundamental tools needed for efficient Guile development. This will work for your personal Guix config, Guix itself, a new fancy Guile library, or Your Next Big Thing. We will go step by step from a simple project stub to a fully functional application covered with tests, and along the way we will learn about: - REPLs and highly interactive development environments - Ares/Arei Guile IDE - How to deal with exceptions and stack traces - Testing in the Scheme ecosystem and a new testing library, suitbl - Whether tests and TDD work with the REPL - Whether you need a debugger and how to use it
Links:
Those looking to get started with Scheme often find that they need to first learn Emacs. This is for good reason: pretty much all other editors have lacked the basic features to make Scheme a comfortable language to use. Over the past year, I've been developing my own VS Code extension to make programming Scheme without Emacs a reality. This talk explores what exists today, covering both my own extension, other tooling, and what's left for us to do as a community to make Scheme a first-class citizen in all editors.
Wastrel is a new ahead-of-time compiler from WebAssembly to native binaries. It has all the features, tail calls, garbage collection (via Whippet), and exception handling included. In this talk we show how Wastrel can run on vanilla C programs compiled using the WASI toolchain with best-in-class performance, as well as running Scheme programs compiled using Hoot. We discuss how Wastrel build on Hoot's WebAssembly support library and compare the speed of Scheme programs in the browser versus Wastrel versus native Guile.
Lisp is often decried for being hard to read and having too little syntax. This talk argues that the parentheses are not the point, but the uniform structure is! Lisp is like clay: a medium which is versatile for building many shapes and sculpting beautiful new technical visions. Christine Lemmer-Webber makes an argument that lisp's power comes from composable DSLs, and that this power is what gives projects like Guix and Spritely much of their strength.
Functional reactive programming (FRP) is a declarative programming paradigm that is most commonly used in interactive applications where imperative, event-driven, callback-laden code quickly becomes overwhelming and difficult to reason about. The reduction in cognitive overhead comes at a price, however. Popular reactive systems are limited to one-way data flow (a directed acyclic graph) which limits the types of problems these systems can solve elegantly. Fortunately, a way to remove this limitation has been known for over 15 years! Alexey Radul's 2009 PhD thesis "Propagation Networks: A Flexible and Expressive Substrate for Computation" tells us how. In this talk, I'll use Guile Scheme to demonstrate how an FRP system built on the propagator model allows for cyclic dependencies without user-visible glitches whilst keeping implementation complexity low.
This talk will describe work on creating and publishing Guix container images, and what you can do with them. Images are bootstrapped from Debian images and built on GitLab shared runners for amd64 and arm64, with ppc64el and riscv64 work in progress. The images are tested for regression, and automatically uploaded to the GitLab container registry and to Docker Hub. We will also talk about what these images can be used for, with examples of long-term reproducible tarball artifacts for official releases of GNU Libtasn1, InetUtils, Libidn2 and SASL. We will also go into limitations involving security trade-offs for reducing guix-daemon privileges, and the interaction between GitLab shared runners, user namespaces and other security complications.