Adriano Dias · Writing

Not Invented Here (Yet) 🦀

2026-10-27T00:00:00Z

So. Funny thing happened on the way to having a simple blog.

You may remember my first post, where I explained that I'd chosen static sites because I'm lazy—sorry, efficient—and didn't want to maintain anything. A reasonable position. A position I held for roughly as long as it took for the Tailwind build to break in a way the error message declined to explain.

Reader, I did not debug it. I rewrote the whole generator in Rust.

🧱 The Current Inventory

Here's the honest state of my "I just want a simple blog" project:

Statico — a static site generator. Replaces Static by DevDojo. It builds this very page. ✅ Done, actually works, I'm using it right now.
berth — a free, open-source take on OrbStack. Docker and Linux on Apple Silicon, straight onto Virtualization.framework. Because I looked at my container tooling and thought "how hard can it be." 🚧
rustyphp — a PHP engine. In Rust. We'll come back to this one. 💀
This website — I needed a portfolio. A portfolio is one page. Instead it boots like an operating system on an old CRT: windows, a dock, a pretend browser, a terminal, a screensaver, a folder of sixteen little tools, and a fake Tinker and Drush backed by a small PHP interpreter I wrote in JavaScript. (Yes, another PHP engine. Given what happened with the last one, which we'll get to, this was brave.) There's even an AI agent window that pretends to rewrite the site while you read it, which is either satire or a cry for help. ✅ You're inside it right now.

That's the part I'm willing to put in a list with a straight face.

⚰️ The Graveyard

Here's the part nobody puts in the list.

For every project above there's a folder of repos where the README is comfortably the most finished artefact in it. Things I started at 11pm with total conviction and abandoned by Thursday, not because they didn't work, but because the interesting problem had already been solved in my head and the remaining 80% was just typing.

This is, I think, the actual occupational hazard of vibe coding. Not bad code — bad follow-through. When starting something costs an evening instead of a quarter, you start everything. The bottleneck was never the idea. It was the three weeks of grind that used to filter out the ideas that weren't worth it, and that filter is gone now.

So you end up with a graveyard. Every vibe coder has one. Mine has a view.

I've made peace with it, mostly. Some of those repos were genuinely just me learning something with extra steps, and there are worse ways to spend a Tuesday. But I do notice that the three projects I listed above are the three I actually use, and I don't think that's coincidence. Dogfooding is the only honest filter I've found: if you don't reach for it on a normal day, it's already in the graveyard, it just hasn't been told yet.

💀 rustyphp, or: Signs and Portents

Which brings me to rustyphp.

I write Drupal and Laravel for a living. PHP has paid for every meal I have eaten in a decade. So naturally I decided to implement its engine. In Rust. Voluntarily, in my own time, for fun.

Shortly after I started, my MacBook's screen did this:

Two vertical black bars. Straight down the display. Permanently.

Now. I want to be clear that I am a professional and I understand that display failures have physical causes — a flex cable, a panel defect, thermal cycling, the ordinary cruelty of hardware. There is no mechanism by which writing a PHP parser damages a laptop screen.

I understand this.

I am simply observing that I have written PHP for ten years without incident, and that within weeks of attempting to reimplement it, my machine developed a permanent visual impairment in the exact region where I had been reading the parser code.

I'm not saying it's related. I'm saying I haven't opened that repo since, and my screen hasn't gotten any worse. Draw your own conclusions. Some things aren't meant to be rewritten, and PHP's engine may well be load-bearing for reality in ways the spec doesn't document.

rustyphp stays where it is. Respectfully. 🙏

🎤 In My Defence, DHH Started It

Here's where I'd like to shift some blame.

At Rails World 2026, DHH gave a keynote about how 37signals is building software now — there's a good write-up over at Rustify. The short version, as I understood it through the haze of my own enthusiasm:

They've gone "pencils down" — meaning the normal workflow is no longer a human typing the implementation. A human decides what should exist, an agent writes it, the human reviews what came back.

He reckons Rust is unpleasant to read and write by hand, but that this matters a great deal less when a human isn't the one doing the typing. Meanwhile it's fast, which you get to keep forever.

They rewrote the HEY mail server core in Rust and reported something like 99% less CPU and 95% less memory. He was upfront that these are their own numbers from their own workload, so season to taste — but even if you halve it twice, that's still an absurd result.

And the number that really got me: around 150,000 lines of code in a single month, against a historical average of roughly 30,000 lines of production Ruby per year. The Rustify write-up is careful to point out that counting lines is a famously terrible way to measure productivity, which is true, and which I ignored instantly because it was telling me what I wanted to hear.

So. A man with considerably more credibility than me says the constraint has moved. Rewriting your tools is no longer obviously insane.

I took this as a personal licence. I don't think it was issued as one.

🫠 The Part Where I Admit I Might Be Losing It

Let me be honest about the other side of this, because the post would be a lie otherwise.

There's a specific feeling when an agent hands you 2,000 lines of working Rust in a language whose borrow checker you've argued with maybe twice. It passes. The tests are green. The benchmarks are genuinely good.

And a small voice asks: do you understand this?

Sometimes yes. Sometimes I understand it the way you understand a city you've only seen from a train. I know the shape. I could not give directions.

I keep catching myself in a loop that goes:

Notice minor annoyance in existing tool.
Think "I could rewrite this."
Actually rewrite it, because now that's a Tuesday evening rather than a six-month project.
Now maintain it. Forever. Alone.

Step four is doing a tremendous amount of silent work there. Statico is lovely right now because I wrote it last week. Ask me about maintaining it in two years when someone files a genuinely good bug report about a Tailwind v5 edge case I've never heard of.

The honest summary: I cannot currently tell whether I'm being unusually productive or unusually unhinged. The outputs look identical from inside.

🏄 Until Then: Vibe Code Everything

So here's where I've landed, and I accept it is not a rigorous position:

I'm going to keep going. Full send. Vibe code everything.

Partly because it's the most fun I've had programming in years, and I think that counts for more than people admit. Partly because the tools I've ended up with are genuinely better for me — Statico does exactly what I want, has no Node in it, and builds this site in under a second, because it was built by someone with a sample size of one user and strong opinions about that user.

And partly because if the constraint really has moved, the people who find out first will be the ones who went and poked it.

I'll reassess when something catches fire. Something already did catch fire, technically, but it was only the screen. 🦀

🔮 Next: Local Models, and a Very Expensive Laptop

Which brings me to the next thing I'm going to be insufferable about.

I've been dabbling with running models locally, and so far it's been equal parts "oh, that's genuinely useful" and "why is this eating my entire machine." Both of these problems may be solved by throwing money at them, which is my favourite kind of problem.

A MacBook Pro M5 Max with 128GB of unified memory arrives later this week. 🎉

That is an amount of RAM that would have run a small hosting company, and I intend to spend it asking local models to write Rust I will then nod at knowingly. It also, and I cannot stress this enough, has a screen that works.

I'm planning to write up what I actually find, honestly — which models are genuinely usable at that memory, what the speeds really look like rather than what the benchmarks claim, and whether local models are good enough yet to do the sort of work I've been handing to the cloud. Including the bits that don't work, because those posts are more useful and nobody writes them.

Assuming the laptop arrives, and assuming I haven't started rewriting macOS by then.

Stay tuned for more rambling!

Hello World 🌍

2025-04-08T00:00:00Z

Updated, October 2026 — this post originally walked through building the blog with Static by DevDojo. The site now runs on Statico, a static site generator I ended up writing in Rust. The commands and the deploy workflow below have been updated to match. Everything else is as it was.

Oh, hi there! 👋 Welcome to my very first blog post. Think of it like that awkward "Hello, World!" program we all wrote when first learning to code.

I've decided to kick things off by embracing the concept of less is more, mostly because I'm lazy—oops, I meant "efficient" and I found out static sites are an awesome way to achieve this. Plus, who has time for complicated CMS setups, database migrations, updates, etc etc...

🚀 Static Websites: When Less Really is More

You might be thinking: "Static websites? Sounds boring!" But hear me out, they're like the IKEA furniture of web development—sleek, functional, and occasionally frustratingly simple. No moving parts means fewer things to break, less to maintain.

I started out with Static by DevDojo because:

It's free (my favorite price).
It's easy (my favorite difficulty level).
You can get something looking nice really fast.

That's what got this blog off the ground, and the idea behind it is still exactly what I wanted: pages are just HTML files, with a handful of tags for layouts, includes and loops. No template language to learn.

What I kept tripping over was everything around it. It needs Node, the Tailwind setup broke in ways that were hard to pin down, and when something went wrong the error rarely told me which file to look at. So I did the reasonable, proportionate thing and rewrote it in Rust. 🙃

That's Statico: same HTML, same folders, same tags — one binary instead of a Node toolchain. My site files didn't change at all when I switched, which is the part I'm most pleased about.

🛠️ How to Statico Like a Pro (or at least Fake It)

Here's the quick guide to getting started:

Install Statico: it's a single binary, so there's nothing else to set up. Open your terminal and run:

curl -fsSL https://raw.githubusercontent.com/adrianodias8/statico/main/packaging/install.sh | sh

This drops a statico binary into ~/.local/bin. Builds for other platforms are on the releases page.

Create a New Project: Navigate to the directory where you want your project to reside and run:

statico new my-static-site

Replace my-static-site with your desired project name. This command creates a new folder with all the necessary files for your static site.

Navigate to Your Project Folder:

cd my-static-site

Move into your project's directory to start working on it.

Start the Development Server: Launch the local development server with:

statico dev

Your site is now running locally at http://localhost:3000/, and it reloads by itself when you save a file. Open this URL in your browser to view your site.

Check Your Work: Before you push anything, run:

statico check

This builds the site and tells you about broken links, missing #anchor targets, images without alt text and placeholders you typo'd. Zero errors means you're good.

Build for Production: Once you're satisfied with your site, generate the production-ready files by running:

statico build

This command creates a _site folder containing your optimized static files, ready for deployment.

Congratulations, you're now the proud owner of a static website!

🤔 Why Static Websites Are Actually Awesome

⚡ Speed: Super fast loading times due to optimized static assets.

🔐 Security: Less vulnerable to hacking because, honestly, there's nothing dynamic to hack.

💰 Cost-effective: Hosting is virtually free. For example, GitHub Pages offers free hosting.

🌐 Deploying Your Static Website on GitHub Pages

Let's take advantage of GitHub Pages to host your static site completely for free! Follow these simple steps to deploy your site automatically each time you update your repository.

Step-by-Step Guide for GitHub Pages

Create a GitHub Repository:

Visit GitHub and create a new repository (for example, my-static-site).

Clone it locally, or set your existing project to track this remote.

git init
git add .
git commit -m "Initial commit"
git branch -M main
git remote add origin https://github.com/yourusername/my-static-site.git
git push -u origin main

Replace yourusername and my-static-site with your GitHub username and repo name.

Add GitHub Actions Workflow:

In your repository, you should find new folder .github/workflows and a static.yml.

Note on GitHub Workflow

Back when this ran on Static, the default workflow didn't work for me — some of the actions it used were outdated, and I added a pull request so hopefully someone from DevDojo updates it in their templates.

The current one is shorter, because there's no Node to install. It downloads one binary, checks the site, builds it and deploys:

static.yml

# Simple workflow for deploying static content to GitHub Pages
name: Deploy static content to Pages

on:
  # Runs on pushes targeting the default branch
  push:
    branches: ["main"]

  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

# Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages
permissions:
  contents: read
  pages: write
  id-token: write

# Allow only one concurrent deployment, skipping runs queued between the run in-progress and latest queued.
# However, do NOT cancel in-progress runs as we want to allow these production deployments to complete.
concurrency:
  group: "pages"
  cancel-in-progress: false

env:
  # Pin the generator so a build is reproducible; bump to upgrade.
  STATICO_VERSION: v0.1.0
  SITE_URL: https://adwebdev.xyz

jobs:
  # Single deploy job since we're just deploying
  deploy:
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Setup Pages
        uses: actions/configure-pages@v4

      # Statico fetches standalone Tailwind and esbuild binaries on first use.
      # Caching them keeps every run after the first one offline and fast.
      - name: Cache Statico toolchain
        uses: actions/cache@v4
        with:
          path: ~/.cache/statico
          key: statico-tools-${{ env.STATICO_VERSION }}

      - name: Install Statico
        run: |
          curl -fsSL "https://github.com/adrianodias8/statico/releases/download/${STATICO_VERSION}/statico-x86_64-unknown-linux-musl.tar.gz" \
            | sudo tar xz -C /usr/local/bin statico
          statico --version

      # Fails the build on broken links, missing anchors and unresolved
      # placeholders. Drop this step if you'd rather deploy regardless.
      - name: Check
        run: statico check

      - name: Build
        run: statico build "$SITE_URL"

      - name: Upload artifact
        uses: actions/upload-pages-artifact@v3
        with:
          path: "./_site/"

      - name: Deploy to GitHub Pages
        id: deployment
        uses: actions/deploy-pages@v4

The whole thing takes about 20 seconds, most of which is GitHub spinning up the runner.

Enable GitHub Pages in Your Repository:

Go to your repository's Settings tab.

Select Pages from the sidebar.

Under Build and deployment, set the source to GitHub Actions. GitHub will use your configured workflow.

(Optional) Add a Custom Domain:

To make your website more professional, you can use a custom domain:

Purchase your domain or use one you already own.

Follow the official GitHub documentation to configure your custom domain.

🎉 In Conclusion (or Just Getting Started?)

Remember, simplicity doesn't mean sacrificing style or functionality. Sometimes, stripping things down to basics is exactly what's needed to get moving and for me was how I ended up with my blog running.

Sure, this blog post might just be a test run, but it's my test run. And I'm really happy with it. Though I'll admit "I just want a simple blog" turning into "I wrote my own static site generator" is a very on-brand way for this to have gone.

Stay tuned for more rambling!