wrapcheck VS Bunyan

This is such an infuriating problem. I'm convinced I'm using Go wrong, because I simply can't understand how this doesn't make it a toy language. Why the $expletive am I wasting 20-30 and more minutes per week of my life looking for the source of an error!?

Have you seen https://github.com/tomarrell/wrapcheck? It's a linter than does a fairly good job of warning when an error originates from an external package but hasn't been wrapped in your codebase to make it unique or stacktraced. It comes with https://github.com/golangci/golangci-lint and can even be made part of your in-editor LSP diagnostics.

But still, it's not perfect. And so I remain convinced that I'm misunderstanding something fundamental about the language because not being able to consistently find the source of an error is such an egregious failing for a programming language.

If you're curious to read more, you can have a read here: https://blog.tomarrell.com/post/introducing_wrapcheck_linter_for_go

NodeJS -> Pino, Winston, Bunyan, Npmlog, e.t.c.

Bunyan is also another popular and fast JSON Node.js logging library. Just like Winston, it also supports logging into multiple transport options. Other features include a neat-printing CLI for logs, a log filter, serializers for rendering objects, snooping system, and the ability to support multiple runtime environments such as NW.js and WebPack. Bunyan enforces the JSON format for logs.

bunyan argues that logs should be structured and that JSON is a good format for that. It describes itself as a “simple and fast JSON logging library” and has all the features you would expect from a logging library, including serializers and support for different runtime environments including Node.js, Browserify and Webpack.

Suppose that after some time you decide that the winston logger library was not the best logger for your project and you want to use Bunyan, what do you do? You just need to create a BunyanLogger class that implements the ILogger interface and it is ready to be used by the UserService.

Bunyan: Another popular logging library that outputs in JSON by default.

bunyan

Are there more options? Absolutely: Bunyan, Pino, and others. It depends on what your particular logging needs are.

With the increasing number of requests and possibly errors, we needed a proper logging setup to debug and monitor the service. That’s why we chose bunyan to log insightful data in our application. These logs sit conveniently on our new logging pipeline running on EFK (or, Elasticsearch Fluentd Kibana) stack. While this deserves a separate blog post on its own, let’s take a brief look at how the logs travel from our application to the kibana dashboard.

Bunyan — Another feature-rich logging framework that outputs in JSON by default and provides a CLI tool for viewing your logs.