Learning Jam

March 15-17. March 22-24.
See the results.
March 15-17.
March 22-24. See the results.
Learn more

We are working to correct the course of the software industry.

We are a community of low-level programmers with high-level goals. Originally inspired by Casey Muratori's Handmade Hero, we dig deep into our systems and learn how to do things from scratch. We're not satisfied by the latest popular language or the framework of the month. Instead we care about how computers actually work.

Software quality is declining, and modern development practices are making it worse. We need to change course. Help us get the software industry back on track.

Latest News

I'm pleased to write this final news post of the year together with Abner Coimbre!

Dear Handmade Community,

Warm holiday greetings! Abner Coimbre and Ben Visness here, teaming up to announce that the Handmade Cities Matrix server will remain online permanently. In past years, it has been shut down at the end of conferences, but now it will remain active year-round!

This might surprise you, since most of you are probably already members of the (now rather large) Handmade Network Discord server. So why keep the Matrix server as well?

The Handmade movement has grown an incredible amount in the past several years. Importantly, it has grown both online and in the real world. Both domains are vital to the health of the larger Handmade community - but there are some critical differences between the two. Let's dive into it.

Two communities? Not quite.

The Handmade Network (HMN) is the online hub for the Handmade movement. Led by Ben and his team, they run programming jams, Twitch shows, and online social gatherings. They provide a place for community members to discuss programming, learn from each other, and share what they're working on. The Handmade Network is also the home of Handmade projects, including the Orca initiative and Abner's own Terminal Click.

In essence, HMN is the online community - and it's accessible to everyone, including those who prefer to remain anonymous.

Handmade Cities (HMC) brings the Handmade movement into the physical realm. Headed by Abner and his own staff, HMC orchestrates tech conferences like Handmade Boston and Handmade Seattle, which are venues to present to the rest of the world our software and ideals. HMC also organizes monthly in-person meetups worldwide.

In essence, Handmade Cities is all about in-person events. HMC emphasizes real-world interactions; by its very nature, those who participate in these events can't be anonymous!

For several years now, Handmade Cities has used a Matrix server for discussions related to conferences and conference meetups. This server has always complemented the Handmade Network Discord server, rather than competing with it. And that is not going to change!

The HMN Discord remains open to all, while users on the HMC Matrix are tied to real individuals participating in Handmade events: ticket holders, local meetup members, and so on. The Discord is the hub for jams and other online events; the Matrix is the hub for meetups and other in-person events.

What about Handmade Hero? How's that going?

At the start of the Handmade movement was Handmade Hero, a Twitch series showing how to craft a video game from scratch. Casey Muratori, president of Molly Rocket, started it in November 2014 and quickly found great success, forming a huge community around its values that has lasted almost a decade.

So, what's become of our bouncy little friend? Casey's passions have expanded beyond this project, reflecting Molly Rocket's commitment to multiple initiatives. We're not privy to the specifics of Casey's plans with Handmade Hero, but this year, we collaborated directly with him to shape the opening blurbs for both Handmade Network and Handmade Cities:


Originally inspired by Casey Muratori's Handmade Hero, we dig deep into our systems and learn how to do things from scratch. We're not satisfied by the latest popular language or the framework of the month. Instead we care about how computers actually work.


Inspired by Handmade Hero

Like Handmade Hero by Molly Rocket we believe in breaking software down to the bare bones and building back an understanding of how it all really works.

While Molly Rocket, Handmade Network, and Handmade Cities share a spirit of mutual support, it's crucial to emphasize that we exist as separate entities, and are not formally affiliated. You might instead see us as independent stewards of the Handmade movement.

And at the end of the day, that's the way we like it. We each have our own expertise, our own experiences, our own goals, and ultimately our own businesses. We feel that we're at our best, and the Handmade movement is at its best, when we are run independently but collaborate at every opportunity.

We look forward to bringing you improved conferences, jams, meetups, shows, and projects in 2024. With our 10-year anniversary fast approaching (!) the future of Handmade shines brighter than ever. 😊

All the best,

Abner and Ben

Around the Network

New forum thread: RemedyBG
Forum reply: RemedyBG
Forum reply: RemedyBG
Forum reply: RemedyBG
New blog post: nCine Dev Update 20
Angelo Theodorou

I forgot to mention here that in December I published the Dev Update #20, with updates from August 2022 to November 2023.

Some of the highlights:

  • Binary shaders and their hashing system
  • HiDPI support
  • Some fixes to the Thread class
  • The addition of a BunnyMark apptest
  • Improvements to particle systems and affectors
Simon Anciaux
Bits Please
New blog post: Why does C3 use 'fn'?
Christoffer Lernö

Alongside the removal of goto, having adding an fn in front of function declarations seems superfluous and an arbitrary deviation from C.

Originally, C3 inherited this from C2, which at the time used func (it later simplified it to fn).

In C2 the keyword simplified grammar and made the code easier to search. In C3 however, it also made macro and function declarations symmetric:

macro int foo(int a) { ... }
fn int bar(int b) { ... }

Furthermore, it gives a simple and readable look for defining function types and lambdas:

def Foo = fn int();
Foo lambda = fn int() { return 1; };
Foo lambda_short = fn () => 1;

Because fn starts a declaration, it's easy to search for it using regex as well, or have some simple tool extracting function names.

So those are all straight up usability reasons for fn.

But there is one more:

// Which one is C3 code?

fn void my_function(int a)
    return a * a;

void my_function(int a)
    return a * a;

Yes, it being trivially simple to identify a C3 snippet really is an advantage as well as a disadvantage.

If you are converting C to C3, you might copy-paste the C code and piecemeal convert it. So how do you see what's C3 and what's C? Well the fn of course.

It might seem almost flippant to list this as something positive, but reinforcing a shift in interpretation can be surprisingly helpful.

Forum reply: RemedyBG
New blog post: A new site and v0.5.5
Christoffer Lernö

Another month and another C3 0.5.x release (read the 0.5.4 announcement here), grab it here: https://github.com/c3lang/c3c/releases/tag/v0.5.5. As work on 0.6.0 is underway, 0.5.5 contains much fewer language updates, and instead mostly contains bug fixes.

In other news, the C3 site has gotten a face-lift: https://c3-lang.org. It's still a work in progress with more extensive guides planned.

For 0.5.5 the biggest feature is the new @link attribute. It works similar to #pragma comment(lib, ...) supported by MSVC and Clang.

module std::os::macos::cf @link(env::DARWIN, "CoreFoundation.framework");

// Use of any functions in this module section
// will implicitly link the CoreFoundation framework


While library dependencies still can be specified in project and library settings, this features allows fine grained dependency tracking, avoids superfluous linking. You link what you use, not more.

0.5.5 sees a lot of important fixes, such as the broken output directory setting for projects (and fixes the project template for the corresponding setting!)

The standard library has gotten new_aligned and alloc_aligned as new and alloc would not work correctly on over-aligned types, such as vectors wider than 16 bytes. In mem copy/clear/set functions now has a separate inline variant, which is important as inline requires a compile time length.

Previously aligned alloc using libc would have an extra overhead to support it, but now on POSIX and Windows native aligned allocations are used, avoiding this problem.

Here is the full change list:

Changes / improvements

  • Disallow multiple _ in a row in digits, e.g. 1__000.
  • Added @link attribute.
  • New 'linker' build option.
  • "linker" project setting updated, "system-linker" removed.


  • Struct/union members now correctly rejects members without storage size #1147.
  • math::pow will now correctly promote integer arguments.
  • Pointer difference would fail where alignment != size (structs etc) #1150
  • Fixed array calculation for npot2 vectors.
  • $$memcpy_inline and $$memset_inline fixed.
  • .$Type = ... and .$foo = ... now works #1156.
  • int.min incorrect behaviour #1154.
  • Bitstruct cast to other bitstruct by way of underlying type would fail #1159.
  • Bug in time.add_seconds #1162.
  • Remove initial './' in Win32 paths when running a binary.
  • 'output' directory for projects was incorrect in templates.
  • Regression: no stacktrace.
  • For MacOS, running with higher optimization would crash as initializers were removed.
  • compile-run and run now returns the proper return code.
  • Allow String constants -> ichar*, and allow integer pointers to explicitly convert between unsigned signed.
  • Bug in unaligned return value lowering for Aarch64.

Stdlib changes

  • Added new_aligned and alloc_aligned functions to prevent accidental under-alignment when allocating simd.
  • Fixes to realloc of aligned allocations
  • Use native Windows calls on aligned allocations on Windows.
  • mem::copy_inline, mem::clear_inline and mem::set_inline added.
  • mem::copy / clear / set no longer has an $inline attribute.
  • Native aligned libc malloc on Windows & POSIX.
  • Simplification of the allocator interface.
  • CoreFoundation only linked on MacOS when used.

0.5 has feature stability guarantees, so code written for 0.5.0-0.5.4 will work with 0.5.5.

If you want to read more about C3, check out the documentation: https://c3-lang.org or download it and try it out: https://github.com/c3lang/c3c

Community Showcase

This is a selection of recent work done by community members. Want to participate? Join us on Discord.