
Handmade: A Community for Self-Rolled Performant Software (2016) - TheUndead96
https://handmade.network/manifesto
======
abnercoimbre
Hey! I organized this community a few years ago; it's under great leadership.
Trivia points:

1\. The manifesto author was barely 18 when he wrote this; representative of a
new, younger cohort interested in this stuff.

2\. Handmade is into low-level understanding, but certainly a few people stick
to high-level projects, and simply peek behind the curtain when they _need_
to. Low-level thinking translating into high-level wins.

3\. Someone mentioned my conference, Handmade Seattle [0]. This is part of an
effort to expand into the mainstream, and to inspire the next generation of
compiler writers, kernel developers, game engine programmers etc.

We're not saying _everyone_ has to be into this. We want to carve out our
place, let those who care flourish, and not be caricatured for "reinventing
the wheel."

[0] [https://www.handmade-seattle.com](https://www.handmade-seattle.com)

------
arcin
The handmade hero community is wonderful. It is a portal to a lot of knowledge
transfer. If you're looking to approach C/C++ in a welcoming environment
and/or love getting closer to the metal, I highly recommend the community.

I also recommend the handmade video series.

Casey Muratori has been live streaming himself build the same game for the
past few years. He try's to build everything from scratch, which is
entertaining and quite the brain dump.

Also, the video archive and live chat is searchable. I can't count the number
of times I

\- searched for some keyword or phrase, like "CPU"

\- was greeted by a link that read something like this

 _" Day 025: Finishing the Win32 Prototyping Layer (01:38:59) Isn't the CPU
Memory bandwidth only valid for on-die memory?"_

\- clicked the link to receive 3-10 minutes of extremely dense but well-
explained information on a topic.

\- spent the next hour or so googling technical terms and subjects that filled
massive holes in my knowledge.

If you love learning, treat yourself to jumping around the video archive :)

[https://guide.handmadehero.org/](https://guide.handmadehero.org/)

Two favorites of mine from the archive Undefined Behavior:
[https://guide.handmadehero.org/chat/chat011/](https://guide.handmadehero.org/chat/chat011/)

Modern x64 Architectures and the Cache:
([https://guide.handmadehero.org/chat/chat017/](https://guide.handmadehero.org/chat/chat017/))

P.S. Its worth mentioning that you can buy the game hes building and get
access to the source code. I'm not associated with handmadehero.org or Casey
Muratori in anyway. The community just led to me becoming a better programmer
over the past 5 years. I hope someone reading this finds the value I did in
rabbit-holing for hours and laughing at the rants of a seasoned game dev.

*edit: formatting

~~~
Udo
There also used to be a meetup in Seattle [https://www.handmade-
seattle.com/](https://www.handmade-seattle.com/) (which has since moved online
due to the pandemic situation) but in the past they had some pretty good
presentations and interesting speakers. You can find some videos of them
online (Youtube: "HandmadeCon" and "Handmade Seattle") although regrettably
there are no recordings of last year's meetup.

~~~
abnercoimbre
I'm in the process of getting a few of them officially up. I had lost contact
with the cameraman after COVID, but we're in touch again!

~~~
Udo
That is great to hear Abner, thank you very much for all your efforts! Because
I couldn't make it to Seattle last year, I missed the entire thing, it would
be awesome to see some of the presentations.

------
senko
Why is that we praise hand-crafted objects in the real world while at the same
time deriding such hand-crafted code as a quaint curiosity that can only make
sense as a hobby of the hopelessly romantic?

Do we compare your local carpenter with IKEA, or that delicious, nutritive and
healthly meal you cooked with McDonald's, in terms of pure (developer)
performance?

Do we obsess over how a handmade jewelrer can't scale operations to five
continents?

Why do we copycat every process or idea from tech behemoths but laugh when
someone tells us that maybe a chat client shouldn't gobble up gigs of RAM?

In the real world, both craft workshops and assembly lines have their place.
Maybe that should be true for the digital world as well.

~~~
lukevp
Carpenters still use harvested, dried, milled lumber. Chefs still use
harvested, dried, milled flour.

Frameworks are tools and building blocks like this, but for software. Not
using them is not like an artisan carpenter using lumber from the store. It’s
like a carpenter making their own boards, or a chef making her own flour. It
is not really relevant to efficient, performant software, it is more like an
art for the sake of it.

~~~
commandlinefan
> Frameworks are tools and building blocks

Tools, maybe, but I have yet to see anything that calls itself a "framework"
(i.e. Spring, Angular, Django, Salesforce) that doesn't a) bloat the hell out
of the binary, b) use more memory than it can possibly justify, c) create
impossible-to-diagnose problems, d) not actually provide anything except
overhead.

~~~
mattgreenrocks
The best framework I've used is probably MonoGame. It abstracts away
accelerated 2D graphics across multiple platforms, asset loading, and input
handling, among a few other things. You write your game not against DirectX,
but against the concepts it introduces. Unlike modern ideas of frameworks, it
doesn't preach to you that you need to name things certain ways, or impose
other slightly-pedantic notions on you.

Instead, it's focused on getting out of your way. Most other frameworks seem
to love getting in your way, because they see themselves as so important.

------
miki123211
What people don't realize is that modern, high-level languages and
abstractions give you much more than just speed of development.

If you use a garbage collector, you don't have to do manual memory management,
which is amazing for security. You also don't need to worry about buffer
overflows and weird pointer exploits.

If you use web tech, you get a lot of important stuff, like sandboxing,
handling of esoteric keyboards, RTL languages and screen reader accessibility
almost for free. If you use some extremely fast, small and lightweight GUI
framework, you will probably not implement those, as they seem boring, and who
needs that anyways.

If you go the handcrafted, lightweight and fast route, you're sacrificing a
lot of features, possibly without even being aware of what you lose until it's
too late.

I will happily shelve a few more bucks for RAM and wait a few more seconds to
get an accessible, secure Messenger, instead of one that is going to steal my
bank details the moment some stranger sends me a malicious GIF.

~~~
beached_whale
A pedantic point, buffer overflow protection and the GC are separate things.
Buffer overflow protection is bounds checking, GC's are ensuring memory that
is no longer in use is reclaimed. But the boundaries on the programs you
mention, are more to do with the system not allowing these actions than the
language.

Also, there are other ways to achieve memory safety for all but maybe a few
cases without a GC. One being ref counted structures that have loops in the
links. Another case, but it has work arounds, is postponing the cleanup until
a later time. But C++ provides guarantees like, at scope end the
destructors(finalizers) are run and the values are cleaned up. This allows for
more than memory safety and can include other resources too. This is easier in
greenfield projects where old idioms/C compatibility are more common.

To add to your point, high level abstractions allow for optimal code as it is
more declarative. The low level constructs to make it fast are of no concern
to the caller. And one can build upon this for new higher level abstractions.

~~~
deschutes
What is your point? The way refcounted smart pointers are used in modern c++
doesn't come close to addressing all the memory safety issues. Iterator
invalidation, bounds checking, use of uninitialized memory, use after move,
dangling reference (outside the aforementioned cases), etc.

What they're pretty good at is solving for use after free. Even there, caveats
apply (see widely documented thread safety fiasco of shared_ptr).

------
PaulDavisThe1st
I've been writing C code for more than 30 years, C++ for 27. I've written code
at every level of "the stack", from kernels of several nix-related operating
systems to application GUIs. I've worked on "plumbing", on libraries, and on
applications.

And here's the thing: I understand, at a very very deep level, precisely why
my application is slow to start up. I understand it at every level from the
semiconductor gates in silicon up to the color specification lists used by the
GUI toolkit. But none of that helps me make it as fast as the handmade
community thinks things should be.

Why? Because I know that the slow startup is caused by substantial amounts of
code that all add useful functionality for at least some of my users. Do I
want to get rid of i18n? Shall I skip checking for new versions? How about
forcing plugin scans to be initiated by users and never doing them
automatically (don't even _think of_ suggesting doing them in another thread,
and don't ask me why)? Shall I skip the ability to handle RTL text? Should we
drop human readable and editable configuration files in favor of some faster
and less resource-eating format? How about a scalable GUI, is that really
useful for most? How about a themeable GUI, given that it's not actually that
themeable anyway?

And so on and so forth. Each one of the above (and lots more) contributes just
a little bit to the slow startup. For most users, all but one of them will
likely seem not very important. So which ones do we drop to get back to the
sort of startup times that the handmade community seems to expect?

Because let's face it, xterm can put a window on the screen before my finger
is off the return key. So why not a DAW (or an IDE or an editor or a vector
graphics app or an image editor or a browser or a circuit emulator or whatever
your thing is) ? Just which features do you want to cut to accomplish this?

~~~
Olreich
Let’s call 1 second the threshold for a bare system with an SSD and 4 core CPU
at 2Ghz. That gives you 8 billion cycles to start up, trading off with file
access, so maybe only 4 billion of those have access to all the data you need
in memory (modern ssd loads what, 400 MB/s?).

So all the startup code and initial assets are larger than 200 megabytes and
take more than 2 billion cycles to prep? Computers are fast, software is slow.
Sure, things aren’t trivial to always fit in that package, but it’s
disingenuous to say you need to take many seconds to start up.

Look at a giant piece of software that was built for more limited times:
Visual Studio. It used to start up in milliseconds back in 2000. Now it takes
30 seconds. Did it really improve things so much to justify that in the
intervening years? I’d go with no.

You know what else has an amazing set of features and capabilities including
internationalization and accessibility and all those other complicated things?
Web browsers. And there’s not a browser on the market that doesn’t start up in
more than a couple of seconds, including loading a full webpage and rendering
it from the internet.

~~~
PaulDavisThe1st
Well, maybe I'm being too harsh on myself. Timing Ardour on my machine (Ryzen
2950X with 64GB of RAM), it has something on-screen is less than 1 second. But
actually loading a "significant" session is more like 6 seconds. There's
approximately 300MB of data in the session in total, but most of that is audio
data that isn't being read at startup.

I've seen DAWs start up massively faster than this, though. And also slower.
Essentially I have some intuition that "correct" software design would appear
to the user as a more incremental startup: the window would appear as rapidly
as xterm does, and would slowly fill with everything that makes up the actual
program. I personally find this hard to design for. Could be me, or the GUI
toolkit I use or maybe it just is pretty hard.

As for browsers, "a couple of seconds" has some slop. When I restart Firefox
here, with typically 100-200 tabs and the main/primary/#1 tab being gmail
(unfair! i hear you cry), I'd say it was more like 5-10 seconds until it is
usable.

------
Cthulhu_
While "handmade" code may be faster, it's also a big time sink and as a
developer your job is to make tradeoffs.

For most software, you should probably focus on architecture instead of the
lower level of your code. Sane code and architecture solves most performance
issues. This includes technology decisions, like using web tech for
applications instead of the native platform.

For example, Apple has had a lead of at least five years over Android when it
comes to performance and user experience, because their system and apps were
all built in native environments, instead of the JVM abstraction layer. It
took at least five years for Android to catch up, and it took quadcore CPU's
to do it. Around then, Apple carefully started using dual-core CPUs.

Meanwhile, companies like Facebook and Twitter spent dozens of work-years on
trying to make web technology feasible in native apps and never really cracked
it.

If they had just focused on building good native apps they wouldn't have
wasted so much time.

Caveat / Aside: IIRC Facebook is having / has had massive issues with having
too much code / classes / files in their app(s), on both iOS and Android.
Which is (I believe) one of the reasons why they split off Messenger into its
own app at the time.

~~~
gridlockd
Here's the fundamental difference between iOS and Android, and it's related to
memory management:

On iOS, you pay for memory management in small installments, which make your
code slower overall (reference counting in ObjC/Swift), but predictably so.

On Android, you pay almost nothing for memory management until at some random
point the garbage collector shows up and stops your program to clean up your
mess. Your program is going to be janky.

Apple deliberately ships devices with little RAM and kills applications that
use too much of it. As a developer you better pay attention, or you will be
flooded with bad reviews.

Google leaves RAM up to vendors. The secret to good performance with GC is to
make the heap twice as large as the data which it contains. Low-end Android
devices _feel_ low-end, not just because of slower CPUs, but also because of
too little RAM.

It has nothing to do with the "JVM abstraction layer". Java code on a good JIT
easily runs faster than Swift or ObjC if there's a lot of allocations
involved, but the GC behavior must be accounted for to give a good experience.

------
Stierlitz
“Why does it take your operating system 10 seconds, 30 seconds, a minute to
boot up? Why does your word processor freeze when you save a document on the
cloud? Why does your web browser take 3, 4, 10 seconds to load a web page?”

Bloat !!!

------
mwcampbell
The Handmade metaphor masks a key difference between software and physical
goods. IIUC, mass-produced physical goods are inferior to their handmade
counterparts because of the trade-offs that enable profitable mass production.
So we have a strong emotional attachment to handmade things being better, and
the Handmade movement plays on that emotional attachment.

But the metaphor breaks down if you think about it. A carpenter making a
single piece of furniture can tailor it to the person who will be sitting on
it. A cook making a meal for one person can tailor it to their dietary
requirements or tastes. But software of any non-trivial scale is rarely
written for one person. Even when it's developed according to the ideals of
the Handmade movement, it will be mass-distributed.

I actually think that, contrary to our intuition about handmade things,
Handmade software tends to have compromises compared to software that builds
on well-established components. I won't repeat miki123211's top-level comment
[1]. I'll just add here that it's precisely the economics of large-scale
software distribution that allow concerns such as internationalization and
accessibility to be addressed, while a solo Handmade project will probably not
have these important things.

So, while slinging JavaScript code with no regard for performance and
packaging it with Electron is certainly not the ideal, I strongly believe that
the Handmade approach isn't either. As is so often the case, we need a middle
ground.

[1]:
[https://news.ycombinator.com/item?id=24186711](https://news.ycombinator.com/item?id=24186711)

~~~
ratww
_> As is so often the case, we need a middle ground._

This is not a popular opinion here, but: the middle ground is writing handmade
native apps using native OS widgets. You get both the speed and a mature
environment to work with.

If you follow the platform conventions you will probably have better
accessibility and internationalisation support than Electron. They will run
fast as a bullet. They will consume a puny amount of memory. They will have
dark mode for free on macOS. They will look like most other applications that
come with the OS. It probably also has a graphical editor that will make your
job easier (.NET, MFC, Cocoa, all have).

If it's something like .NET you won't even have to worry much about the
"Turkish internationalisation Problem" that we were discussing yesterday. [1]

Things like localisation that require a framework/library in the web world are
probably handled by the libraries provided by the OS vendor.

If it's "handmade", you're already putting a lot of effort that you wouldn't
put in your day job. Why not use that effort to port directly to each
platform, instead of recreating everything from scratch?

For Linux the situation is more complicated, of course, but maybe Qt is
acceptable?

[1] [https://blog.codinghorror.com/whats-wrong-with-
turkey/](https://blog.codinghorror.com/whats-wrong-with-turkey/)

~~~
mwcampbell
I mostly agree with you. But which toolkit for Windows is the "native" one?
This is a well-known problem with Windows development, so I won't belabor it
here. Hopefully Project Reunion improves the situation. But the murky state of
native development on Windows is a big reason why developers just throw up
their hands and go with something non-native that at least will work
consistently all the way down to Windows 7 (or XP before that).

Disclosure: I work for Microsoft, but on the Windows accessibility team, not
on a UI framework or developer tools.

~~~
ratww
Glad to see someone from Microsoft interested in seeing this issue solved. :)

Well, native for me is whatever provides native look and feel. Win32 if you
want C/C++, WinForms (yeah I know) if you're ok with C#. Most people featured
in the article's website would only consider "truly native" as being Win32,
though, which is fine.

------
srg0
It reminds me of [https://suckless.org/](https://suckless.org/)

Also the set of projects is somewhat similar:

window manager (dwm) -> game engine library (raylib)

terminal emulator (st) -> IDE template (4coder)

web browser (surf) -> video browser (motionbox)

\+ tools and libs...

------
bArray
I love all the game engines in there! Really makes me feel like hacking some
game together to test them!

------
fulafel
Interesting what words the manifesto doesn't mention: correctness, security,
safety, bugs.

------
Vai1sail
Damn, this place looks amazing, it looks like El Dorado in a sea of despair,
for someone being used to make the same points than this manifesto and being
looked as a weirdo in response.

Sadly they block Tor users, because they use Cloudflare. Maybe we're not that
much on the same page after all.

~~~
jgrahamc
Cloudflare doesn't block Tor users by default and I just visited the site
using TBB: [https://imgur.com/a/GHpbvTD](https://imgur.com/a/GHpbvTD)

~~~
Vai1sail
Are you kidding? Or is it corporate speak, like "it does not block Tor, only
99% of its users"?.

Cloudflare is what makes the web unusable for Tor users. Every two websites
you try to reach, yup, blocked by Cloudflare. The fact that you try to deny it
makes it painfully obvious how there is no hope for Cloudflare. Sorry, I can't
wish any good to your company.

------
phtrivier
TL,Dr : knowledgeable, skilled programmers writing semi-confidential software
in C for mostly a single OS, by themselves, with total control of the feature
set and release schedule, can produce pretty fast binaries.

Which is great ! I just don't know how to transfer that to building software
as a team with multiple skillsets, unknown feature set (because market feet is
still searched for) aggressive schedule, (We don't know what we want to build
, but we need it in six months), large target audience ("what do you mean they
have to install stuff ? Where is the link I can paste in an email so they open
it in IE6 ?") , and,let's be honest, less knowledgable and more lazy
developers.

(To be clear : I'm _not_ criticizing the network or project. I just find it
interesting that they had a goal - making fast software - and that, to the
ebest of my knowledge and without a rigorous analysis - it seems that most
projects converged on a very particular kind of software. Which just happens
not to be the kind most of us will ever be working on, but it does not matter.
Go them !)

~~~
phendrenad2
Speed is a very real selling point for software though. If your competitor
takes 6 months to get to market, and then is locked-in to a bloated, sluggish,
badly-architected codebase made from 50 abstraction layers, you have plenty of
time to come in later and steal their userbase, when your project is done and
can do things in 1/10th the time.

~~~
phtrivier
My prior in such a situation would be to assume that "stealing userbase" is
very hard. It depends on the kind of application, of course, but once you have
paying / committed user, I'd assume the friction to change (and natural
risk/change aversion )would be in favor of the incumbent.

That being said, arriving afterwards with a message of "we're like X,but
faster" could be a good marketing catch, but probably not for any kind of
enterprise app. (The only good marketing catch in this case would be "we're
like X, but cheaper.")

No idea how such an hypothesis could be tested. We would need records of user
switching from an app to another.

------
willvarfar
So the bottom of the linked article says 2016, which made me immediately think
'old!'

It makes complete sense for the manifesto to be timestamped, but the surprise
was that I didn't realise I was reading the manifesto rather than this
actually being the normal landing page... there's no title or anything and HN
usually links to homepages.

But a quick glance at the forum and the homepage shows there's activity there
still!

Clicking around, this seems really interesting :)

~~~
mrkeen
> So the bottom of the linked article says 2016, which made me immediately
> think 'old!'

I yearn for the day when the industry reaches a state of reliability where we
see "old" as a good thing, i.e. "this problem was solved ages ago!", rather
than it seeming out-of-date.

Probably not in my lifetime!

