DEV Community: icsboyx

[Boost]

icsboyx — Wed, 20 May 2026 11:39:22 +0000

icsboyx

May 20

I Just Wanted to Reuse Async Functions in Rust. I Ended Up Building a Tiny Task Manager

#rust #tokio #async #beginners

Comments

11 min read

I Just Wanted to Reuse Async Functions in Rust. I Ended Up Building a Tiny Task Manager

icsboyx — Wed, 20 May 2026 11:38:47 +0000

I Just Wanted to Reuse Async Functions in Rust. I Ended Up Building a Tiny Task Manager

I am currently studying Rust, and one of the things that kept bothering me was surprisingly simple:

How do I reuse an async function more than once in a clean way?

At first, this did not look like a big problem. I already had async functions. I already had Tokio. I could already spawn tasks.

So what was the issue?

The issue was that I did not just want to run a task once.

I wanted to:

register different async functions
run them inside the same async system
treat them as generic tasks
restart some of them depending on their role
keep the system logic separate from the task logic

That is the point where "I just need an async function" slowly becomes "I think I am building a task manager".

This article is the story of that shift.

If you want to follow along with the code, the project is here:

https://github.com/icsboyx/async_task_manager

And this is the central idea that finally made the whole thing click for me:

A Future is not a task definition.

A Future is one execution.

If I want restartable async work, I should store the recipe: Fn() -> Future.

The Real Problem Was Not Async

The real problem was not writing async functions.

Rust makes it easy to write something like this:

pub async fn task1() -> anyhow::Result<()> {
    loop {
        println!("task 1 is running");
        tokio::time::sleep(std::time::Duration::from_secs(1)).await;
    }
}

This function intentionally never returns, so there is no trailing Ok(()).
If I later add shutdown logic, I can exit the loop cleanly with something like break Ok(()).

The problem starts when you want to say:

"I want to store multiple async functions, possibly with different behaviors, and start them when I want."

That sounds natural, but in Rust it immediately forces you to think about:

concrete types
futures
trait objects
closures
pinning
ownership
reusability

And that is where I hit my first wall.

My First Wrong Mental Model

My first instinct was something like:

let tasks = vec![task1, task2, task3];

Conceptually, that is exactly what I wanted:

here are my tasks
keep them in a collection
run them when needed
restart them if needed

But that nice mental model hides the real issue.

Each async fn returns a future, and each future has its own concrete type.
So the moment I want one task manager to store several different async starters behind one uniform interface, I need to be much more explicit about the abstraction I want.

That was the first real lesson:

If I want to restart async work, I should not store a future that is already created.

I should store something that can create a fresh future every time.

That single realization changed the whole design.

`task1` vs `task1()`: The Difference That Actually Matters

This was the point where Rust forced me to think more clearly.

The first mistake would be trying to store this:

task1()

Why is that wrong for my use case?

Because task1() is not the task definition.
It is a future instance created right now.

That means:

it represents one execution
once that execution finishes, that value is done
if I want to restart the task, I do not want the old future back
I need a brand new future for the next run

So the real thing I needed was not:

task1()

but:

task1

or, more generally:

Fn() -> Future

That is the key mental shift.

Function Item, Function Pointer, Closure, `dyn Fn`

This also helped me understand something I had been hand-waving before.

task1 is not automatically "a dynamic function".

At first, it is a function item: a concrete value tied to one exact function.
Rust knows exactly which function it is and gives it a concrete type.

From there, I can move through more general callable shapes:

task1: a concrete function item
fn() -> _: a function pointer
move || ...: a closure
dyn Fn() -> _: a dynamically dispatched callable trait object

That distinction mattered a lot for me, because the real transition was not just:

from task1() to task1

but:

from one concrete callable
toward one uniform callable abstraction I could store in the task manager

Once I saw it that way, the problem stopped being "why is Rust being difficult?" and became "what callable shape do I actually need?"

The Important Type Transition: From Concrete to Dynamic

This was probably the most important Rust lesson in the whole project.

When I write:

pub async fn task1() -> anyhow::Result<()>

Rust gives me a concrete future type behind the scenes.
The same is true for task2, task3, and every other async fn.

So even if all my functions look conceptually similar, Rust still sees different concrete future types.

That means this line is doing two jobs in the article:

let tasks = vec![task1, task2, task3];

Repetita iuvant.
Yes, I am showing the same line again on purpose.
The first time, it was my naive mental model.
This time, it marks the exact point where the type system pushes back.

If I want a HashMap, a queue, or a task manager to store all tasks uniformly, I need one shared stored type.
I cannot keep each future in its own concrete shape and still expect one collection to treat them all the same.

So this is where I had to make the move that, for me, changed the whole design:

from one concrete future type
to one dynamic future abstraction I could actually store

Because this is the point where Rust stops feeling like:

I wrote some async functions

and starts feeling like:

I need to model a reusable async execution boundary

In other words, I stopped thinking:

Store this exact future type.

and started thinking:

Store anything that behaves like a future returning Result<()>, even if the concrete future behind it changes from task to task.

In cleaned-up form, the idea that finally made sense to me was this:

use std::{
    future::Future,
    pin::Pin,
    sync::Arc,
};

type TaskFuture =
    Pin<Box<dyn Future<Output = Result<(), anyhow::Error>> + Send + 'static>>;

type TaskFn =
    Arc<dyn Fn() -> TaskFuture + Send + Sync + 'static>;

And this was exactly the moment where my brain went:

wow wow wow wow wow... what the duck is this?

Because the first time you see something like this while learning Rust, it does not look like "a reusable task".
It looks like somebody dropped an entire type system on your keyboard.

And yet, once I slowed down and read it piece by piece, it stopped looking absurd.

This pair of types says exactly what I need:

a callable thing I can keep
that I can invoke more than once
and that gives me an owned future I can spawn each time

That is the real abstraction boundary in the design.

Why `dyn Future` Needs `Box`

Trait objects like dyn Future do not have a known size at compile time.

Rust therefore cannot store them directly by value.
I need indirection.

That is why the owned dynamic future shape is typically:

Box<dyn Future<Output = Result<(), anyhow::Error>> + Send>

The Box gives me:

one stable heap allocation for the concrete future
one uniform, sized handle I can store
a way to erase the concrete future type behind a common interface

The same idea applies to the callable itself.

I do not want one Task<F, Fut> per task starter.
I want one storable task function type shared by the whole manager.

Why `Pin<Box<dyn Future<...>>>`

This was another thing that looked scary until it clicked.

Many futures produced by async fn are not Unpin.
After polling starts, Rust may require that they are not moved around in memory.

That is why the common owned dynamic future shape is not just:

Box<dyn Future<Output = Result<(), anyhow::Error>> + Send>

but:

Pin<Box<dyn Future<Output = Result<(), anyhow::Error>> + Send>>

So:

dyn Future gives me dynamic dispatch
Box gives me indirection and a sized owned container
Pin gives me the movement guarantees a future may require

Once that clicked, the ugly type stopped looking random.
It started looking like a precise description of the thing I actually needed to own.

The Closure That Makes the Whole Thing Reusable

Even after understanding the dynamic future type, I still needed a bridge between:

the original concrete callable
and the uniform task function type I wanted to store

That bridge is the closure.

In cleaned-up form, the constructor looks like this:

impl Task {
    pub fn new<F, Fut>(
        name: impl Into<String>,
        function: F,
        task_type: TaskType,
    ) -> Self
    where
        F: Fn() -> Fut + Send + Sync + 'static,
        Fut: Future<Output = Result<(), anyhow::Error>> + Send + 'static,
    {
        let start_fn: TaskFn = Arc::new(move || {
            Box::pin(function()) as TaskFuture
        });

        Self {
            uuid: uuid::Uuid::new_v4().to_string(),
            name: name.into(),
            start_fn,
            task_type,
        }
    }
}

At first glance, this looks like glue code.

It is not.

This closure is doing the real adaptation work.

It does three jobs at once:

it owns the original concrete callable
it calls it each time a fresh execution is needed
it erases the concrete future type into TaskFuture

That is what makes the design restartable.

Without this adapter, I would not really have a reusable task definition.
I would just have a bunch of specific functions with no common storage shape.

The move also matters here.
It makes the closure take ownership of function, so the task can keep that callable around and use it later, long after Task::new has returned.

If I had to summarize this entire section in one sentence, it would be:

The reusable thing is not the future.

The reusable thing is the factory that creates a fresh future on demand.

A Diagram of What Actually Happens

Here is the transformation that finally helped me think about it clearly:

For reference, this is the Mermaid source:
Show the Mermaid source

flowchart LR
    A["Concrete async function<br/>task1"] --> B["Concrete callable<br/>F: Fn() -> Fut"]
    B --> C["Adapter closure<br/>move || Box::pin(function())"]
    C --> D["Dynamic task factory<br/>TaskFn"]
    D --> E["Stored inside Task<br/>start_fn"]
    E --> F["Called by TaskManager"]
    F --> G["Fresh owned future<br/>TaskFuture"]
    G --> H["Spawned into Tokio JoinSet"]

This is also the point where the whole thing started to feel like function inception:

a function that stores a function that creates a future that runs a task

Ridiculous? A little.
Correct? Also yes.

Building a Task Type

Once I understood that I needed a restartable task factory, the next step was creating a task representation with both execution behavior and system meaning.

Conceptually, the task shape became:

pub struct Task {
    uuid: String,
    name: String,
    start_fn: TaskFn,
    task_type: TaskType,
}

I liked this design because each task now had:

an identity
a name for logs
a reusable startup function
a system-level policy

And that last point turned out to be very important.

Running a Task Is Not Enough. You Need to Know What It Means

While building the manager, I realized that "a task ended" is not enough information.

A task manager should not only know how to run a task.
It should know what that task means to the system.

Some tasks are optional.
Some tasks should stop the whole system when they end.
Some tasks are essential enough that if they disappear, the rest of the system no longer makes sense.

That is why I introduced this enum:

pub enum TaskType {
    ShutDownOnExit,
    Mandatory(i32),
    Detachable(i32),
}

This was a big architectural improvement, because now the manager was not just executing tasks.
It was interpreting them.

`ShutDownOnExit`

If this task exits, the manager stops.

This is perfect for something like a ctrl_c_handler.

`Mandatory(restarts)`

This task is essential for the system.

If it exits, restart it while budget remains.
If the restart budget is exhausted, stop the whole manager.

For me, this means:

if this task is gone, keeping the rest of the system alive no longer makes sense

`Detachable(restarts)`

This task is useful, but not essential.

If it exits successfully, I can discard it.
If it fails, I can restart it while budget remains.
If the restart budget is exhausted, I discard it and let the rest of the system continue.

That made the whole project feel much more like a small supervised async system, and much less like a pile of random spawned tasks.

The Restart Counter Was More Subtle Than I Expected

Another thing that looked easy at first was restart logic.

I thought:

"Fine, I just decrement a counter and restart the task."

But once I started implementing it, I had to answer a more precise question:

What does 3 actually mean?

Does it mean:

the task can run 3 times total?
the task can fail 3 times?
the task can be restarted 3 times after the first start?

I chose the last meaning.

So in my design:

Mandatory(3) or Detachable(3) means:

1 initial start
up to 3 restarts

That sounds simple, but it forced me to be careful with off-by-one logic.

The behavior I wanted was:

if remaining restarts are greater than zero, restart and decrement
if remaining restarts are zero, do not restart anymore

That was one of those small implementation details that taught me a lot about translating a verbal idea into precise behavior.

Why `JoinSet` Helped a Lot

Once I had reusable task factories, I still needed a way to:

spawn multiple tasks
wait for whichever one completes next
know which task completed
separate task completion from task policy decisions

tokio::task::JoinSet was a very good fit for this.

The manager can spawn tasks into the set and then wait for completions:

result = self.task_set.join_next_with_id() => {
    // handle task completion here
}

That with_id part matters a lot.

If a task finishes, I do not just want to know that something finished.
I want to know which task finished, so I can:

remove it from the active set
look up its metadata
apply the correct restart or shutdown policy

Another subtle but important point is that if the spawned task returns Result<(), anyhow::Error>, then the join result is nested.

In practice, that means these cases are different:

Some(Ok((id, Ok(()))))   // Tokio join succeeded and the task returned Ok
Some(Ok((id, Err(e))))   // Tokio join succeeded but the task returned an application error
Some(Err(e))             // Tokio JoinError: panic, cancellation, abort, etc.
None                     // No more tasks in the JoinSet

That distinction matters because "the join worked" is not the same thing as "the task succeeded".

JoinSet gave me a clean place to separate:

execution mechanics
task outcome
system policy

And that made the task manager much easier to reason about.

The Core Idea of the Manager

At a high level, the flow became:

Create tasks and push them into a queue.
Spawn them into a JoinSet.
Wait for whichever task finishes next.
Identify the task.
Inspect how it ended.
Apply the policy defined by TaskType.
Restart, discard, or stop the system.

That is the moment where the project stopped being "a few async functions" and became a tiny async supervisor.

The Part That Taught Me the Most

If I had to summarize what this project really taught me, it would be this:

1. Reusability in async Rust is about factories

If I want to execute the same async logic multiple times, I should usually store something that creates a future, not the future itself.

2. System behavior should not live inside each task

The task should focus on doing work.
The manager should decide what to do when that work ends.

That separation made the code much easier to reason about.

3. Semantics matter more than syntax

A lot of the difficulty was not "how do I write this in Rust?"

It was:

what exactly does restart mean?
when should the whole system stop?
which tasks are optional and which are essential?

Those are architecture questions, not syntax questions.

Rust just forces you to answer them more explicitly.

Current Shape of the Project

Right now, the project is small on purpose.

It starts a few demo tasks, including a Ctrl+C handler, and routes their behavior through a small task manager with different policies.

It is not a production-grade supervisor, and I do not think it needs to be.

For me, it is a learning project with a very specific goal:

to understand how to reuse async functions cleanly, and how to build a small but structured execution model around them.

And honestly, I think that is why this project was useful.

It did not try to solve everything.
It solved one problem that kept bothering me, and in doing so it forced me to understand several Rust concepts more deeply.

Final Thought

I started with a very small question:

How can I reuse async functions in Rust without turning everything into a mess?

I ended up learning about:

boxed futures
trait objects
closures as adapters
pinning
task supervision
restart policy design
async orchestration with Tokio

That is one of the things I like most about learning Rust:

you often start by trying to solve a local problem, and end up improving the way you think about the whole system.

If you are learning Rust too, and you have hit the same wall around reusable async functions, I hope this helps.

Sometimes the real progress is not just making the code compile.
Sometimes it is finally understanding what kind of abstraction you actually needed.

If you want to explore the code itself, you can find the project here:

https://github.com/icsboyx/async_task_manager

My Tiny Rust Utils, Part 5: mod.rs

icsboyx — Thu, 30 Apr 2026 16:13:25 +0000

This last part is about the least impressive file in the crate:

pub mod helpers;
pub mod macros;
pub mod save_load;
pub mod web;

That is src/utils/mod.rs.

It is just four lines.

And maybe that is why it feels like the right place to end the series.

Why a boring file still matters

I like this file because it does not pretend to be smarter than it is.

It just says:

these are the utility modules
they live together
this is the shape of the toolbox

After the previous parts, that shape is easier to read:

macros.rs helps me see what the program is doing
helpers.rs removes a bit of error and JSON friction
save_load.rs gives me one place for config-like persistence
web.rs keeps HTTP glue from leaking everywhere

None of those files is huge.

None of them is a framework.

That is very intentional.

I think I work better when the code is allowed to stay small and honest for as long as possible.

How the crate feels to me

This utils crate is not something I built because I wanted to be abstract.

It is something I built because I know how I work.

If I do not create a little structure around repeated pain points, I end up with the same code copied in slightly different ways across the project.

And then I get annoyed with myself later.

So this crate is a compromise between two things:

I do not want ceremony
I also do not want chaos

That is really the whole story.

A more personal ending

I think this is the part where I should be honest.

For me, coding is not really "work" in the emotional sense, even when it is tiring.

It is more like a mix of:

joy
frustration
curiosity
stubbornness

Sometimes it is fun.

Sometimes it is painful in a very specific and ridiculous way.

Sometimes a tiny bug ruins half a day.

Sometimes a four-line helper makes the whole project feel lighter again.

That is why I keep doing it.

Not because every line of code is important.

Not because every project needs to become a product.

But because coding, for me, is still one of the nicest forms of mental exercise I know.

It is a hobby, a habit, and occasionally a headache I choose on purpose.

And honestly, I mean that in a good way.

Final thought

If you also keep building small local utility files for your own projects, I do not think that is a bad sign.

Maybe it just means you are slowly learning what kind of friction bothers you, and what kind of tools help you think.

That is more or less what this crate is for me.

My Tiny Rust Utils, Part 4: web.rs

icsboyx — Thu, 30 Apr 2026 16:10:05 +0000

I like reqwest.

I just do not always like seeing raw reqwest patterns repeated all over my application code.

That is the whole reason src/utils/web.rs exists.

I don't need full HTTP framework. I just need one place to keep a few recurring things:

response decoding
basic header preparation
a default User-Agent
a simpler response type for the rest of the app

A smaller response model

The file starts here:

#[derive(Debug, Clone, Serialize, Deserialize)]
pub enum ResponseBody {
    Json(Value),
    Text(String),
    Binary(Bytes),
}

#[derive(Debug, Clone)]
pub struct HttpReply {
    pub status: StatusCode,
    pub headers: HeaderMap,
    pub body: ResponseBody,
}

That already helps me.

Instead of passing raw reqwest::Response deeper into the app, I get a smaller local type that matches how this project actually thinks about HTTP replies.

That is enough abstraction for me. No more is needed here.

`json_try_into`

The helper I probably use the most is this one:

impl ResponseBody {
    pub fn json_try_into<T>(&self) -> Result<T>
    where
        T: for<'de> Deserialize<'de>,
    {
        match self {
            ResponseBody::Json(json) => serde_json::from_value(json.clone()).map_err(Into::into),
            _ => bail!("Response body is not JSON, cannot deserialize"),
        }
    }
}

That lets me write things like:

let token = http_reply.body.json_try_into::<BotIdentity>()?;

I like this because it is strict in a simple, readable way.

If the body is not JSON, it says so.

If the JSON shape does not match the target type, it says so.

That is exactly the level of honesty I want from utility code.

Default headers without fuss

The file also takes care of the default User-Agent:

pub const DEFAULT_USER_AGENT: &str = concat!(env!("CARGO_PKG_NAME"), "/", env!("CARGO_PKG_VERSION"));

fn prepare_headers(headers: Option<HeaderMap>, user_agent: Option<&str>) -> Result<HeaderMap> {
    let mut headers = headers.unwrap_or_default();

    if !headers.contains_key(header::USER_AGENT) {
        let value = HeaderValue::from_str(user_agent.unwrap_or(DEFAULT_USER_AGENT))?;
        headers.insert(header::USER_AGENT, value);
    }

    Ok(headers)
}

This is a tiny thing, but it is one of those details that becomes annoying if I have to remember it in every call site.

So I would rather centralize it once and stop thinking about it.

The public API stays small

The actual entry points are just these:

pub async fn get_http(
    url: impl AsRef<str>,
    headers: Option<HeaderMap>,
    query: Option<&[(&str, &str)]>,
    user_agent: Option<&str>,
) -> Result<HttpReply> {
    let headers = prepare_headers(headers, user_agent)?;
    let request = http_client().get(url.as_ref()).headers(headers);
    let response = apply_query(request, query).send().await?;

    decode_response(response).await
}

pub async fn post_http(
    url: impl AsRef<str>,
    headers: Option<HeaderMap>,
    query: Option<&[(&str, &str)]>,
    body: Option<Value>,
    user_agent: Option<&str>,
) -> Result<HttpReply> {
    let headers = prepare_headers(headers, user_agent)?;
    let mut request = http_client().post(url.as_ref()).headers(headers);
    if let Some(body) = body {
        request = request.json(&body);
    }
    let response = apply_query(request, query).send().await?;

    decode_response(response).await
}

I am happy when a utility module stays about this size.

It does not try to be clever.

It just absorbs repetition so the rest of the code stays calmer.

Where it pays off

A real call site looks like this:

let sub_reply: Value = post_http(url, Some(headers), None, Some(subscription_request.json_value()?), None)
    .await?
    .body
    .json_try_into()?;

I still recognize that as ordinary application code.

That is important to me.

If the wrapper made this harder to read, I would not consider it a win.

Moving to Part 5

At this point the pieces are all on the table:

macros
helpers
save/load
HTTP

The last part is the simplest file, mod.rs, but it is also where I can finally say what this whole crate means to me.

My Tiny Rust Utils, Part 3: save_load.rs

icsboyx — Thu, 30 Apr 2026 16:07:25 +0000

Sooner or later, even a small bot needs to remember something.

In my case, that usually means token-like or config-like data.

I do not want to build a whole persistence subsystem for that, but I also do not want save/load code duplicated in random places.

That is where src/utils/save_load.rs comes from.

The basics

The file starts with a few exports and a format enum:

pub use anyhow::{Error, Result, bail};
pub use serde::{Deserialize, Serialize};
pub use serde_json;
pub use toml;

pub static CONFIG_BASE_DIR: &str = ".config";

#[derive(Debug, Clone, Copy, PartialEq, Eq, Default)]
pub enum SaveType {
    JSON,
    YAML,
    #[default]
    TOML,
}

This is a very local design.
It is just trying to answer a smaller question:

"How does this project save and load structured data without repeating itself?"

For that, this is enough.

`ConfigManager`

The main trait is:

pub trait ConfigManager
where
    Self: Sized + Serialize + for<'de> Deserialize<'de>,
{
    fn save_custom(&self, file_path: PathBuf, dir_path: PathBuf, save_type: SaveType) -> Result<()> {
        let file_path = PathBuf::new()
            .join(dir_path)
            .join(file_path)
            .with_extension(save_type.as_str());
        save_file(&file_path, self, save_type)
    }

    fn load_custom(file_path: PathBuf, dir_path: PathBuf, save_type: SaveType) -> Result<Self> {
        let file_path = PathBuf::new()
            .join(dir_path)
            .join(file_path)
            .with_extension(save_type.as_str());
        load_file(&file_path)
    }

    fn save(&self) -> Result<()> {
        let struct_name = struct_name_from_type::<Self>()?;
        let file_path = PathBuf::new()
            .join(CONFIG_BASE_DIR)
            .join(struct_name)
            .with_extension(SaveType::default().as_str());
        save_file(&file_path, self, SaveType::default())
    }

    fn load() -> Result<Self> {
        let struct_name = struct_name_from_type::<Self>()?;
        let file_path = PathBuf::new()
            .join(CONFIG_BASE_DIR)
            .join(struct_name)
            .with_extension(SaveType::default().as_str());
        load_file(&file_path)
    }
}

What I like here is not sophistication.

It is that the feature code stays short.

In the token flow, I can simply do:

let mut tw_token = TwitchToken::load_or_default();
tw_token.save()?;

That feels about right for a project of this size.

The part that matters most to me

The most important part of this file is not the serialization format.

It is the path validation.

Here is the real function:

fn validate_path(file_path: &Path) -> anyhow::Result<PathBuf> {
    let mut normalized = PathBuf::new();

    for comp in file_path.components() {
        match comp {
            Component::Normal(part) => normalized.push(part),
            Component::CurDir => {}
            Component::Prefix(p) => {
                bail!("Config path should not contain prefix component: {:?}", p);
            }
            Component::RootDir => {
                bail!("Config path should not contain root component: /..",);
            }
            Component::ParentDir => {
                if !normalized.pop() {
                    bail!(
                        "Path traversal detected: config path should not contain parent directory component that goes beyond root dir",
                    )
                }
            }
        }
    }

    if normalized.as_os_str().is_empty() {
        anyhow::bail!("Empty config path");
    }

    Ok(normalized)
}

I trust code more when the rules are visible.

This function makes the rules visible:

no absolute paths
no prefix components
no climbing upward beyond the normalized relative path
no empty paths

That is the kind of small defensive behavior I like to centralize.

Not because it is glamorous, but because I do not want to rediscover the same problem later.

Why I prefer this over inline file code

Without a file like this, the same chores start leaking everywhere:

picking the file extension
creating directories
converting values into the chosen format
validating paths
building consistent error messages

I would rather make those choices once.

This file is basically me admitting that repetitive file IO glue is not something I want to keep solving in five different places.

Moving to Part 4

Once local persistence is under control, the next obvious pain point is external IO.

For this project, that means HTTP.

So the next part is web.rs.

My Tiny Rust Utils, Part 2: helpers.rs

icsboyx — Thu, 30 Apr 2026 16:02:35 +0000

After logging, the next kind of repetition that starts bothering me is usually this:

adding context to errors
converting typed values into JSON request bodies

Neither of those is dramatic on its own.

But if I leave them totally inline, they spread everywhere.

That is why src/utils/helpers.rs exists.

`WithLocation`

This is the first helper:

pub trait WithLocation<T> {
    fn with_location(self) -> anyhow::Result<T>;
    fn with_location_msg(self, msg: &str) -> anyhow::Result<T>;
}

impl<T, E> WithLocation<T> for std::result::Result<T, E>
where
    E: Into<anyhow::Error>,
{
    #[track_caller]
    fn with_location(self) -> anyhow::Result<T> {
        let loc = Location::caller();

        self.map_err(Into::into)
            .with_context(|| format!("{}:{}:{}", loc.file(), loc.line(), loc.column()))
    }

    #[track_caller]
    fn with_location_msg(self, msg: &str) -> anyhow::Result<T> {
        let loc = Location::caller();

        self.map_err(Into::into)
            .with_context(|| format!("{} at {}:{}:{}", msg, loc.file(), loc.line(), loc.column()))
    }
}

I like this because it captures something I personally care about when debugging:

not only what failed, but where I decided to wrap or reinterpret that failure.

That is often the more useful location for me.

Why I still keep it as a helper

Yes, I could just write .context(...) everywhere.

Sometimes I do.

But I know myself well enough: if the repetitive part feels slightly annoying, I will postpone it in one or two places, and then the code becomes uneven.

This helper lowers that friction just enough that I actually use it.

That is a recurring theme in this utils crate, honestly. I am not searching for elegance as much as I am trying to remove small excuses.

`IntoJsonValue`

The second helper is very small:

pub trait IntoJsonValue {
    fn json_value(self) -> serde_json::Result<Value>
    where
        Self: Sized + Serialize,
    {
        serde_json::to_value(self)
    }
}

impl<T> IntoJsonValue for T {}

This is almost embarrassingly tiny.

Still, I like it.

It lets me write:

Some(subscription_request.json_value()?)

instead of:

Some(serde_json::to_value(subscription_request)?)

That difference is not huge.

But I think a lot of utility code lives exactly in that zone: not essential, not magical, just a little nicer to use.

`TrackError`

The same file also has a very small custom error type:

#[derive(Debug)]
pub struct TrackError {
    pub location: &'static std::panic::Location<'static>,
    pub message: String,
}

impl TrackError {
    #[track_caller]
    pub fn new(message: impl Into<String>) -> Self {
        Self {
            location: std::panic::Location::caller(),
            message: message.into(),
        }
    }
}

I keep it around because sometimes I want something between:

a full error enum
and a generic error chain

Sometimes I just want a normal error value with a message and a caller location.

This gives me that, without pretending to be more important than it is.

Moving to Part 3

Once logs and helper traits are in place, the next problem is usually state.

Small apps still need to save things. Tokens, config-like values, maybe a bit of local persistence.

That is where save_load.rs comes in.

My Tiny Rust Utils, Part 1: macros.rs

icsboyx — Thu, 30 Apr 2026 16:01:19 +0000

I did not build this little utils crate because I thought I had something revolutionary to show.

I built it for a much simpler reason: while working on small Rust projects, I keep running into the same tiny frictions over and over again.

Nothing dramatic. Just the usual stuff:

logging that starts inconsistent
little helper code repeated in the wrong places
config or HTTP glue leaking into feature modules
small annoyances that are easy to ignore for a day and then annoying for a month

So this crate is mostly me trying to be a bit kinder to my future self.

I wanted one place for the small things that make the project easier to read, easier to debug, and a little less noisy.

And I wanted to share it for the exact same reason.

Not because these files are perfect, and not because I think anyone should copy them as-is, but because I always enjoy seeing how other people solve these very ordinary problems in their own projects.

Sometimes the most useful things to share are not big architectures or polished libraries.

Sometimes they are just small, honest utilities that made a project nicer to work on.

This is the crate I am talking about:

src/
└── utils/
    ├── helpers.rs
    ├── macros.rs
    ├── mod.rs
    ├── save_load.rs
    └── web.rs

So before getting into the rest of the series, I wanted to show the shape of it.

It is a small crate, but each file has its own job:

macros.rs for logs, timestamps, and source breadcrumbs
helpers.rs for small error and JSON helpers
save_load.rs for config-like persistence
web.rs for a thin HTTP layer
mod.rs as the glue that exposes the submodules

If I had to choose where this little series really starts, it would be macros.rs.

Not because macros are the most important thing in the world, and not because this file is especially smart.

It is just the first file that makes the rest of the project easier to live with.

When I am building a small bot or service, I usually want a few very basic things:

log lines that look consistent
timestamps without repeating formatting code everywhere
a cheap way to see where something happened

That is all src/utils/macros.rs is trying to do.

The real `log!` macro

Here is the actual code:

#[macro_export]
macro_rules! log {
    () => {{
        $crate::log!("");
    }};
    ($($arg:tt)*) => {{
        std::println!(
            "[ {} ] {} {}",
            $crate::timestamp!(millis),
            if cfg!(debug_assertions){crate::here!()} else {format!("[ {:<20} ]", module_path!())},
            format!($($arg)*)
        );
    }};
}

And the stderr version:

#[macro_export]
macro_rules! err_log {
    () => {{
        $crate::err_log!("");
    }};
    ($($arg:tt)*) => {{
        std::eprintln!(
            "[ {} ] {} {}",
            $crate::timestamp!(millis),
            if cfg!(debug_assertions){crate::here!()} else {format!("[ {:<20} ]", module_path!())},
            format!($($arg)*)
        );
    }};
}

This is not a grand logging system.

It is just a format I do not have to think about every time I want to print something.

That matters more than it sounds.

When the friction is low, I log more consistently. When I log more consistently, I understand the project better.

The small trick I still like

This part is probably my favorite:

if cfg!(debug_assertions){crate::here!()} else {format!("[ {:<20} ]", module_path!())}

In debug builds, I get source position.

In release builds, I get the module path instead.

That feels modest, but useful:

during development I want precise breadcrumbs
outside development I usually want something a bit cleaner

I do not need this to be perfect. I just need it to help.

`here!` is tiny, but honest

This is the real macro:

#[macro_export]
macro_rules! here {
    () => {
        format!(
            "[ {:<30} ]",
            format!("{}:{}:{}", file!(), line!(), column!())
        )
    };
    ($fmt:literal $(, $arg:expr)* $(,)?) => {
        format!(
            "[ {:<30} ] {}",
            format!("{}:{}:{}", file!(), line!(), column!()),
            format_args!($fmt $(, $arg)*)
        )
    };
}

I use it directly in places like this:

let session_id = msg.payload.session.as_ref().context(here!()).unwrap().id.as_str();

That line is not fancy at all. It is basically me saying:

"If this breaks, please show me exactly where I made this assumption."

I like helpers that are honest like that.

Timestamp helpers

The timestamp macro is also deliberately small:

#[macro_export]
macro_rules! timestamp {
    () => {{ chrono::Local::now().format("%Y-%m-%d %H:%M:%S").to_string() }};
    (milliseconds) => {{ chrono::Local::now().format("%Y-%m-%d %H:%M:%S%.3f").to_string() }};
    (millis) => {{ $crate::timestamp!(milliseconds) }};
    (micro) => {{ chrono::Local::now().format("%Y-%m-%d %H:%M:%S%.6f").to_string() }};
    (micros) => {{ $crate::timestamp!(micro) }};
    (nano) => {{ chrono::Local::now().format("%Y-%m-%d %H:%M:%S%.9f").to_string() }};
    (nanos) => {{ $crate::timestamp!(nano) }};
    ($fmt:literal) => {{ chrono::Local::now().format($fmt).to_string() }};
    ($unknown:tt) => {
        compile_error!(
            "unsupported timestamp! argument. Use: milliseconds|millis|micro|micros|nano|nanos|\"custom fmt\""
        );
    };
}

I am aware this is not revolutionary code.

That is kind of the point.

It saves me from repeating chrono formatting noise, and it keeps the call sites readable:

log!("Token will expire at: {:#?}", TW_TOKEN.expires_at().await);

For this project, that is enough justification.

What the output looks like

In debug builds, the output includes the exact source location:

[ 2026-04-30 12:15:44.381 ] [ src/tw_client.rs:94:36       ] Handling session welcome message, id abc123

In release builds, the same kind of line becomes a bit cleaner and shows the module path instead:

[ 2026-04-30 12:15:44.381 ] [ botox::tw_client     ] Handling session welcome message, id abc123

That difference is small, but it is intentional.

When I am debugging, I usually want the exact place.

When I am not, the module name is often enough.

It is not beautiful. It is not trying to be.

It is just useful in the exact way I need.

Moving to Part 2

Once I have logs and source breadcrumbs, the next annoyance is usually error context and JSON glue.

That is where helpers.rs starts to matter, so that is the next part.

DEV Community: icsboyx

[Boost]

I Just Wanted to Reuse Async Functions in Rust. I Ended Up Building a Tiny Task Manager

I Just Wanted to Reuse Async Functions in Rust. I Ended Up Building a Tiny Task Manager

I Just Wanted to Reuse Async Functions in Rust. I Ended Up Building a Tiny Task Manager

The Real Problem Was Not Async

My First Wrong Mental Model

task1 vs task1(): The Difference That Actually Matters

Function Item, Function Pointer, Closure, dyn Fn

The Important Type Transition: From Concrete to Dynamic

Why dyn Future Needs Box

Why Pin<Box<dyn Future<...>>>

The Closure That Makes the Whole Thing Reusable

A Diagram of What Actually Happens

Building a Task Type

Running a Task Is Not Enough. You Need to Know What It Means

ShutDownOnExit

Mandatory(restarts)

Detachable(restarts)

The Restart Counter Was More Subtle Than I Expected

Why JoinSet Helped a Lot

The Core Idea of the Manager

The Part That Taught Me the Most

1. Reusability in async Rust is about factories

2. System behavior should not live inside each task

3. Semantics matter more than syntax

Current Shape of the Project

Final Thought

My Tiny Rust Utils, Part 5: mod.rs

Why a boring file still matters

How the crate feels to me

A more personal ending

Final thought

My Tiny Rust Utils, Part 4: web.rs

A smaller response model

json_try_into

Default headers without fuss

The public API stays small

Where it pays off

Moving to Part 5

My Tiny Rust Utils, Part 3: save_load.rs

The basics

ConfigManager

The part that matters most to me

Why I prefer this over inline file code

Moving to Part 4

My Tiny Rust Utils, Part 2: helpers.rs

WithLocation

Why I still keep it as a helper

IntoJsonValue

TrackError

Moving to Part 3

My Tiny Rust Utils, Part 1: macros.rs

The real log! macro

The small trick I still like

here! is tiny, but honest

Timestamp helpers

What the output looks like

Moving to Part 2

`task1` vs `task1()`: The Difference That Actually Matters

Function Item, Function Pointer, Closure, `dyn Fn`

Why `dyn Future` Needs `Box`

Why `Pin<Box<dyn Future<...>>>`

`ShutDownOnExit`

`Mandatory(restarts)`

`Detachable(restarts)`

Why `JoinSet` Helped a Lot

`json_try_into`

`ConfigManager`

`WithLocation`

`IntoJsonValue`

`TrackError`

The real `log!` macro

`here!` is tiny, but honest