DEV Community: Ali Amer

Ep2: Working on logger for Nusku

Ali Amer — Tue, 06 Oct 2026 14:21:00 +0000

Since we are using Zig and the available libraries and packages are limited, we need to implement some of the core infrastructure code that we need for this project.

On the first day, we implemented a simple, lightweight CLI framework to help with parsing arguments and interacting with the CLI.

Today, we are starting to work on something new: the logger module. Like any logging library, you write a message along with some named fields. The module renders one line per record as readable text, logfmt, or JSON, with a timestamp and a log level, and writes it to a writer that you provide, such as stderr for a CLI application.

Quick start

In main, create one logger and install it as the default:

const log = @import("log");

var err_buf: [1024]u8 = undefined;
var err = std.Io.File.stderr().writer(init.io, &err_buf);

var logger = log.Logger.init(.{
    .writer = &err.interface,
    .io = init.io,
    .color = log.shouldColor(init.io, std.Io.File.stderr(), init.environ_map.get("NO_COLOR") != null),
});
log.setDefault(&logger);
defer log.clearDefault();

Then log from anywhere:

log.info("server started", .{ .addr = addr, .port = 7000 });

// or give a file or component its own scope name:
const slog = log.scope("agent");
slog.debug("sample taken", .{ .pid = pid, .took_us = elapsed });
slog.err("write failed", .{ .path = path, .cause = error.AccessDenied });

Output:

2026-10-05T08:08:02.803Z INFO  server started addr=0.0.0.0 port=7000
2026-10-05T08:08:02.803Z DEBUG agent: sample taken pid=412 took_us=88
2026-10-05T08:08:02.804Z ERROR agent: write failed path=/x cause=AccessDenied

Output formats

Set with Options.format or at run time with logger.setFormat(...).

.text (default). For people reading a terminal.

2026-10-05T14:03:22.123Z INFO  agent: listening addr=:7000 interval_ms=100

Level is padded to five characters so columns line up. With color = true the level is colored (trace gray, debug cyan, info green, warn yellow, error red), the timestamp and field names are dimmed. Newlines in a message are shown as \n so one record is always one line.

.logfmt. For grep and log tools that understand key=value.

time=2026-10-05T14:03:22.123Z level=info scope=agent msg=listening addr=:7000 interval_ms=100

.json. One object per line, for log pipelines.

{"time":"2026-10-05T14:03:22.123Z","level":"info","scope":"agent","msg":"listening","addr":":7000","interval_ms":100}

Color is only ever applied to .text. The other two never contain escape codes.

Levels

trace < debug < info < warn < err < off

A record is written when its level is at or above the logger's threshold. off as a threshold silences everything. The default threshold is info.

logger.setLevel(.debug);          // any thread, any time
logger.getLevel();
logger.enabled(.trace);           // false at the moment

log.Level.parse("WARNING")        // ?Level: case-insensitive

Level.parse accepts trace, debug, info, warn, warning, error, err, off, none. It is meant for flags and environment variables.

The level check happens before any formatting or locking, so a disabled call costs one atomic load. The field values you pass are still evaluated by the caller, so avoid building expensive values just to log them at debug level.

Fields

The second argument is an anonymous struct. Each field becomes a key and a value, in the order written.

log.info("request", .{ .method = "GET", .status = 200, .took_ms = 12.5, .cached = false });

Supported value types and how they print:

Type	Output
integers, comptime ints	decimal
floats	decimal. In JSON, NaN and infinity become `null`
`bool`	`true` / `false`
`[]const u8`, string literals, `[N]u8`	text. In text and logfmt it is quoted only when needed (empty, or contains a space, `=`, `"`, `\`, or a control character). In JSON it is always quoted and escaped
enums and enum literals	the tag name
error values	the error name, `cause=AccessDenied`
optionals	the value, or `null`
anything else	its `{any}` rendering as a string, cut at 512 bytes

Logging never fails the caller. If the writer errors (a closed pipe, a full disk) the record is dropped silently.

An empty .{} is fine when you have no fields. A struct with positional fields (a tuple like .{ 1, 2 }) is a compile error, since fields need names.

Scopes and bound context

A scope is a name for the part of the program that produced the record. It prints as agent: in text and as scope=agent or "scope":"agent" in the others.

A bound handle carries a scope and fixed fields, so you do not repeat them on every call.

// attached to a specific logger
const req = logger.scope("http").with(.{ .request_id = id });
req.info("handled", .{ .status = 200 });
// -> INFO  http: handled request_id=abc status=200

// chain more fields; earlier ones print first
const user_req = req.with(.{ .user = "ali" });

// same fields, different scope name
user_req.scoped("http.slow").warn("slow", .{ .ms = 1800 });

Handles are small values. Build them on the stack, pass them around, copy them freely. They hold a pointer to the logger and no allocations, so they are only valid while the logger is.

The module-level log.scope(name) and log.with(fields) return handles that are not attached to a logger. They look up the default logger every time you log. That is what allows a file-level constant:

const slog = log.scope("db");   // at file level, before main runs

pub fn query() void {
    slog.debug("running", .{});  // uses whatever default is installed now
}

The default logger

log.setDefault(&logger) installs a process-wide logger. The functions log.info(...), log.debug(...) and so on, and every unattached handle, use it. log.clearDefault() removes it, and log.getDefault() returns ?*Logger.

If no default is installed, these calls do nothing. They do not crash and they do not print. This means anything logged before main calls setDefault is lost, so install it first.

The default is held in an atomic pointer, so installing and reading it is thread safe. The logger itself must stay alive while it is installed. In main, defer log.clearDefault() right after setDefault covers it.

If you prefer no global at all, ignore the module-level functions and pass *Logger or a bound handle explicitly. Nothing else needs the global.

Using it with the cli module

The two modules are independent. The app connects them in a small file, src/logging.zig, which defines the flags and applies them:

pub const flags: []const cli.Flag = &.{
    .{ .name = "verbose", .short = 'v', .kind = .bool, .help = "Same as --log-level=debug" },
    .{ .name = "log-level", .help = "trace, debug, info, warn, error, off", .env = "PCTL_LOG_LEVEL" },
    .{ .name = "log-format", .help = "text, logfmt or json", .env = "PCTL_LOG_FORMAT" },
};

pub fn configure(ctx: *cli.Context) error{InvalidUsage}!void { ... }

The root command lists logging.flags as persistent flags, and each command's run calls try logging.configure(ctx) first. A bad value like --log-level=loud becomes a usage error: exit 2 with a hint.

Two rules keep this tidy:

Share one stderr writer. main passes the same &err.interface to cli.execute and to the logger. If they used separate buffered writers, their output could appear out of order. Because the logger flushes after every record, ordering stays correct.
Logs are not results. Command output goes to ctx.stdout. Logging goes to stderr. So pctl query ... | jq is unaffected by -v or --log-format json. Because cli has no pre-run hook yet, every command calls configure. A persistent_pre_run hook on Command would remove that repetition and is a good next change to cli.

Routing `std.log` into it

Libraries and the standard library log through std.log. To send those records through the same logger, set this in your root source file:

pub const std_options: std.Options = .{ .logFn = log.stdLogFn };

Levels map one to one (err, warn, info, debug). The std.log scope becomes the scope name, and the default scope prints no scope. The message is formatted into a 1 KiB buffer and cut if longer. Since std.log has no structured fields, those records carry only a message.

How it works

Files

File	Responsibility
`root.zig`	Public API and the module-level convenience functions.
`logger.zig`	`Logger`, `Bound`, the default-logger pointer, `shouldColor`. Owns the lock and the clock.
`encode.zig`	Turns one record into bytes in any of the three formats. Pure: it only touches the writer it is given.
`level.zig`	`Level`, names, labels, `parse`.
`time.zig`	UTC timestamp formatting with no allocation.

What happens on a call

emit compares the level against the atomic threshold and returns if disabled.
It takes the logger's mutex (std.Io.Mutex). This is why two threads can never mix their records.
It reads the clock (std.Io.Clock.real, or now_fn if you set one) and formats the timestamp.
encode.writeRecord writes the whole line straight into the writer. There is no intermediate buffer and no allocation, so there is no length limit on a record.
It flushes the writer if flush is on (the default), then unlocks. How fields are encoded without allocating. Fields are an anonymous struct, so their names and types are known at compile time. writeFields walks them with inline for, and each value is handled by a switch on its type, resolved at compile time. Nothing is boxed or stored.

Fixed fields on a bound handle are joined to per-call fields with a small generic type, Pair(A, B), which just holds both. writeFields recognizes it and writes a then b. Chaining .with nests pairs, and the order stays first-bound first.

Settings that change at run time. The level is an atomic value. Format and color are read under the mutex, so setFormat and setColor lock it too. All three are safe to call while other threads are logging.

Limits and known gaps

No file output, rotation, or network sinks. It writes to one writer. For a CLI that is stderr, and a service can redirect that to a file or a collector.
One output per logger. To write text to the terminal and JSON to a file, you would create two loggers.
Field values are evaluated by the caller. A disabled level skips formatting but not the work of building the arguments.
Fields only on the structured API. std.log records have a message and a scope but no fields.
Records before setDefault are dropped. There is no buffering of early logs.
The lock is held while writing. A slow writer blocks other threads that log. For stderr that is normally fine. If it becomes a problem, put a buffered writer in front.
No sampling or rate limiting, and no compile-time level floor to strip debug calls from release builds.
Errors are logged by name. The error name is printed, with no error return trace.

https://nuskum.github.io/nusku/

Ep1: Setting Up The Project

Ali Amer — Mon, 05 Oct 2026 11:24:37 +0000

This is first task, we should do is building the infrastructure for the tool and the most important one is Cli

The cli module

A small command-line framework for Zig 0.16, modeled on Go's cobra. You describe your commands as a tree of constant structs. The module parses argv, picks the right command, fills in flag values, prints help, and turns errors into the right stream and exit code.

What it does

For an app with many commands and subcommands, it handles the parts that are the same every time:

Resolving nusku agent start --listen :7000 to the start command under agent.
Parsing flags: --flag value, --flag=value, -f value, -fvalue, bool clusters like -abc, --no-flag, and -- to end flag parsing.
Flag values from three places, in this order: command line, environment variable, default.
Checking types (int, bool), required flags, and the number of positional arguments, before your code runs.
Generating --help for every command from the tree.
Keeping Unix stream rules: results on stdout, errors and progress on stderr, and meaningful exit codes. Your command code only has to do its job and return.

Quick start

build.zig: register the module and give it to the app.

const cli_mod = b.addModule("cli", .{
    .root_source_file = b.path("cli/root.zig"),
    .target = target,
    .optimize = optimize,
});

// Nusku commands
const commands_mod = b.addModule("commands", .{
    .root_source_file = b.path("src/cmd/root.zig"),
    .target = target,
    .optimize = optimize,
    .imports = &.{
        .{
            .name = "cli",
            .module = cli_mod,
        },
    },
});

const exe = b.addExecutable(.{
    .name = "nusku",
    .root_module = b.createModule(.{
    .root_source_file = b.path("src/main.zig"),
    .target = target,
    .optimize = optimize,
    .imports = &.{
        .{ .name = "commands", .module = commands_mod },
        .{ .name = "cli", .module = cli_mod },
        },
    }),
});

File map

File	Responsibility
`root.zig`	Public API. Re-exports the types and functions you use, and pulls in every file's tests.
`command.zig`	Plain data types: `Command`, `Flag`, `ArgsRule`, `FlagValues`, `Context`. No parsing logic.
`parser.zig`	Turns `argv` into a `Parsed` result or a parse error with a message. Never prints.
`help.zig`	Renders help text and the usage hint. Pure functions over the tree.
`errors.zig`	The two special error names and the exit code constants.
`execute.zig`	The entry point. Runs the parser, dispatches to `run`, maps outcomes to streams and exit codes.

The data model

Everything in command.zig is plain data. Commands are const values linked with pointers, so a whole tree can sit in static memory with no allocation.

`Command`

Field	Meaning
`name`	The word the user types.
`aliases`	Other words that select the same command (`ls` for `list`).
`short`	One line, shown in the parent's command list.
`long`	Longer text shown at the top of this command's own help. Falls back to `short`.
`usage_args`	Positional synopsis for the usage line, like `<file>...`. Display only.
`flags`	Local flags. Visible only on this command.
`persistent_flags`	Visible on this command and all its descendants.
`subcommands`	`[]const *const Command`.
`args`	Rule for the number of positional arguments (see below).
`hidden`	Left out of the parent's command list. Still runnable.
`run`	`?RunFn`. Null makes it a grouping command that prints help when invoked.

`Flag`

Field	Meaning
`name`	Long name without dashes. `verbose` is `--verbose`.
`short`	Optional one-character alias, like `'v'`.
`kind`	`.bool`, `.string`, or `.int`. Default `.string`.
`help`	One line for the help output.
`default`	Text default. If null: `false`, empty string, or `0` depending on `kind`.
`env`	Environment variable to read when the flag is not on the command line.
`required`	Usage error if neither the command line nor the env supplies it.

Defaults are written as text ("50", ":7000") because they go through the same validation as user input.

`ArgsRule`

Controls how many positional arguments are allowed.

.args = .any                                  // no check (default)
.args = .none                                 // exactly zero
.args = .{ .exact = 1 }
.args = .{ .min = 1 }
.args = .{ .max = 2 }
.args = .{ .range = .{ .min = 1, .max = 3 } }

`FlagValues`

The result of flag resolution. It maps each flag name to an Entry:

Entry = struct { value: []const u8, source: ValueSource }   // source: .default, .env, .cli

Every flag visible to the chosen command gets an entry, with its default filled in. That is why the getters never return null:

ctx.getBool("verbose")
ctx.getString("format")
ctx.getInt("limit")
ctx.isSet("limit")      // true if the user supplied it by CLI or env, false for the default

Asking for a flag name that is not defined for the command is a programmer error and panics with a clear message.

`Context`

What run receives.

Field	Meaning
`allocator`	An arena that lives for this one invocation. Do not free what you allocate from it.
`prog`	Name of the root command.
`stdout`	`*std.Io.Writer`. Results only.
`stderr`	`*std.Io.Writer`. Diagnostics, progress, warnings.
`command`	The command being run.
`args`	Positional arguments, with command names and flags already removed.
`flags`	The resolved `FlagValues`.

Plus the helper methods getBool, getString, getInt, isSet, fail, and usageFail.

How parsing works

parser.parse(arena, root, argv, opts, &diag) makes one pass over the tokens, then finishes with a short validation step.

The pass

The parser keeps a stack called path, which starts as [root]. The last item is the current command. For each token:

token
 |
 |- after "--"  ........................ positional
 |- does not start with "-" (or is just "-") ...
 |      |- no positional seen yet and current command has a subcommand with this name
 |      |        -> push that subcommand onto path
 |      |- no positional yet, current command has subcommands but no `run`
 |      |        -> error UnknownCommand
 |      '- otherwise -> positional
 |- exactly "--"  ...................... switch to "everything is positional"
 |- starts with "--"  .................. long flag
 '- starts with "-"  ................... short flag(s)

The key point is that flags are looked up against whichever command is current at that moment. This gives cobra's behavior:

nusku --verbose query -n5 x      ok: verbose is persistent on the root
nusku query -v -n5 x             ok: same flag, after the subcommand
nusku --limit 5 query x          error: limit belongs to query, which is not current yet

Which flags are visible

When looking up a flag name, the parser checks:

Local flags of the current command.
persistent_flags of the current command and each ancestor, walking up to the root. Local flags of ancestors are not visible. If a local flag and a persistent flag share a name, the local one wins on lookup.

Long flags

--name=value, --name value, --name (bool). For a bool flag, --name value does not take value; the bool is set and value is parsed as the next token. --no-name sets a bool flag to false. --help is recognized if you did not define your own help flag.

Short flags

The token body is scanned left to right:

A bool flag is set and the scan continues, so -abc sets three flags.
A flag that takes a value ends the cluster. The value is the rest of the token (-n5), the part after = (-n=5), or the next token (-n 5).
h is treated as help if no flag claimed it. When a flag takes a value from the next token, that token is used as is, even if it starts with -. So --limit -1 gives the value -1.

Validation at set time

Each value is checked when it is stored. Ints must parse with std.fmt.parseInt(i64, v, 0), so 0x10 and 1_000 style input follows Zig's rules. Bools must be exactly true or false. A bad value is a parse error, so your run never sees it.

After the pass

If help was requested, the parser returns right away with help_requested = true and skips everything below. This is why nusku query --help works even though --service is required.

Otherwise, for every flag visible to the final command that was not set on the command line:

If the flag has env and the lookup returns a value, use it (source .env).
Else if the flag is required, fail with MissingRequiredFlag.
Else store the default (source .default). Finally the positional count is checked against the command's ArgsRule.

So the precedence is command line, then environment, then default. A required flag can be satisfied by the command line or the environment, but a default never satisfies it.

Result and errors

On success, Parsed holds the chosen command, the full path (root to command), args, flags, and help_requested.

On failure, parse returns one of these errors and fills a Diagnostic with a message, the failing command, and its path:

Error	Example message
`UnknownCommand`	`unknown command "lst" for "nusku"`
`UnknownFlag`	`unknown flag: --bogus`
`MissingValue`	`flag needs a value: --limit`
`InvalidValue`	`invalid value "abc" for --limit: expected an integer`
`MissingRequiredFlag`	`required flag not set: --service`
`InvalidArgCount`	`get: expects exactly 1 argument(s), got 0`
`OutOfMemory`	none

The parser never prints. The caller decides how to show the message, which keeps it testable and reusable.

Environment lookup

The parser does not read the process environment itself. It takes an EnvLookup, a small struct with a context pointer and a function. In a 0.16 main, cli.EnvLookup.fromMap(init.environ_map) builds one. In tests you pass a fake. Passing null turns env fallback off.

How help is rendered

help.zig renders from the tree and writes to any *std.Io.Writer. It does no allocation.

Sample output for nusku query --help:

Query stored profiles

Usage:
  nusku query [flags] <expression>

Aliases:
  query, q

Flags:
  -h, --help             Show help for this command
  -s, --service string   Service to query [env: NUSKU_SERVICE] (required)
  -n, --limit int        Max rows (default 5)
  -f, --format string    table or json (default "table")
      --reverse          Oldest first

Global Flags:
  -v, --verbose         Print progress to stderr
  -c, --config string   Config file (default "/etc/nusku.toml") [env: NUSKU_CONFIG]

How it is built:

Intro: long, or short if there is no long.
Usage: one line if the command has a run, another with [command] if it has visible subcommands.
Aliases: shown for non-root commands that have any.
Commands: visible subcommands, names padded to the longest one.
Flags: the command's own flags plus its own persistent_flags. An automatic -h, --help line is added unless you defined a help flag.
Global Flags: persistent flags inherited from ancestors.
Footer: a pointer to nusku [command] --help when there are subcommands. Column alignment needs the widest flag label before anything is printed, and there is no allocation to collect the labels into. So each section is walked twice with a small visitor: the first pass measures, the second pass prints with that width. This is why the same traversal function serves both.

writeUsageHint prints the shorter line used after errors: Run 'nusku query --help' for usage.

How `execute` ties it together

cli.execute(&root, argv, opts) returns the exit code. It never calls exit itself, so tests can call it and check the result.

Steps:

Make an arena from opts.allocator. It is freed when execute returns.
If opts.version is set and argv is exactly ["--version"], print nusku 0.1.0 to stdout and return 0.
Call the parser.
- On a parse error, write nusku: <message> and the usage hint to stderr, and return 2.
- On out of memory, write a short message and return 1.
If help was requested, or the chosen command has no run, print its help to stdout and return 0.
Build a Context and call run.
Map what run returns (next section).
Flush both writers. ## Streams and exit codes

Situation	Stream	Exit
Normal result	stdout	0
`--help`, `--version`, or a grouping command with nothing to run	stdout	0
Parse error: unknown command or flag, bad value, missing required flag, wrong argument count	stderr	2
`ctx.usageFail(...)` from a command	stderr	2
`ctx.fail(...)` from a command	stderr	1
Any other error returned from `run`	stderr, as `nusku: error: <ErrorName>`	1
`error.WriteFailed` from a writer (for example `nusku ... \	head -1`)	nothing

Two details worth knowing:

Ordering. Before writing a diagnostic to stderr, execute flushes stdout. On a terminal this keeps the two streams in the order things happened.
Broken pipes. When the reader of a pipe exits early, writes fail with WriteFailed. execute exits quietly instead of printing an error about it. ### The special error names

In errors.zig:

error.Reported: the message is already printed. Returned by ctx.fail.
error.InvalidUsage: bad input. Returned by ctx.usageFail. execute adds the help hint and exits 2. Exit codes are constants: exit_success = 0, exit_failure = 1, exit_usage = 2.

Writing a command

One file per command keeps a large tree manageable. Each file exports its Command as a pub const, and the parent points at it.

// src/commands/query.zig
const std = @import("std");
const cli = @import("cli");

pub const cmd: cli.Command = .{
    .name = "query",
    .aliases = &.{"q"},
    .short = "Query stored profiles",
    .usage_args = "<expression>",
    .flags = &.{
        .{ .name = "service", .short = 's', .required = true, .env = "NUSKU_SERVICE" },
        .{ .name = "limit", .short = 'n', .kind = .int, .default = "5" },
        .{ .name = "format", .short = 'f', .default = "table" },
    },
    .args = .{ .exact = 1 },
    .run = run,
};

fn run(ctx: *cli.Context) anyerror!void {
    const expr = ctx.args[0];

    // input the parser cannot judge: exit 2 with a hint
    const format = ctx.getString("format");
    if (!std.mem.eql(u8, format, "table") and !std.mem.eql(u8, format, "json")) {
        return ctx.usageFail("unknown --format \"{s}\"", .{format});
    }

    // progress goes to stderr
    if (ctx.getBool("verbose")) try ctx.stderr.print("querying {s}\n", .{expr});

    // the result goes to stdout
    try ctx.stdout.print("{s}\n", .{expr});

    // an operation that failed: message plus exit 1
    // return ctx.fail("cannot open {s}", .{path});
}

Parent:

const query = @import("commands/query.zig");

const root: cli.Command = .{
    .name = "nusku",
    .subcommands = &.{ &query.cmd },
};

Rules of thumb:

Never write to the process streams directly. Use ctx.stdout and ctx.stderr. This is what makes piping correct and what lets tests capture output.
Use usageFail when the user's input is wrong, fail when the input was fine and the work failed.
Put flags that apply to many commands in persistent_flags on a common ancestor. ### Grouping commands

A command with subcommands and no run is a group. Invoking it prints its help and exits 0. A command with both run and subcommands is allowed: an unrecognized first word becomes a positional argument instead of an unknown-command error.

Memory and lifetimes

execute creates one arena per call and frees it at the end. ctx.allocator is that arena, so commands can allocate freely and never free.
parser.parse allocates from the arena you give it. The returned Parsed points into that arena and into argv, so both must outlive it. Inside execute this is already the case.
Flag values are slices of the original argv strings, not copies.
The command tree itself allocates nothing. It is const data. ## Testing

The module has 17 tests across four files. Run them with zig build test, or zig test src/cli/root.zig.

parser.zig: subcommand and alias resolution, flag forms, clusters, negation, --, env precedence, every error, required flags, arg count rules, help skipping validation.
help.zig: exact text of root help, subcommand help, and the usage hint.
execute.zig: for each outcome, checks stdout, stderr, and the exit code together. To test your own commands, call execute with in-memory writers:

var out: std.Io.Writer.Allocating = .init(std.testing.allocator);
defer out.deinit();
var err: std.Io.Writer.Allocating = .init(std.testing.allocator);
defer err.deinit();

const code = cli.execute(&root, &.{ "query", "-s", "api", "x" }, .{
    .allocator = std.testing.allocator,
    .stdout = &out.writer,
    .stderr = &err.writer,
});

try std.testing.expectEqual(@as(u8, 0), code);
try std.testing.expectEqualStrings("x\n", out.written());
try std.testing.expectEqualStrings("", err.written());

Limits and known gaps

--version only works as the only argument (nusku --version). It is not a real flag, so nusku query --version is an unknown flag.
Tokens like -5 are treated as flags. To pass a negative number as a positional, put it after --. As the value of a flag it works: --limit -5.
Shadowed flags. If a command defines a local flag with the same name as an ancestor's persistent flag, lookup picks the local one, but both would share one key in FlagValues. There is no check at tree-build time yet.
Flag access is by string. A misspelled name in ctx.getInt("limt") panics at run time. The planned fix is typed flags derived from a struct with comptime reflection, so the compiler catches it.
No color handling yet, because nothing prints color. When something does, honor NO_COLOR and check for a terminal.
No shell completion yet. The tree has what a generator needs (names, aliases, flags, kinds).
No "did you mean" suggestions for mistyped commands. Planned next: typed flags via comptime reflection, then shell completion for bash, zsh, and fish.

main returns the exit code as a u8. Zig's start code passes it to the OS.

codebase: https://github.com/nuskum/nusku

Ep0: Starting Nusku, a continuous profiler for Linux, built in Zig, no shortcuts

Ali Amer — Sun, 04 Oct 2026 20:54:59 +0000

I've always wanted to see the complete performance picture before pushing any code or building something. Not after it's slow in production, not after a user complains about it, before. Click a button, run a command, trigger a request, and actually see what that cost instead of guessing.

That itch has been sitting with me for years. Back in university, I took a course on application performance, and every single homework was the same loop: profile a feature, find what's slow, fix it, measure again, confirm it's actually better. We did it in C# with Visual Studio's live profiler, watching CPU and memory update in real time while clicking through an app. That loop never left me. A few years later I was using NetBird before it had anything close to a performance or observability story, and I kept thinking about the same gap from a completely different angle: infrastructure.

So I'm building Nusku. A continuous profiling system for Linux, written in Zig, with eBPF doing the actual watching.

What it does

Point Nusku at a running process, or launch one through it, and watch what it's actually doing while you use it. CPU time per function, live. Memory as it's allocated, not just a number that goes up, but what called for it and where. Threads that look idle but are actually stuck waiting on a lock, a disk read, or another process, and for how long. Syscalls that quietly eat milliseconds a normal CPU graph never shows you. Network calls that are slow because packets are getting retransmitted, not because the code is doing anything wrong.

It runs locally with nothing to configure, you point it at a process and watch. It can also run on a remote machine and stream that same live picture back over a secure connection, so a server can be watched the same way as something running on your own laptop.

Why eBPF, and why Zig

Every serious Linux profiling tool, Parca, Pyroscope, Cilium, Datadog's continuous profiler, is built on eBPF, not on polling files in /proc and hoping for the best. eBPF is the only way to get real kernel-level visibility into what a process is doing, without injecting anything into it and without the overhead of a userspace polling loop. So that's the foundation, not an add-on bolted on later.

Zig is the other half of the decision, and it's as much about the learning as the result. No garbage collector getting in the way of measuring performance accurately. Full control over memory and allocation, which matters a lot when the entire point of the tool is measuring memory and allocation in something else. And honestly, it's just the language I want to get good at.

The big picture

Nusku splits into a few pieces, each with one job, built and released one at a time:

Agent: sits next to a process and does the actual watching through eBPF. Being built first, because nothing else matters if the data it collects isn't accurate.
Controller: the thing you'd actually talk to once there's more than one process to watch, or watching needs to happen from somewhere else. Lists what's running, lets you pick a target, manages sessions. ...and others will decide later.

Each piece has to fully work before the next one starts. Right now, that means the Agent and nothing else.

What I want to end up with

Honestly, depth first. This is me practicing Zig and systems programming for real, no AI-generated slop, no shortcuts, just me, textbooks, and the Linux kernel docs. There's no deadline attached to any of this and no plan to monetize it right now. If it ends up being something other people actually find useful along the way, that's a genuine bonus, not the goal I'm optimizing for.

What I do want is to end up with a tool that actually answers the question that's been sitting with me since that performance course: not "is my app slow," but "show me exactly why, right now, while it's happening."

I'm documenting the real, unpolished progress in a dev log as I build it. If watching a profiler get built from scratch in Zig and eBPF, warts and all, sounds interesting, I'd genuinely like the company.

#DAY1: The story of unemployment peak for a software engineer

Ali Amer — Sun, 31 May 2026 09:19:11 +0000

𝗗𝗮𝘆 𝟭 𝗼𝗳 𝗨𝗻𝗲𝗺𝗽𝗹𝗼𝘆𝗺𝗲𝗻𝘁 𝗣𝗲𝗮𝗸

I've been thinking what can I actually build that I 𝗿𝗲𝗮𝗹𝘆 𝗲𝗻𝗷𝗼𝘆 𝗺𝗮𝗸𝗶𝗻𝗴?

I love Go. I love microservices. I really need a project to hone my skills and grow since I am unemployed and it is not easy to get a job that I would love and level up.

I came up with a project – Wardu – Kubernetes native scheduler which allows running workers as containers in any language you like.

𝗧𝗵𝗲 𝗶𝗱𝗲𝗮 𝗶𝘀 𝘀𝗶𝗺𝗽𝗹𝗲: if you run microservices then you have workers implemented in different languages. Python for ML tasks, Go for core services, Node.js for notifications. But all existing schedulers require using their SDKs which makes you write Python/Go workers in second class.

𝘀𝗼𝗹𝗲 𝗽𝗿𝗲𝗰𝗿𝗶𝘁𝗶𝗼𝗻: 𝗮𝗰𝗰𝗲𝗽𝘁 𝗮 𝗝𝗦𝗢𝗡 𝗽𝗮𝘆𝗹𝗼𝗮𝗱, 𝗿𝗲𝘁𝘂𝗿𝗻 𝗿𝗲𝘀𝘂𝗹𝘁𝘀. 𝗛𝗧𝗧𝗣 𝗼𝗿 𝗴𝗥𝗣𝗖. 𝗔𝗻𝘆 𝗹𝗮𝗻𝗴𝘂𝗮𝗴𝗲. 𝗔𝗻𝘆 𝗰𝗼𝗻𝘁𝗮𝗶𝗻𝗲𝗿.

Today I have prepared project structure, API Gateway, Docker configuration, Kubernetes manifests and started working on Tilt setup to test locally.

Will this project be useful to anyone? Honestly I don't know yet.

𝘉𝘶𝘵 𝘐'𝘮 𝘵𝘪𝘳𝘦𝘥 𝘰𝘧 𝘴𝘱𝘦𝘯𝘥𝘪𝘯𝘨 𝘩𝘰𝘶𝘳𝘴 𝘢𝘱𝘱𝘭𝘺𝘪𝘯𝘨 𝘵𝘰 𝘫𝘰𝘣𝘴 𝘢𝘯𝘥 𝘩𝘦𝘢𝘳𝘪𝘯𝘨 𝘯𝘰𝘵𝘩𝘪𝘯𝘨 𝘣𝘢𝘤𝘬. 𝘈𝘵 𝘭𝘦𝘢𝘴𝘵 𝘵𝘩𝘪𝘴 𝘸𝘢𝘺 𝘐'𝘮 𝘣𝘶𝘪𝘭𝘥𝘪𝘯𝘨 𝘴𝘰𝘮𝘦𝘵𝘩𝘪𝘯𝘨 𝘳𝘦𝘢𝘭.

The story of unemployment peak for a software engineer

Ali Amer — Tue, 26 May 2026 11:07:48 +0000

𝗜'𝘃𝗲 𝗯𝗲𝗲𝗻 𝘂𝗻𝗲𝗺𝗽𝗹𝗼𝘆𝗲𝗱 𝗳𝗼𝗿 𝗮𝗹𝗺𝗼𝘀𝘁 𝗮 𝘆𝗲𝗮𝗿.

Back in 2020, I wrote down my dream job: work remotely on a well-known open source project. I built toward it : freelance contracts, internships, real experience. I felt like I was on track.

Then the AI boom hit. Freelance dried up. Jobs disappeared.

I did what every unemployed engineer does: built SaaS products. Three of them. All failed. Built a mobile app. Also failed.

So I changed direction entirely. I made a list of Go open source projects and started contributing like I was employed by them. Got ghosted. PRs ignored. But eventually found one project where things clicked.

My PRs got merged. The feedback was great. The CTO offered me a contract to implement bidirectional gRPC streaming for remote debugging and integrated with the UI

Three months of hard work. It shipped to production.

Then the contract ended. And I was unemployed again.

That was almost a year ago.

AI keeps getting better. Being "just" a full-stack Go engineer doesn't feel like enough anymore. And I can't level up the normal way through work because I don't have work.

So here's my plan:

I bought 7 DevOps and platform engineering courses. I'm going to study all of them and build one real, useful project from scratch "𝗻𝗼 𝗔𝗜 𝘄𝗿𝗶𝘁𝗶𝗻𝗴 𝗺𝘆 𝗰𝗼𝗱𝗲, 𝗻𝗼 𝗰𝗹𝗼𝗻𝗲𝘀, 𝗻𝗼 𝘁𝗼𝘆 𝗮𝗽𝗽𝘀".

I'll document everything. The learning. The building. The failures.

𝘞𝘪𝘭𝘭 𝘪𝘵 𝘮𝘢𝘬𝘦 𝘮𝘦 𝘮𝘰𝘯𝘦𝘺? 𝗣𝗿𝗼𝗯𝗮𝗯𝗹𝘆 𝗻𝗼𝘁.
𝘞𝘪𝘭𝘭 𝘪𝘵 𝘨𝘦𝘵 𝘮𝘦 𝘢 𝘫𝘰𝘣? 𝗠𝗮𝘆𝗯𝗲.

I'm doing it anyway. Because I love this. And because I refuse to give up.

Stop maintaining two files that describe the same API

Ali Amer — Sat, 18 Apr 2026 09:26:22 +0000

Show of hands: how many of you have an OpenAPI spec and a separate test collection that slowly drifted apart?

I'll wait.

Yeah. I've been there too. For a long time. And I finally got annoyed enough to build something about it.

The problem in one sentence

Your OpenAPI spec and your API tests describe the same thing, so they should be the same file.

What I built

VolcAPI — a Go CLI that makes your OpenAPI spec executable. You define test scenarios directly inside the spec using a v-functional-test extension, then run them from the terminal.

# Inside your openapi.yml
paths:
  /users:
    post:
      summary: Create user
      v-functional-test:
        scenarios: ["create_valid_user", "duplicate_email"]

scenarios:
  create_valid_user:
    headers:
      Content-Type: application/json
    request:
      name: Alice
      email: alice@example.com
    response:
      status: 201
      body:
        contains: ["id", "email"]

  duplicate_email:
    request:
      name: Alice
      email: existing@example.com
    response:
      status: 409

Then:

volcapi run volcapi_local.yml -o openapi.yml

Done. Both your documentation and your tests updated in one place.

Environment configs

Point at different hosts without changing your spec:

# volcapi_local.yml
host: http://localhost:3000
env:
  API_TOKEN: dev_token_here

# volcapi_staging.yml  
host: https://staging.api.myapp.com
env:
  API_TOKEN: ${STAGING_TOKEN}

Why Go?

Single static binary. No node_modules. No Python virtualenv. Downloads in seconds, runs in CI with zero setup. Same reason K6 took off for performance testing.

Where it's at

Early alpha. This is what works today:

✅ OpenAPI 3.x parsing
✅ GET / POST / PUT / DELETE
✅ Response status + JSON body validation
✅ Environment variable substitution
🔨 JUnit XML output (for CI integration) — in progress
🔨 GitHub Actions example — in progress ## The bigger picture

Dredd used to own this space (OpenAPI-native API testing). It's been mostly unmaintained for years. Most of what replaced it is JavaScript-heavy or requires a cloud service. There's a real gap for a fast, Go-native, CI-first OpenAPI test runner. That's what I'm building.

Repo: https://github.com/aliamerj/volcapi

If this solves a problem you've felt — even a star helps me know the direction is right. And if you have opinions about the "spec as test suite" model (for or against), drop them in the comments. I'm still thinking through the design.

Built in Go. MIT licensed. v0.1.0-alpha.

Why does performance debugging still suck so much?

Ali Amer — Wed, 08 Apr 2026 20:40:18 +0000

Recently I got laid off.

Weirdly, I didn’t feel stressed. I actually felt… excited.

For a long time I’ve wanted to build something meaningful in open source, but work always got in the way. Suddenly I had the time to try.

So I asked myself a question:

Why does performance debugging on Linux still suck?

I remember a moment back in college that stuck with me.

One semester we had to build a project using .NET on Windows.

It was the first time I had to seriously use Windows for development.

Honestly, I never liked .NET very much.

But there was one thing I really liked: Visual Studio.

When you run an application in the debugger, Visual Studio shows you live metrics:

CPU usage
memory usage
allocations
performance spikes

And the coolest part was watching what happened when you interacted with the app.

You could click a button in the UI and instantly see:

CPU usage spike
memory allocations change
performance graphs jump

That made performance debugging feel visual and intuitive.

You could literally see:

“I clicked this button… and something expensive just happened.”

Then you start digging:

Which function caused the spike?
Why did memory jump here?
What part of the code is slow?

It turned performance optimization into a kind of investigation.

And I loved that experience.

But there was a problem

Years later, working mostly on Linux systems, I realized something strange.

We have powerful tools:

perf
bpftrace
flamegraphs
eBPF

But none of them feel as simple and immediate as that Visual Studio experience.

Most tools are:

hard to set up
hard to understand
designed for experts

So I decided to build one.

The idea

I’m building a tool called Nusku.

The goal is simple:

A fast, modern performance profiler built with Rust + eBPF.

It should:

run instantly
require almost no setup
work on production systems
show useful information immediately

No complicated configuration.

No massive dashboards.

Just run it and see where your CPU time is going.

What I’ve built so far

So far Nusku can:

Attach to a running process
Sample CPU usage using eBPF perf events
Capture user-space stack traces
Symbolize addresses into real function names
Aggregate hot functions in real time
Show CPU usage and memory usage in a live terminal view

Example output:

── PID 132612 ── 98 samples ── CPU  99.0% ── RSS 2.0 MiB ── VIRT 3.1 MiB ──
     %     COUNT  FUNCTION                          SOURCE                           ADDRESS
────────────────────────────────────────────────────────────────────────────────────────────────
 27.6%        27  <core::ops::range::Range<T> as …  range.rs:773          0x00005efa8cfd4b95
 11.2%        11  testing::hot_c                    main.rs:7             0x00005efa8cfd4cc7
 10.2%        10  <i32 as core::iter::range::Step…  range.rs:197          0x00005efa8cfd4acd
 10.2%        10  <core::ops::range::Range<T> as …  range.rs:775          0x00005efa8cfd4b9f
  9.2%         9  testing::hot_c                    main.rs:8             0x00005efa8cfd4cf0
  6.1%         6  <core::ops::range::Range<T> as …  range.rs:771          0x00005efa8cfd4b69
  5.1%         5  <i32 as core::iter::range::Step…  range.rs:198          0x00005efa8cfd4b0b
  4.1%         4  core::hint::black_box             hint.rs:482           0x00005efa8cfd4d5a
  4.1%         4  core::iter::range::<impl core::…  range.rs:856          0x00005efa8cfd4b40
  3.1%         3  <core::ops::range::Range<T> as …  range.rs:776          0x00005efa8cfd4bba
  2.0%         2  <core::ops::range::Range<T> as …  range.rs:772          0x00005efa8cfd4b7a
  2.0%         2  <core::ops::range::Range<T> as …  range.rs:780          0x00005efa8cfd4bce
  2.0%         2  testing::hot_c                    main.rs:9             0x00005efa8cfd4d09
  2.0%         2  <i32 as core::iter::range::Step…  range.rs:195          0x00005efa8cfd4ac4
  1.0%         1  core::hint::black_box             hint.rs:483           0x00005efa8cfd4d64

Top frame:
  <core::ops::range::Range<T> as core::iter::range::RangeIteratorImpl>::spec_next
  /home/ali/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/iter/range.rs
  line 773

Everything runs in real time.

Under the hood it uses:

Rust
libbpf-rs
eBPF stack sampling
Blazesym for symbolization

What’s next

Right now the output is pretty basic.

Next steps include:

building a proper terminal UI (Ratatui)
improving symbol aggregation
better stack analysis
eventually generating flamegraphs

The long-term vision is a tool that feels as simple as:

run with pid:

nusku --pid 1234

run binary:

nusku ./my-app

run with commend:

nusku -c node app.js

and immediately shows you where your program is spending CPU time.

Follow the project

I’ll be posting updates as I build this.

If you're interested in:

Rust
eBPF
performance debugging

follow along.

GitHub repo:
https://github.com/aliamerj/nusku

And if you have ideas or feedback, I’d love to hear it.

The Hidden Superpower of AI: How Smart Data Retrieval Is Revolutionizing Everyday Life

Ali Amer — Mon, 19 May 2025 10:40:29 +0000

A Day in the Life of “Invisible AI”
Imagine waking up and asking your smart assistant for:

“What’s my most urgent email? And remind me to follow up on that proposal if I haven’t heard back by Friday.”

Your AI not only scans your inbox, it understands which messages matter most and taps into your calendar, too. No more frantic searches for a lost attachment or digging through threads—you get answers instantly.

That’s the magic of AI‑powered retrieval, quietly hustling behind the scenes in apps you use every day.

Why We Need Better Search—Again
Keyword search felt revolutionary in the 2000s: type a phrase, get a list of links. But today, our data looks nothing like a neatly indexed webpage:

Voice notes from last week’s brainstorming session
PDFs with handwritten meeting minutes
PowerPoint decks shared in chat groups
Traditional search can’t connect the dots between “budget forecast” in a spreadsheet and that off‑hand mention in your voice memo. AI retrieval changes the game by understanding meaning, not just matching words.

5 Surprising Ways AI Retrieval Helps You Right Now
Smarter Personal Assistants

Your AI can pull relevant documents, chats, and even images to answer complex questions:
“Show me the contract version we signed last quarter and summarize its key dates.”
Instant Knowledge Base for Teams

No more “check our internal wiki”—AI bots can fetch and summarize policies, technical docs, or HR guidelines in natural language.
Contextual Shopping Recommendations

e‑commerce sites use retrieval to suggest products based on past purchases, reviews, and even your browsing behavior, all blended seamlessly.
Legal & Medical Research Made Simple

Lawyers and doctors can ask AI to surface past cases or similar clinical studies, saving hours of manual literature review.
Home Automation with a Brain

Ask your smart home:
“Which lights were on last night between 10 PM and midnight?”
and get a precise timeline without sifting through logs.
The Flip Side: When Search Breaks
Ever typed in a query and felt like your data was speaking a different language? That’s because:

Synonyms and slang confuse keyword search.
Unstructured formats (images, audio) aren’t easily indexed.
Volume & velocity overwhelm simple databases.
AI retrieval solves these by converting everything into “embeddings”—compact numerical fingerprints that capture meaning. Suddenly, “sales report Q1” and “Q1 numbers” live in the same semantic neighborhood.

Your Next Step with AI Retrieval
Curious to see how this works under the hood? Platforms like Dcup (open‑source RAG‑as‑a‑Service) let you:

Connect all your data sources in minutes.
Automatically chunk and embed documents, audio, and more.
Deploy a smart search API that speaks natural language.
Whether you’re building the next-gen digital assistant or just want your team to stop chasing files, AI‑powered retrieval is the secret sauce. Give it a spin—and transform chaos into clarity.

Want to experience invisible AI retrieval for yourself?
Head over to dcup.dev and start your free self‑hosted trial today! 🚀

Building Dcup: An Open-Source RAG Pipeline with a Twist

Ali Amer — Sun, 04 May 2025 11:57:05 +0000

Ever wrestled with a RAG pipeline and thought, “Why is this so damn hard?” We’ve been there—tearing our hair out over complexity and slow performance. So, I built Dcup, an open-source, self-hostable RAG-as-a-Service platform that actually works Very good.

What’s Dcup All About?

It’s a tool to hook your app up to user data with zero bullshit. Here’s the rundown:

Tech Stack: Next.js, BullMQ for job queues, OpenAI for embeddings, and Qdrant for vector storage. It’s lean, mean, and scales like a dream.
Killer Features: AI-driven retrieval and hybrid search that cuts through the noise. Plus, optional re-ranking if you’re a precision freak.
Learn more

At its core, Dcup is your bridge to smarter data handling. It takes the complexity out of RAG pipelines by automating the heavy lifting. Here’s how it works in plain English:

Data Ingestion: Hook up your data sources—think Google Drive, AWS, or wherever your files live—and Dcup keeps it all synced and current.
Data Processing: Your raw data gets chopped into bite-sized chunks and turned into embeddings using OpenAI. (More on embeddings later—they’re cool!)
Storage & Indexing: Those embeddings land in Qdrant, a lightning-fast vector database that makes searching a breeze.
Advanced Retrieval: Need answers fast? Features like re-ranking and hybrid search dig up the most relevant info in seconds.

Think of Dcup as your personal AI assistant that organizes, understands, and retrieves your data like a pro.

The Fight We Won

Big files used to choke us. Performance would tank, and we’d be staring at spinning wheels. Then we got smart—batching and parallel processing turned it around. Now, Dcup eats large datasets for breakfast.

Why You’ll Dig It

This isn’t some corporate ad. It’s a project by dev not shitty vibe coding or whatever the kids call it these days.

support the project

Star the repo if it vibes with you: Dcup on GitHub.

Wanna contribute? Hit me up! Let’s make RAG pipelines suck less together.

First Reverse Proxy Built with Zig

Ali Amer — Mon, 25 Nov 2024 11:45:37 +0000

The first-ever reverse proxy built with Zig. If you're a developer, sysadmin, or just someone interested in optimizing web traffic handling, Cloud Cup may be your new favorite tool. It's lightweight, fast, and built to scale. And it's open-source!

In this blog, I'll walk you through Cloud Cup’s architecture and the challenges I faced while building it. I’ll also talk about how you can help shape the future of this project, suggest new features, and contribute. I am just getting started, and your feedback and support can make all the difference.
What is Cloud Cup?

What is Cloud Cup?

Cloud Cup is a reverse proxy and load balancer designed with simplicity and performance in mind. It helps route traffic between clients and backend servers, distributing the load evenly to avoid overloading any single server. But here’s the twist – Cloud Cup is built using Zig, a low-level language known for its performance and control over memory usage.

Unlike traditional reverse proxies, which can be heavy on resources, Cloud Cup is lightweight, optimized for speed, and easy to configure. I believe it’s the next big thing in reverse proxies, and I want you to be a part of it.

Architecture

Cloud Cup’s architecture is designed to be as efficient and scalable as possible, and it revolves around the Master-Worker pattern. Let’s break it down:

Master Process

The master process is the heart of Cloud Cup. Here's what it does:

Configuration Management: The master process validates and applies configurations at startup, ensuring that everything is set up correctly before launching workers.
Dynamic Hot Reloading: Through the CLI tool (called cupctl), Cloud Cup can hot reload its configurations without needing to restart the entire system. This allows for seamless updates and scaling on the fly.
Worker Management: The master spawns multiple worker processes and ensures that they are always running. If a worker crashes, the master immediately spawns a replacement.
CLI Listener: The master also manages the command-line interface, which lets you interact with Cloud Cup, run diagnostics, and apply updates.

Worker Process

The worker process is responsible for handling actual network traffic:

Shared Port, Independent Threads: All workers listen on the same port, and the kernel manages the traffic distribution between them. Each worker has its own epoll instance for highly efficient I/O handling.
Concurrency with Thread Pool: Each worker has a dedicated thread pool for handling requests concurrently, making Cloud Cup highly scalable and responsive.
Configuration Updates: The workers dynamically receive updates from the master process, so configuration changes are applied across all workers instantly and consistently.

Challenges I Faced

Building Cloud Cup wasn’t without its challenges. Since I'm working with Zig, a language that is still relatively new in the ecosystem, I faced a steep learning curve when it came to optimizing networking performance and ensuring memory safety. But I was determined to keep the project lightweight, efficient, and easy to use.

Some of the challenges I overcame include:

Memory Management: Zig’s manual memory management gave us more control, but also required careful handling to avoid memory leaks or crashes. I've worked hard to ensure that Cloud Cup’s memory footprint remains minimal while still delivering high performance.
Concurrency and Scalability: I wanted Cloud Cup to handle heavy loads without sacrificing performance. Building the master-worker architecture allowed us to handle traffic distribution efficiently while maintaining responsiveness.

But I'm not done yet! I'm actively working on adding more features and improving performance even further.

How Can You Contribute?

As Cloud Cup is still in its early stages, I’d love your help! Whether you're a developer, tester, or just someone who wants to try out new software, you can contribute in many ways:

Feature Requests: Is there something you’d love to see in Cloud Cup? I'm listening! Submit your ideas, and I will review them.
Bug Reports: Encountered a bug? Let me know so I can fix it. Your feedback helps make Cloud Cup better for everyone.
Code Contributions: If you’re interested in contributing code, check out GitHub repo. I'd be happy to accept pull requests for new features or bug fixes.
Suggestions: Have suggestions on how I can improve documentation or features? Drop me a message. I want to make Cloud Cup as user-friendly as possible.

You can find all the information you need for contributing in our CONTRIBUTING.md file.
What’s Next?

I'm just getting started with Cloud Cup, but I already have big plans for future updates. In the next releases, I'm planning to improve:

Performance: Always looking to make Cloud Cup even faster!
Features: More advanced load balancing options and enhanced configuration management.
Documentation: I am committed to improving the docs, making it easier for developers to get started with Cloud Cup.

If you're passionate about reverse proxies, load balancing, or just want to see Cloud Cup grow, consider supporting me on our Patreon. Every bit of support helps me keep building and adding new features.

I Need Your Feedback!

I want to make Cloud Cup the best reverse proxy tool out there, and for that, I need your feedback. Whether it’s a suggestion for a new feature, an improvement to the documentation, or a bug you’ve encountered, I want to hear from you.

You can reach out via:

GitHub Issues: Create an Issue
Email: Send me a message at aliamer19ali@gmail.com

I am really excited about Cloud Cup, and I hope you’ll join me on this journey. Help me build the future of reverse proxies, one feature at a time!

Thanks for reading, and I can’t wait to hear what you think!

Github: https://github.com/cloud-cup/cloud-cup
DOC: https://cloud-cup.netlify.app/

DEV Community: Ali Amer

Ep2: Working on logger for Nusku

Quick start

Output formats

Levels

Fields

Scopes and bound context

The default logger

Using it with the cli module

Routing std.log into it

How it works

Limits and known gaps

Ep1: Setting Up The Project

The cli module

What it does

Quick start

File map

The data model

Command

Flag

ArgsRule

FlagValues

Context

How parsing works

The pass

Which flags are visible

Long flags

Short flags

Validation at set time

After the pass

Result and errors

Environment lookup

How help is rendered

How execute ties it together

Writing a command

Memory and lifetimes

Limits and known gaps

Ep0: Starting Nusku, a continuous profiler for Linux, built in Zig, no shortcuts

What it does

Why eBPF, and why Zig

The big picture

What I want to end up with

#DAY1: The story of unemployment peak for a software engineer

The story of unemployment peak for a software engineer

Stop maintaining two files that describe the same API

The problem in one sentence

What I built

Environment configs

Why Go?

Where it's at

Why does performance debugging still suck so much?

But there was a problem

The idea

What I’ve built so far

What’s next

Follow the project

The Hidden Superpower of AI: How Smart Data Retrieval Is Revolutionizing Everyday Life

Building Dcup: An Open-Source RAG Pipeline with a Twist

What’s Dcup All About?

The Fight We Won

Why You’ll Dig It

support the project

First Reverse Proxy Built with Zig

What is Cloud Cup?

Architecture

Master Process

Worker Process

Challenges I Faced

Some of the challenges I overcame include:

How Can You Contribute?

I Need Your Feedback!

Routing `std.log` into it

`Command`

`Flag`

`ArgsRule`

`FlagValues`

`Context`

How `execute` ties it together