I am creating the Klogging logging library in Kotlin. There is also an SLF4J binding and a Spring Boot Starter. Currently it supports Splunk, Graylog and Seq destinations directly. Let me know if you try it and if you find it useful (or not!).

There were a lot of attempts into multiplatform logging in Kotlin. For example https://github.com/MicroUtils/kotlin-logging. I do not see any need of a new library unless you fix some of critical issues with exiting ones. For example kotlin-logging is not published for all required platforms. Obviously your variant does not even support JS-IR to say nothing about all native targets publication. How will you address that?

There's been some behind-the-scenes work going on recently related to logging, trying to get a more "standard" logging library established to cut back on the sprawl of single-purpose loggers and avoid confusion for beginners. You can read our discussions here, including the most recent work done to make Touchlab's Kermit the favored library https://github.com/copper-leaf/clog/discussions/7#discussioncomment-1387404 I'd encourage you to consider contributing some of these features to Kermit instead! https://github.com/touchlab/Kermit

Kermit looks fine. At least it covers all platforms. I am not a fun of single letter shortcuts, but it does not really matter.

neither I am, if I were to use Kermit I’d define aliases for info, warn, etc.

@altavir kotlin-logging is a shim on top of SLF4J, which binds to Logback by default. Logback has limitations, including having structured events as an afterthought (MDC is clumsy to use compared to coroutine contexts) and timestamp precision limited to milliseconds.

@Michael Strasser the problem is that nobody needs logging API which is not widely accepted. SLF4J works because everybody use it and it has connectors for those who don't. It does not make sense to create "yet another logging framework", you should work together with other people working on similar things to at least create a universal API. SPI is currently not available on MPP, but you can use manual selection of logger provider instead and do something like SLF4J.

@altavir Klogging provides a binding for SLF4J so users can keep using that API. Klogging’s own API is based on SLF4J and kotlin-logging, so I have not invented much new. I believe Klogging’s back-end is better than the Java alternatives (native structured logging with message templates, finer resolution of timestamps). I have spent enough hours trawling through logs written by myself and others to have thought about this quite a lot.

It does not matter how good is your backend if your logging library won't be used by anyone else because of compatibility issues (you can't load two different libraries with different logging frameworks. Well, you can, but it is not pleasant). So instead of doing yet another logging library, better to sit together with other people and create one to rule them all. You can contribute your better solutions there. Or save people from doing some mistakes. I am old enough to remember Java ecosystem logging hell. And you are currently doing exactly the same mistake.