DEV Community: Jeremy Nobel

Kron Devlog #2: copy is done — threads, syscalls and a performance problem I haven't solved yet

Jeremy Nobel — Mon, 23 Mar 2026 01:52:19 +0000

Compared to previous commands, copy was relatively straightforward to build. The options — recursive, force, dry-run, verbose, skip-existing, no-overwrite, pattern filtering — all came together without major friction. Testing was clean. No dramatic bugs this time.

The real challenge was the threading model.
The original implementation had a fundamental flaw: threads would exit their loop as soon as the work queue was empty, even if other threads were still discovering new directories to process. In practice, almost everything was running on a single thread. The fix required rethinking the entire approach — instead of threads dying prematurely, they now wait intelligently using condition variables and notifications. They only exit when there's genuinely nothing left to do. A whole new layer of complexity, but the right kind.

The bigger unsolved problem is performance on large directories. Unlike list or inspect, copy can't cache anything — every file operation requires constant syscalls, and syscalls are expensive. The more files, the more it hurts. I have some ideas for specific cases, but I'm not interested in point solutions. I want something more fundamental before I consider the problem addressed.

--preserve is intentionally not implemented yet. Preserving metadata means more syscalls, and adding that on top of an already expensive operation didn't make sense until I find a way to reduce that cost first.

Kron is still being built from the void.
github.com/TheNobelVoid/kron

Kron Devlog #1: A Simple Flag Bug, a New Command, and a Performance Problem

Jeremy Nobel — Sat, 21 Mar 2026 00:57:00 +0000

There's a certain kind of bug that doesn't make you feel stupid because it's complex. It makes you feel stupid precisely because it isn't.
That was my day today.

I'm building Kron — a multifunctional CLI tool for file inspection and manipulation, written in C++20 with zero external dependencies. I'm currently working on a new command: copy. But before I could write a single line of it, I had to deal with the global --version and --help flags first.

The flag bug
The logic was simple: --version and --help need to be handled before any command is dispatched. If someone runs kron --version alone, the program should print the version and exit — not throw an error because no command was provided.

I overcomplicated it at first, trying to figure out the right place to intercept these flags in the pipeline. Eventually I found it: right after options are normalized, before command processing begins. That way the flow gets cut early and nothing downstream runs.

--help was similar, with one extra condition: if a command is provided alongside --help, it should print that command's help and stop execution. Clean, simple.

Then I spent way too long debugging why a command with no options wasn't executing at all. The culprit? A stray else in the dispatch logic that should have been removed. It was blocking execution entirely for commands called without options. Classic.

The copy command
The core data extraction logic in copy is similar to what inspect already uses, which made the foundation straightforward. The standard functionality is all there — recursive copy, force overwrite, skip existing files, preserve metadata, dry run, verbose output.

But I want copy to do something the traditional tool doesn't: filter what gets copied. By extension, by file size, by date, by permissions. So instead of blindly copying everything, you can tell Kron exactly what you want moved and what should stay behind. More control, less cleanup.

The performance problem
list and inspect already use multithreading for data collection, and the filtering logic is as optimized as my current knowledge allows. Both commands handle simple workloads well.

The bottleneck is printing. When dealing with large volumes of data, output slows down noticeably. I haven't solved this yet — but it's on the table. If anyone has dealt with high-volume terminal output in C++ and has ideas, I'm genuinely open to them. Drop a comment or open issue #3 on GitHub.

Hoping to have copy ready before the end of the week.
github.com/TheNobelVoid/kron

Why I Build CLI Tools with Zero External Dependencies

Jeremy Nobel — Fri, 20 Mar 2026 02:56:45 +0000

For a long time I wasn't really programming. My university degree covered a lot of things — but actual building wasn't one of them. Professors mentioned AI, algorithms, low-level concepts. They'd describe what something did, roughly how it worked underneath. But nobody told you the truth: building it isn't just calling a couple of functions and moving on.
There was always something deeper below.

At some point I decided to stop waiting and start digging.
I want to be clear about something: this isn't about dismissing other languages or tools. If I'm working on a company project or something with deadlines and other people depending on it, I'll adapt. I'll use whatever makes sense. But when the project is mine — when nobody is waiting, when the only requirement is that I understand every single line — I build from scratch.

Everything. My own tokenizer. My own CLI parser. My own command executor. Not because libraries don't exist. They do, and some of them are excellent. But because there's a difference between using a tool and understanding what the tool is made of.

I do make one exception: the C++ STL. And honestly, if I followed my own logic all the way down I'd end up punching cards or writing assembly. There's a floor somewhere. The STL is mine.

The real reason I build this way has nothing to do with efficiency or philosophy. It's simpler than that.

Kron — my CLI tool for file inspection and manipulation — made me suffer. It kept me awake. I'd lie down and instead of sleeping I'd be running solutions in my head, thinking about architecture, about what I'd broken, about what I could do better. It gave me something that years of coursework never did: the feeling that I was actually building something.

It brought me back to programming.
Kron is just the beginning.

Do you build from scratch or prefer existing tools? What made you choose your approach?