---
title: "Segfault, the mother of invention"
date: 2024-01-31
type: post
layout: default
permalink: /drafts/segfault/
draft: true
---

There is no greater joy for a programmer than to build his own tools. A few
weeks ago, I embarked on a little coding experiment: I wanted to see if it was
possible to build a 2D/3D software suite with an embedded scripting language
more or less from scratch.

This all started when I wanted to try Blender, a popular open source 3D tool.

    $ blender
    Writing: /tmp/blender.crash.txt
    zsh: segmentation fault (core dumped)  blender

The last time I tried running Blender, which was some five years ago, it worked
fine. Turns out this is likely due to an LLVM dynamic library incompatibility,
as stated by someone on the Arch Linux bug tracker:

> So, OSL is linking LLVM15, and the driver is linking LLVM16. Something is
> breaking because two different versions of LLVM are being linked concurrently
> and calling into each other, presumably because symbol versioning is disabled
> or broken.

If you're wondering why Blender depends on LLVM, one of the most sophisticated
compiler toolchains ever created, with millions of lines of code, your guess is
as good as mine. But anyway, if your reaction to the above is not *wtf?*, you
have already given up on software.

Here's a useful principle:

> **Principle**: To assess the complexity of a piece of software, its entire
> dependency tree must be considered.

Naturally, dynamic linking makes a software's dependency tree a runtime
concern, ie. mostly unpredictable. Shucks.

I tend to have very limited patience dealing with code I didn't write,
especially when it doesn't work. To avoid that, I try to keep dependencies to a
bare minimum, and pick ones that mostly get out of the way. This has worked
well for me, probably because bugs are typically corelated with code size (yes,
this includes transitive dependencies). In other words, less code equals less
things that can go wrong. Every dependency you add has a benefit and a cost,
and we tend to overestimate the benefit and underestimate the cost. Picking
dependencies is all about this cost to value ratio.

    Ratio = Benefit (time saved) ÷ Cost (dependency burden)

Naturally, when I wasn't able to run Blender, I asked myself what it would take
to write my own. I've dabbled in graphics programming before and wrote a [pixel
editor][rx] a few years ago, what would it take to add a third dimension? This
is the question I wanted to answer, and the direction I wanted to explore. I
like to constrain myself to working mostly with the standard library of a
language and a very minimal set of dependencies; mostly for the code I don't
want to write. Things like C bindings and platform-specific code are usually in
that category.

Hence, when thinking about new projects, the question of dependencies is the
first one I ask, and after doing a bunch of research, I landed on these three,
somewhat unsurprisingly, for a 2D/3D graphics application:

    [dependencies]
    glfw = { version = "0.54.0" }
    glow = { version = "0.13.0" }
    log = { version = "0.4.20" }

These are the things I don't want to have to reinvent.

[glfw][glfw] is a rock solid OpenGL context creation and input handling library
I've been using without issue for over a decade. Compared to SDL, it's a tenth
of the size, while doing everything I need. It contains lots of
platform-specific code I'm not willing nor able to write.

I chose `glfw` over [winit][winit] because I'm not interested in running
software on mobile or web, and winit's API is a compromise made to support
these platforms. For instance, `winit` doesn't give you control over your event
loop. This is a deal breaker for me. It's common to lose power and flexibility
when using APIs that try to abstract over vastly different domains.

[glow][glow] is a set of GL bindings for Rust, optimized for portability. It's
a great library that doesn't try to do too much:

> GL on Whatever: a set of bindings to run GL anywhere (Open GL, OpenGL ES, and
> WebGL) and avoid target-specific code.

The `log` crate doesn't need much of an introduction. Since I avoid async rust,
there is no need for anything more advanced in terms of logging.

I chose to build directly on OpenGL 3.3, as opposed to using something like
[wgpu][wgpu] because OpenGL is already the hardware abstraction layer that I
need to write cross-platform code, and it's not going anywhere. All I would add
is a thin wrapper around it to make it more palatable.

What about the GUI? There are dozens of libraries in Rust to choose from, but
they either depend on something like GTK, have a massive dependency tree, or
are coupled with their graphics backend. I'm a big fan of [Raph Levien's][raph]
work, such as [druid][druid] and [xilem][xilem], but these are large, and still
unfinished projects that I'd rather not take on as dependencies. However, I
think a lot of [good ideas][archi] can be borrowed from them.

There are many other promising UI library projects for Rust, but none tick
all of the boxes for me, so I decided to build my own on top of `glow`.
The goal, as usual, is to write something maintainable and as close to
dependency-free as possible. If it ends up being useful to others, great,
but it will be primarily built based on my own requirements for this project.

So far, a few weeks into the project, I have a thin, ergonomic wrapper around
`glow` inspired by [sokol-gfx][sokol], a basic 3D renderer, a scripting
language, and the beginnings of a small [retained mode][retained] GUI library.

I'm discovering a lot of interesting problems along the way and having to make
all sorts of trade-offs and decisions to keep the code size small and
manageable for one person. So far, it feels like the goal of having a usable
2D/3D software stack for my own needs is achievable. I'll be posting updates
here as I make progress.

[raph]: https://raphlinus.github.io/
[archi]: https://raphlinus.github.io/rust/gui/2022/05/07/ui-architecture.html
[xilem]: https://xilem.dev/
[rx]: https://rx.cloudhead.io
[glfw]: https://www.glfw.org/
[glow]: https://crates.io/crates/glow/
[winit]: https://crates.io/crates/winit
[wgpu]: https://wgpu.rs
[druid]: https://docs.rs/druid/latest/druid/
[sokol]: https://floooh.github.io/2017/07/29/sokol-gfx-tour.html
[retained]: https://en.wikipedia.org/wiki/Retained_mode