RVS_UIKit_Toolbox VS SLF4J

> I don't think I could in good conscience recommend your approach as a general practice.

I can live with that, but ... (There's always a "but")

I am not happy at all, with the general industry practice of writing every project to be something that can be understood by inexperienced, undisciplined coders.

Every language and programming methodology has an "advanced" type of thing, requiring people to have experience and/or book-larnin'.

I write Swift at a fairly advanced level. I am not at the level of some heavy-duty advanced Swift people, but I am pretty "idiomatic," in my approach. It is not "rewritten TypeScript," like so much code out there.

My code is very well-documented, and I hold myself to standards of Quality that most folks in the industry consider to be obsessive to the point of insanity. My testing code usually dwarfs my implementation code, and my documentation is, let's say ... complete. You can see what I mean in my latest module[0].

I won't write junk, so that someone used to junk, can comprehend it. If people aren't willing to learn enough to understand my middle-of-the-road semi-advanced Swift, then I can't help them. Swift is an awesome language. I feel that we are doing ourselves a disservice, if we do not explore it.

I write for myself. I write code and documentation that I want to use (and I use it). I really don't care, whether or not someone else "approves" of it. I am not relying on others to review, maintain, or patch my code.

When I do use other people's code, I vet it fairly carefully. Including a dependency is a really serious matter. I'm handing full control of my execution context to code that someone else wrote. I'd damn well better take that Responsibility seriously.

[0] https://github.com/RiftValleySoftware/RVS_UIKit_Toolbox

A few years ago, my team moved from Java to Go. Working on Go projects, we encountered a wide variety of logging frameworks with different APIs, configuration, and formatting. We soon found ourselves longing for a logging abstraction layer like Java’s slf4j, which had proven invaluable for use in reusable libraries or configuring and debugging production systems. So, not long after moving to Go, we began working toward replacing what we had lost in slf4j.

I'm not familiar with Serilog as I code mostly in Java, use slf4j (logs to stdout) and our apps send logs to Cloudwatch using the task definition's awslogs configuration. I prefer it this way because I can customize the log configurations in my task definitions. Also the default stream name has this format prefix-name/container-name/ecs-task-id so I can easily identify the logs of the task I want to look at. I haven't experienced any downsides with this approach and our apps publish a shit ton of logs. Cloudwatch approach looks like you can customize the stream name?

slf4j is open source. You can look at the code.

Java -> Logback, Log4j2, JDK (Java Util Logging), Slf4j, e.t.c.

slf4j para padronização dos logs;

SLF4J

> My God. Logging in protobuf?

Yes, or any other data format and/or transport protocol.

I'm surprised this is up for debate.

> Logging is the lowest of all debugging utilities - its the first thing you ever do writing software - “hello world”. And, while I admire structural logging, the truth is printing strings remains (truly) the lowest common denominator across software developers.

This sort of comment is terribly miopic. You can have a logging API, and then configure your logging to transport the events anywhere, any way. This is a terribly basic feature and requirement, and one that comes out of the box with some systems. Check how SLF4J[1] is pervasive in Java, and how any SLF4J implementation offers logging to stdout or a local file as a very specific and basic usecase.

It turns out that nowadays most developers write software that runs on many computers that aren't stashed over or under their desks, and thus they need efficient and convenient ways to check what's happening either in a node or in all deployments.

[1] https://www.slf4j.org/