DEV Community

Kairav Dutta
Kairav Dutta

Posted on

Why I Built Yet Another Logging Library

#python #showdev #tooling #programming

Why I Built Yet Another Logging Library

Or, why I think logging should be as easy as print().

If you've ever started a new project, you've probably written something like this:

print("Server started")
print("Database connected")
print("Error:", err)
Enter fullscreen mode Exit fullscreen mode

Eventually, you realize you want timestamps.

Then colors.

Then log levels.

Then file logging.

So you search for a logging library.

You install it.

Read the documentation.

Configure it.

And suddenly you've spent fifteen minutes setting up something that every project needs.

That always bothered me.

So I asked myself:

What if logging was as easy as copying a single file into your project?

That's why I built LogX.

The Goal

I wasn't trying to build another enterprise logging framework.

There are already fantastic projects like spdlog, Winston, Pino, Zap, and many others that solve production-scale problems extremely well.

My goal was much smaller.

I wanted something that:

  • takes less than a minute to integrate
  • has zero runtime dependencies
  • works across multiple programming languages
  • has a familiar API everywhere

In other words:

Professional logging without the setup.

What LogX Looks Like

Instead of installing packages and reading configuration guides, the experience is intentionally simple.

Python 

from logx import log

log.info("Server started")
log.warn("Cache miss")
log.error("Database unavailable")
Enter fullscreen mode Exit fullscreen mode

C++ 

#include "logx.hpp"

log.info("Server started");
Enter fullscreen mode Exit fullscreen mode

TypeScript 

import { log } from "logx";

log.info("Server started");
Enter fullscreen mode Exit fullscreen mode

The goal is that if you know one language, the API feels familiar in the others.

Why Not Just Use print()?

Because after your project grows a little, print() starts showing its limits.

You usually want things like:

  • timestamps
  • colors
  • log levels
  • file logging
  • cleaner formatting

But I also didn't want to pull in a large dependency just to get those basics.

So LogX tries to sit in the middle.

It gives you structured, readable logs while staying lightweight and requiring virtually no setup.

The Philosophy

One thing I noticed while working on this project is that many logging libraries are designed to solve problems that appear in very large systems.

Things like:

  • distributed tracing
  • asynchronous pipelines
  • log aggregation
  • cloud transports
  • observability platforms

Those are valuable features.

They're also completely unnecessary for many projects.

Sometimes you're writing:

  • a CLI tool
  • a game
  • a college project
  • a hackathon submission
  • a prototype
  • a personal utility

In those situations, I think logging should be simple.

That's the niche LogX is trying to fill.

Why Multiple Languages?

As I started using different programming languages more often, I realized I kept learning different logging APIs for every ecosystem.

The concepts were always the same, but the syntax, configuration, and setup varied from language to language.

I wanted one consistent experience.

Whether you're writing C, C++, Python, TypeScript, or another supported language, the API should feel familiar.

Learn it once.

Use it everywhere.

The Hardest Part Wasn't the Code

Writing a logger isn't particularly difficult.

The interesting challenge was designing an API that feels natural across multiple languages while remaining consistent.

Python encourages one style.

C++ encourages another.

TypeScript has its own conventions.

Finding the balance between "idiomatic" and "consistent" turned out to be far more interesting than implementing the logger itself.

What's Next

I'm currently working on:

  • publishing LogX on language-specific package managers
  • improving consistency across implementations
  • expanding test coverage
  • adding more examples
  • benchmarking performance
  • collecting feedback from developers

The project is still evolving, and I'd genuinely appreciate suggestions.

Especially if there's something in the API that feels awkward or unintuitive.

Final Thoughts

I don't think every project needs a full logging framework.

Sometimes you just want something you can drop into your project and immediately start using.

That's the experience I wanted LogX to provide.

If that sounds useful to you, I'd love to hear your thoughts.

⭐ GitHub

https://github.com/ka1rav6/logx

Feedback, criticism, feature requests, and pull requests are always welcome.

If you end up using LogX in one of your projects, I'd love to hear about it!

Top comments (0)