Wheel Reinvention Jam

September 27 - October 3
Learn more

Community Showcase

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

For the past few months, Asaf and I have been working hard on rewriting the Handmade Network website - and as of today, we're pleased to announce that it is live, and you're using it right now!

The new site has been written from the ground-up in Go, replacing the old Python / Django codebase. The whole site should immediately feel snappier and more pleasant to use, but we've tried hard to keep all the features you know and love from the old site.

It's not all the same though. Here's one big new addition that we hope you'll like...

A new forum post editor (with Markdown!)

The old BBCode-based editor has been completely replaced with a new Markdown-based editor. It features real-time previews and all the features you'd expect from a Markdown editor, including GFM extensions and some features from Discord (like ||spoiler tags|| - always a favorite!).

However, if you are for some reason a BBCode diehard, that is still supported. You can freely mix BBCode and Markdown, and everything should just work.

In the near future, we're planning to add image uploads, so you can directly paste images into your posts without hosting them elsewhere. This has been a long-requested feature, and with this new codebase we're finally in a good place to tackle it.

What's coming next

With the new site released, we're in the perfect place to start working on lots of new features. Here's a few of the things we have coming up:

  • Image uploads in forum posts
  • Lots of special functionality for the upcoming Wheel Reinvention Jam
  • An overhaul of the project experience (more details when it's closer to launch!)

You may also notice that a couple features from the old site are in fact missing - the library, and the wiki.

The library will be ported soon, but had to be temporarily cut in order to make some of our other deadlines. When the library comes back, it will be better than ever, with new features that let you save your favorite articles for easy access later.

The wiki, on the other hand, is gone for good - but all the wonderful wiki content written by our community will have a new home. We're still working out the details, but rest assured that it will be back soon.

That's it!

We really hope you like the new site. It feels great to get this project out into the world, and we're eager to hear what you think about it. If you have any feedback, feel free to leave it as comments on this post, or create new threads in the Site Feedback forum.


Macoy Madson

This post is also on my blog.

I have been working hard on a file organization application written in Cakelisp. This is part of my career goal to sell my software. The project's name is File Helper (I haven't spent any time trying to come up with a better name yet).

I believe I have a good approach to thinking about my projects. It is sometimes hard to define project success in terms other than "other people think it's really cool". There are a large number of reasons why a project is still a success, even if it ends up not being popular.

Accumulating code

I have been continuously improving Cakelisp and GameLib and intend to continue using these tools on future projects. This means all the bugs I find and fix, the features I add, and the body of references I accumulate all contribute to my potential for future success.

The more I can leverage and improve my existing tools, the easier it will be to create better applications. I started Cakelisp because I believed it would help me make better software faster, and I would be happier working with it. I still believe I have achieved these results.

Accumulating experience

Before File Helper, I hadn't had much experience writing shaders for 3D graphics. My career has always been focused on gameplay software engineering. File Helper's Tree Map gave me an opportunity to write some simple shaders and get my feet wet with OpenGL. I am already excited to use this knowledge on my next project, which will definitely need some shaders, because it also requires some custom graphical widgets.

Additionally, the more projects I get to version 1, the better I get at planning and executing my plans. I feel I have gotten better at knowing when to set artificial deadlines for myself, and how to more effectively filter the features which waste time vs. the ones that really matter.

Determining what's worth making

It is very difficult to know whether something is worthwhile until you have something to put in front of people. This is partly the idea behind the Lean startup. I knew the reasons I wanted File Helper, but I do not know how many other people would want it. Do others encounter similar problems to what made me want the tool?

I needed to create something in order to answer this question. I plan on having an MVP for File Helper online and available to download in October. This project was started around 5 months ago, and developed in earnest (nearly every day) for around 2 months. I would like to shorten this time for the next project, especially by gathering input from potential users much earlier, which is something I didn't do with File Helper.

If File Helper doesn't find an audience, I gained an extremely valuable data point. I'd know I am making the wrong thing[^1], and I would hopefully also receive user feedback to hint me in a better direction. I think spending a couple months to learn this lesson isn't entirely unreasonable, especially because I still gain a tool which is valuable to me at the end of it.

Crafting things is satisfying

I'm very proud of the projects I have finished. It feels good to create things, and even if those things "fail", the journey of putting them together, the "Aha!" moments, and tinkering with the whirring machine you built is still worth a ton.

[^1]: In the context where my end goal is to make enough money on my projects to sustain myself, which is my career goal.

Macoy Madson


Simon Anciaux

Meta Assembly Language

Dmitriy Kubyshkin
It has been a couple of months since the last update. As usual, there are a lot of internal changes to the compiler, but there are some interesting externally visible changes as well. I spent some time tightening things that seem stable enough, such as tokenization, encoding, and functions.

For the tokenization, I have switched from a hand-written tokenizer to re2c. It provided a nice boost to the compilation speed almost for free. I have also implemented caching for common number literals (0-9) and identifier names for another small boost.

With encoding, once I decided to ignore possible machine code size improvements from a relaxation step, I have realized that I could eagerly turn assembly instructions into bytes which save a whole lot of memory and some compilation speed. You can see me working on it in a YouTube video.

The big thing with functions is the basic support for generic arguments. Right now there is no way to constrain the type when matching overload, but even this basic functionality allowed moving type definitions of some of the compiler intrinsics into the user land:

type_of :: @fn(x) -> (Type) PRELUDE_MASS.type_of
size_of :: @fn(x) -> (Number_Literal) PRELUDE_MASS.size_of

Generic function support also tightened up internals quite a bit allowing to move allowing to move some of the previously intrinsics to the user land. The main example of this is the fixed-size array type function:

Array :: fn(item : Type, length : u64) -> (Type) {
  mass :: PRELUDE_MASS
  byte_size :: mass.Descriptor.bit_size.as_u64 * 8
  byte_alignment :: mass.Descriptor.bit_alignment.as_u64 * 8
  t : Type = mass.allocator_allocate_bytes(mass.allocator, byte_size, byte_alignment)
  t.tag = mass.Descriptor_Tag.Fixed_Size_Array
  t.bit_size.as_u64 = item.bit_size.as_u64 * length
  t.bit_alignment = item.bit_alignment
  t.Fixed_Size_Array.item = item
  t.Fixed_Size_Array.length = length

There were also a bunch of smaller notable changes:

  • Linux Syscall Support
  • Basic Tuple Support
  • Support specifying output path for the CLI
  • Moved arithmetic operator definitions to the user land
  • Support bulding with Clang-CL on Windows
  • Significantly simplify and speed up `using` implementation


Initially intended as a quick bug fix update, it became the largest update so far (based on tickets resolved).

For command line users, there are new language features that you'll hopefully find useful. For GUI users, performance has been drastically improved and the interoperability of hex view with the other views have improved. Also a slight upgrade for the graphics in general. I have planned some improvements for the hex view itself but I decided to delay that until next update.

A lot of changes have also happened in the background. As there are four distributional packages
  • Windows GUI
  • Windows GUI + CLI
  • Linux GUI
  • Linux GUI + CLI

creating these have been an error prone activity. As I intend to continue updating BEdit, this is now half-automated - and when I figure out how to do the Linux and Windows build on the same machine, hopefully fully automated.

Next update is currently getting planned and I have many many features and improvements I'd like to add, one of the major one being what has already been mentioned since day 1 "creating files". The actual creation abilities of the current state of BEdit is just as bad as a normal hex editor. There are also another hundred or so features I could prioritize instead, including editor integration (and add editor to GUI proper), binary format for instructions (so anybody could make their own layout language), MacOS build, improve the UI, ... yea, I think the list is triple digit long.

So if you have any feature / improvement request for next update, now is the time to share!

As always, the new update can be downloaded from itch io and the free command line version is also available here at handmade network, on the main page.