The Low-level card

Build something close to the machine. The card’s shorthand is “C or Assembly”, and the spirit is broader than that: anything where you are dealing with the hardware or the internals directly, rather than through a framework that hides them.

The easiest thing that counts

A command-line tool in C. That is it. That meets the card.

If low-level programming sounds like something other people do, start here. A tool that does one small job, written in C, with no dependencies: a file renamer, a hex dumper, a wc that does what you actually want, a small text editor, a parser for a format you care about. You will spend your time on memory, buffers and off-by-one errors, which is exactly the point.

You do not have to write an operating system to meet this card. Most entries should not be.

Going further up

In rough order of how much evening they cost:

• A tool or a library. As above, or a library with a real API that another program could link against.
• An interpreter. A calculator that parses properly, then a small language. Lexer, parser, evaluator, and suddenly you understand how every language you use works.
• A game. SDL or raylib and C. Doable in a weekend and very demonstrable.
• An emulator. CHIP-8 first, always: a weekend, and it runs real programs written decades ago. Then a Game Boy or a 6502 if you are enjoying it.
• A kernel. Genuinely less difficult than it sounds. Booting to the point of printing text on screen is an afternoon; from there you add a keyboard driver, memory management and a scheduler at whatever pace you like. The OSDev wiki’s bare bones tutorial is the standard starting point and it is good.
• Assembly. If you are brave. A bootsector, a demoscene intro, or hand-written routines inside a C program. Pairs well with the Lightweight card.

Any language, if it touches the internals

The card names C and Assembly because that is what most people reach for, but the test is what the project does, not what it is written in.

• Rust counts whenever it is doing low-level work: a kernel, an emulator, embedded, a driver, anything in an unsafe block for a reason. Rust has an excellent embedded and OS-development ecosystem.
• Zig, C++, Odin, Nim, D, Ada: same test.
• C# counts if you are writing an operating system with something like Cosmos, which is exactly the sort of entry this card should be delighted to get.
• Go, Swift or anything else doing systems work: same.
• Embedded on a microcontroller counts wherever you are talking to registers and pins, whatever the toolchain. This overlaps with the Hardware card, so pick whichever multiplier suits you.

What does not count is a normal application that happens to be written in a systems language. A web server in Rust using a full framework is a fine project, but it is not this card. The question a reviewer asks is: is the machine visible in this project?

Where people get stuck

• Set the toolchain up first. Cross-compiler, emulator, debugger, whatever your target needs. Do it before you plan the project, because for the more ambitious targets it is a real fraction of the work.
• Use an emulator, not your own machine. QEMU or Bochs for OS work. Reboots are slow and losing your own filesystem is slower.
• Print something as early as possible. Getting any output at all is most of the difficulty on bare metal. Once you can print, you can debug.
• Expect to read specifications. That is the skill this card teaches, and it is worth more than the project.

Shipping one

• Demo: a binary somebody can run, or for a kernel or an emulator, a video plus clear build instructions. Remember that a repository of source is not a demo on its own.
• README: what it does, what it targets, how to build it. Be specific about the toolchain, because nobody will get it running otherwise.
• Screenshot: a still of it running. A terminal or an emulator window is fine.
• Description: say what is low-level about it. If you wrote it in something other than C, this is where you explain what it touches, and it makes review quick.