systems are just a bunch of code

often enough I see people scared to dive deep into the internals of their favorite technologies
- because it looks scary, or they think it’s not really gonna impact their lives too much.
and people tend to form these grandiose noun phrases like The Object System, or The Borrow Checker, making it seem like there are impenetrable walls that guard these complicated pieces of software, and that only people worthy enough will be granted entry into them.
- but great adventurers fear no dungeons, as the deepest dungeons often hide the most precious treasure.
over time I’ve been growing accustomed to knowing my dependencies. after all, how can I depend on some code functioning correctly, if I don’t even know how it works, or what to do to repair bugs in it? or even where to go to customize it to my liking?
- it’s largely annoying to me that compilers ship without their source code, nor do they ship with debug symbols. it would be great if whenever rustc crashes on me while incremental-compiling the treehouse (and it does so pretty often), I was able to catch the crash with a debugger and step through the code to see what happened.
  - but alas, performance and size optimizations make that impossible. I just end up filing bugs in the compiler repo OR moving on with my life.
  - I wonder what the world could have been, had we been compiling and optimizing software on users’ computers rather than downloading ready-to-use, but opaque binaries.
    I imagine a world where I can tell the computer “I’d like to debug this crash” after the compiler crashes, and it will download the relevant sources and let me single-step through the code to see what happened.
    and then I could edit the source code and submit the patch right where I’m standing rather than having to go through complicated and lengthy processes of cloning repositories, bootstrapping, reproducing, and such. imagine fixing compiler bugs on real codebases rather than having to come up with isolated, reproducible examples first.
    I know how hard this is to achieve in practice, which is precisely why I don’t use Gentoo.
- package managers like Cargo make using someone’s code incredibly easy, and that’s really cool. we should be encouraged to share reliable, well-tested code instead of reinventing half-baked solutions every time we need a thing.
  - but I think at the same time they make understanding someone else’s code kind of an afterthought.
    to integrate a library into your C++ project you usually have to browse through their CMake build files to figure out how they name their build targets. and while doing that, through cursory glances at CMakeLists.txt, you gain knowledge of what knobs can be tweaked in the project, how it builds. you may even stumble upon a list of source files, which can give you clues as to the underlying architecture.
    
    while this can hardly be called understanding the code, at least it gives you a peek into how it’s structured.
    (and I’m not defending C++ here, I think its dependency management has a terrible UX in the long run and makes sharing code needlessly hard - but like all tools, it has its strengths and weaknesses)
  - Cargo on the other hand makes it needlessly difficult to poke at someone’s code.
    when vendoring code into C++ projects, you make the build system treat your dependencies as just another piece of code in your code base, which means you can insert debugging code wherever you please, and the build system will happily rebuild it.
    Cargo treats dependencies as immutable, which means that a given version of a package only compiles once per your project. you can’t go poking at the package’s files for debugging purposes - you can’t insert dbg!(x) expressions where you need them, which is really annoying. the only way I know of is to use overrides, but compared to editing an already vendored dependency, those are quite cumbersome to set up…
    you need to clone the repository at the correct version (I don’t even remember the Git command to clone a repository at a given tag)
    which means opening a separate terminal, cding into your folder with repositories
    also adding the repo as a project in your IDE
    then you need to edit Cargo.toml to override the dependency
    have fun typing in that full path /home/daknus/Repositories/cool-library
    and don’t forget to revert the changes to Cargo.toml once you’re done. unlike editing a vendored dependency, which will appear under a very visible path in Git, it’s pretty easy to forget to check your Cargo.toml diff before staging/committing changes. I mean, I edit my Cargo.toml all the time, adding in libaries and stuff. so why would I look at every single change?
    and before you go at me and say “bah you should be reviewing all changes that end up in your codebase”
    
    sigh.
    
    listen. I’m not gonna review all the garbage I commit into my personal website, alright. I value fast prototyping over having a clean Git history in this particular case.
    don’t forget that overriding dependencies doesn’t always work - if the resolver cannot resolve your override, it will not build your project.
    most of the time the more reliable approach ends up being editing the workspace.dependencies entry for your dependency, and changing it to use a path instead of a version.
    this all sounds automatable, but it’s pretty annoying nevertheless that the basic functionality of poking into one of your dependencies is hidden away under layers of caching and patching and immutability and stuff.
    seriously I just wanna insert a dbg!(x), how hard could it be?
as an example, when I first started working with Unreal Engine, everything seemed like magic.
- like how in the world does the GENERATED_BODY() macro manage to expand to different things depending on which class or struct it’s declared in?
- but the more you poke at it, the more you look at definitions, the more you look at the build tools, the less magical it all seems. it’s all just code-generating syntax sugar!
  - everything is code! there is no magic!
    there are no walls blocking you from looking at the code. the grandiose noun phrases are misleading!
    UnrealBuildTool is just a bunch of C# files. and the Gameplay Ability System™ is likewise just a bunch of C++ sources. why can’t we come up with more inviting names?
    grandiose noun phrases sound so hostile. but it’s all just code.
most of the time not knowing your software is largely fine - not everyone has the time to deeply inspect a piece of software, deciphering functions, consulting manuals, asking the authors (when possible.)
- what I’m saying is that we should be encouraging more engineering practices and tools that enable us to inspect and poke at our dependencies when we need it.
  - don’t fear code; respect it like it’s your Holy Mountain. a place to tinker with stuff, and occasionally wreak havoc, anger the fuck out of the gods, and let them kick your ass with an EXCEPTION_ACCESS_VIOLATION or another Segmentation fault (core dumped). and then Steve kills you but you start another run anyways because this game of chasing bugs and perpetually improving software is just too damn addicting
next time you encounter a crash in some library you’re using, try stepping into it with your debugger. you might find some real gems in there.