Why My Weekend C Project Made Me Hate My Day Job (A Gradle vs Meson Rant)

by Ebong Ewane Billy · July 14, 2026

Let’s be honest.

If you build Android apps or write Kotlin for a living, you spend a massive chunk of your life waiting on Gradle.

You wait for syncs. You wrestle with build.gradle.kts files that look more like black magic than code. You debug caching issues that make you want to throw your laptop out the window.

We accept it because “that’s just the JVM life.” (I started hacking on the JVM pretty recently, so I skipped the Maven era entirely. I can’t tell you if it’s better or worse—only that Gradle is my daily bread, and sometimes it tastes like cardboard).

But last weekend, I started building an open-source school timetable generator.

The twist? I decided to write it in C.

And that’s when I met Meson.

The “Aha!” Moment

I expected C build systems to be a nightmare. I was bracing myself for raw Makefiles or complex CMake configurations.

Instead, I used Meson.

And within exactly 5 minutes, my mind was blown.

Look at how dead-simple a basic Meson build file is:

Code snippet

project('timetable-generator', 'c', version: '0.1')
executable('generator', 'main.c', install: true)
Code language: JavaScript (javascript)

No nested blocks of complex DSLs. No endless plugins to apply. No multi-gigabyte daemon sitting in the background eating my RAM.

It just worked. It configured in milliseconds. It compiled instantly.

Compare that to what we deal with in the Kotlin ecosystem.

Why Gradle Feels Like Overkill

Don’t get me wrong. Gradle is incredibly powerful. It handles massive multi-module Android projects with complex dependency graphs.

But it comes with a tax. A massive productivity tax.

1. The Configuration Hang

In Meson, configuring the project takes a fraction of a second. In Gradle, “Configuring projects” is a screen state you stare at for minutes every single day.

2. Readability

Meson uses a clean, non-Turing-complete DSL designed specifically for building software. Gradle uses Groovy or Kotlin DSL. Because it’s a full programming language, build files easily bloat into complex scripts that only the “build engineer” on your team understands.

3. The “Cold Start” Problem

If I haven’t run my C project in hours, Meson and Ninja compile it instantly. If I open an Android project after a few hours away, Gradle needs to warm up, download index files, and sync dependencies all over again.

My Wish for the Kotlin Ecosystem

I love Kotlin. I love building Android apps.

But as developers, we deserve better build UX.

My weekend project made me realize something: we shouldn’t need a PhD in build tools just to compile our code.

I wish we had a “Meson for Kotlin”—a build system that prioritizes:

Extreme Speed: Sub-second configuration times.
Decluttered Configuration: A simple, human-readable configuration format (like TOML or a strict, declarative DSL) with zero scripting allowed.
Lightweight Footprint: No heavy background daemons hogging 4GB of system memory just to run a hello-world app.

Until then, I’ll be begrudgingly sync’ing my Gradle files at work on Monday… and dreaming of my clean, fast C build files on Friday night.

What about you? Have you ever tried a build system outside the JVM that made you question Gradle? Let me know in the comments below!