Discussion: Use of `log/slog` for structured loggin in favor of `logrus` or `log`

[NucleoFusion]

In the Go 1.21 Update a standard logging library slog was introduced. Which is more maintained and has less overhead than logrus and more feature rich than the older log.

• Most of our commands do not have logging in them
• And those that do use logrus, which is an unnecessary dependency

PS: The following doc is the courtesy of ChatGPT.

Milestones

• Try only showing in error
• Dont show logs at all (add a Level -> NoLevel) (!verbose) (verbose, show all) - use io.Discard for no verbose
• try showing inputs on
• Remove colors except Level
• Flags logging in prerune

---

Switch from log to log/slog

Why slog is Better

The standard log package:

• Produces unstructured plain-text logs
• Has no structured key-value fields
• Limited log levels
• Hard to parse in distributed/container environments

log/slog (Go 1.21+) provides:

• Structured logging (key-value pairs)
• Built-in log levels (Debug, Info, Warn, Error)
• JSON output support
• Context-aware logging
• Extensible handlers
• Standard library (no third-party dependency)

Structured logs are easier to ingest into systems like Loki, Elasticsearch, or OpenTelemetry.

---

Key Differences

Feature	log	slog
Structured fields	No	Yes
JSON output	No	Yes
Log levels	Basic	Full support
Context support	No	Yes
Production-ready	Limited	Yes

---

Code Examples

Using log

import "log"

log.Printf("User %d logged in from %s", userID, ip)
log.Fatal("failed to connect to database")

Output:

2026/02/23 10:12:01 User 42 logged in from 192.168.0.1

---

Using slog

Basic usage:

import "log/slog"

slog.Info("User logged in",
    "user_id", userID,
    "ip", ip,
)

slog.Error("failed to connect to database",
    "err", err,
)

---

JSON Logger Setup

import (
    "log/slog"
    "os"
)

handler := slog.NewJSONHandler(os.Stdout, nil)
logger := slog.New(handler)
slog.SetDefault(logger)

Example JSON output:

{
  "time": "2026-02-23T10:12:01Z",
  "level": "INFO",
  "msg": "User logged in",
  "user_id": 42,
  "ip": "192.168.0.1"
}

Switching to slog modernizes logging, improves observability, and standardizes structured output across the project.

---

@bupd @qcserestipy what do you think?

[NucleoFusion]

We could also simplify our output-format logging with the build in JSON logger, and probably YAML as well? looking into that.

[Vad1mo]

slog is the future, it make sense to addapt and use it.

[NucleoFusion]

@Vad1mo I agree
Through some more research, we could also have structured Error Handling and not rely on cobra to do that for us.
This will be specially handy with the errors package being developed right now in #636

[vg006]

Yeah this is what we have been discussing in #635 and I have been working for a while. I support switching to slog from logrus, where we can have structured unified logging.

[NucleoFusion]

@vg006 from logrus to slog you mean?
yeah, I made this issue as a standalone from the error / logging one to better understand how this should be done, and how much we need to change.

[vg006]

Yeah, I meant switching from logrus to slog. I understand, this will be helpful for you and other maintainers to keep track of.

For the convenience, Do I need to update that proposal from Error handling + Logging to Error handling, which can be kept opened until,

1. Addition of errors package to upstream
2. Replacing the non-uniform errors messages with errors.