This project is in slow, but active development and is not public yet. Some of the features outlined here are conceptual and everything shown is subject to change.
It often surprises people when I tell them that one of my favorite languages to work in is plain C1. I actually enjoy being in charge of memory (in certain aspects) and I don’t find myself questioning how the memory will actually be laid out in memory.
But I’m not gonna pretend that C is perfect. It’s absolutely a slog to work in sometimes and I don’t feel quick when I’m writing code in C. A language I do feel productive in is Go. I really like Go. But Go has some specific faults that make it a poor choice for game development in particular. Not only can I not use C libraries without overhead, but CGo is a pain to work with.
I’m constantly trying new programming languages, hoping to find one that will scratch the various itches I have. Especially when it comes to making games. I’ve tried Rust, Zig, Odin, V, Nim, and even D — yet none are what I truly want2.
Yep. It’s currently called Conjure and I’m developing with my good friend, Caleb Gray. We’re building it with the goal of making a language that is enjoyable and great for making games.
We’re not trying to make a language for everyone and everything; nor are we trying to make the perfect language.
I’m going to keep the feature list here as quick summaries for now.
Tooling-First Development: Call me a “programming wimp”, but I want a good language server and IDE support when I’m working on a complicated project. That’s why we’ve prioritized creating an incremental compiler that is also a language server from day one.
Fast Compilation: We’re constantly have to build and test code. I know we love our coffee breaks, but if we’re going to keep up in an increasinly fast-paced world, then code needs to compile quickly. This is even more important given that our compiler tooling lives within the language server.
Meta-programming and compile-time execution: A huge aspect of the language is how much we can do at compile-time4. We currently do this using compiler directives and the functions provided by the @build virtual module. This module provides direct access to the compiler itself.
Compile-time type reflection: The ability to analyze types using our compile-time executed code means we can generate optimized code for each type used, and even use the type information to generate code for serialization and deserialization.
Zero-overhead FFI: There’s a plethora of amazing C libraries out there that could prevent us from having to reinvent the wheel. We want to be able to use C libraries directly3 from Conjure without any overhead
Built-in Testing Framework: I want to be able to write tests and benchmarks without having to set up a whole testing framework. Go has a great testing infrastructure and is a model that we’ve borrowed several concepts from.
Keep the Syntax Simple: We want to keep the syntax simple and easy to read5. We’re borrowing a lot from Go in this regard and are aiming to keep the actual language grammar very straight forward.
First-Class Concurrency Features: The ability to pause and resume the execution of code is super powerful when creating games and doing work over time. Everything in the runtime is scheduled around a coroutine system and we’re creating mechanisms, like signals, to make it easy to communicate between routines.
Native Binary Embedding: Surprisingly few languages support embedding binary data directly into the executable. The ability to easily create standalone executables with everything self-contained is huge and makes distribution of games and tools much easier.
More Global Math Types: Beyond your standard int and float variants, we’re supporting the types you’d expect to see in something focused for game development. This includes various flavors of vector and matrix types (like vec2, vec3, vec4, mat4, etc.) along with syntactic sugar6, support in the math librar(ies), and SIMD support.
Hot Reloading: Borrowing from the world of web development, why not allow for hot reloading of code? Being able to test changes in near real-time is the ultimate productivity boost when trying to solve a problem or test a new feature7.
A robust standard library: that provides a lot of the functionality you’d expect from a language like this. This includes windowing, input, rendering, audio, and more.
I’m not gonna cover the basics of what you’d expect in the standard library like io, math and mem. Instead, let’s talk about the more unique things that would make game and tooling development significantly more enjoyable.
Windowing & Input: An opinionated and ready to go windowing and input system is obviously a must for any kind of game or tool with a GUI. This will most likely be built on top of something like SDL2 or GLFW, but will use an API that is more idiomatic to Conjure.
Rendering: Yet another critical piece of the puzzle. We’re still investigating what approach would be the most future-proof and we’ll most likely build on top of emerging technology or standards like WebGPU8. We also to implement our own shader language that mirrors Conjure’s syntax and can compile to GLSL, SPIR-V, or HLSL seemlessly during the build process.
Audio: A simple audio API that allows you to play sounds and music, ideally one that also supports 3D audio and spatialization.
GLTF: Given we’re working on a pipeline for importing and processing assets during compilation, supporting an open format like GLTF is a no-brainer. This will allow us to import 3D models, animations, and materials directly into your project.
Text Serialization Formats: Given the compile-time type reflection capability we’re building, we want it to be dead simple to serialize data to/from various formats like JSON and TOML. This would be huge for those making custom tools and editors for their projects, and could even be used for mod support.
Parser Tooling: We’ve already been designing Conjure to parse and compile Conjure, and part of that has been creating our own lexer and parser generators. By supporting this tooling as a library, it potentially becomes simple to create custom DSLs or implement other libraries (like JSON and TOML) in a way that is idiomatic to Conjure.
Pool-Oriented Memory Management: Rather than enforce any single memory management solution in the language itself, we left memory management pretty open with different implementations being made possible through our compile-time capabilities. One of which being our std/table module which provides a entity-component-system (ECS) style approach to representing objects in a game world using struct of arrays (SoA) and pool-oriented memory management. This is a common pattern in game engines and allows for better cache locality and performance.
GUI: It’s no secret that building graphical user interfaces at the native is not nearly as robust as doing it on the web. This is critically important to us, since both games and tools used to make games often rely heavily on the ability to present information and controls to the user. We’re even investigating some syntax sugar to make creating user interfaces via code easier.
TUI: Finally, the companion to supporting GUIs within a window, is supporting text-based user interfaces for CLI tools that might be used as part of automated build processes (and for Conjure’s own command line tools). We’ve actually been using the phenomenal Charm ecosystem of tools internally and plan to emulate some of that experience in Conjure’s own TUI library.
Sure! Here’s a small snippet of the current syntax. Keep in mind that this is still a work in progress and the syntax is likely to change.
use "std/io"// @build is a special virtual module that contains symbols// for interacting with the compiler directlyuse entry from "@build"// @entry is a compiler directive that marks functions as being// entry points for the program. You can target specific entry points// when building/running your code or even build multiple entry points// at the same time@entry func helloWorld() { io.println("Hello, world!")}
I just got done rewriting the lexer and am nearly done rewriting the parser using our own, internal parser generator9. We have a significant portion of the semantic analysis tooling done, and can compile a subset of our code using LLVM to generate machine code.
The language server is also in a pretty good place10, providing (limited) code completions, jump to definitions, documentation, and even some refactor and reformat capabilities. Once the parser rewrite is done, we’re addressing a few aspects of the semantic analysis code that will provide even more capability to the language server.
Right now we’re focused solely on building enough of the language and tooling to immediately rewrite using itself11. We’re not sure how much of the feature set we want to include in the first public release, but getting a self-hosted compiler feels like a great milestone to start with. We will likely start to invite a handful of people in as we get farther along.