There’s still no good logging library 😮 And almost all of them synchronously write IO to console which is not nice with coroutines, or performance in general.

whats wrong with log4j2?

uhm. It’s for Java

🤷 you can still use it from Kotlin and based on their performance benchmarks I am unsure whether you could easily get to that level

I’m more interested in Kotlin-like interface (e.g. inline fun so that I don’t have check log level manually), multiplatform & coroutines support.

Create it!

Wrapping log4j2 seems like an easy task

@ilya.gorbunov Is that (logging library) something we can expect in kotlinx in 1-2 years? Asking to know if we should make a library in the community.

@hallvard yeah that’s probably what I’m going to do. But just a simple one. I find something like log4j wayyy to overpowered for most software. Once you’ve grown your product so much that you require all that functionality you can still change library. Or we provide generic extension points and others can extend it. I had to write simple logging classes for me already so I can just package that as one of too many libraries 😄

interesting, does anyone have some logger (even like prototype), based on coroutines? And why you really need it based on them?

Because logging is blocking IO and shouldn’t happen on the thread where you create a log entry. It could temporarily block arbitraty coroutine dispatchers. Therefore my logger prepares the log message, sends it through a channel to the IO dispatcher and logs it there.

Doesn't Lgback permit something similar? If I remember correctly, there's a setting named immediateFlush or somthing, that could be set to false ...

I won’t use any Java logger without wrapping anyway. I’d always have to check something like

if (logger.isTraceEnabled) { logger.trace(…) }

which I don’t need if I use Kotlin inline functions:

log.trace { … }

.

I understand that it's IO, but why coroutines? on JVM loggers will handle that on their own, on JS - single thread, only on native, you can push messages to worker, to unload current worker as I see, coroutines, will not give here much sense

I won’t create my own threads unless I really have to. Coroutines are widely available now so why still use threads?

So you want to use your own JVM logger implementation, based on coroutines, or what? If you will anyway push to slf4j, it will be handled automatically by using some AsyncLogger, that will handle context switch and no blocking will be

slf4j is just one option for forwarding if you have to. I’d prefer to have a multiplatform logging library that works consistently across all platforms, is simple with a well-design API for Kotlin. With no external dependencies.

With no external dependencies.

use java.util.logging for jvm + some async handler that will use coroutines if needed Im just not sure, that coroutines are needed for logging, but it's just my opinion BTW, Im also now trying to create some flexible common logger 🙂

it would be cool to see a multiplatform logging library, that just delegates to an slf4j implementation in jvm, but then has other implementations for other platforms

@wakingrufus Look at microutils/kotlin-logging for that

oh nice i didnt realize it was multiplatform. i have only used the jvm flavor of that

It happened not so long ago But anyway, it supports only desktop native targets

As a user of such a library, I would like to be able to log from not only

suspend

functions. Therefore the library's API should not be based on coroutines. And as a user of such a library I don't care what is used under the hood. I'm ok using it if it has good performance.

@Arkadii Ivanov Logging should not delay program operation, so even from suspending functions, you wouldn't want that. However, using channels to send/offer the values, and managing log output with coroutines is perfectly fine.

@Arkadii Ivanov the log functions wouldn’t need to be

suspend

if you use coroutines because you can use either Channels or

GlobalScope

.

Using coroutines as well as any other async/background library is totally fine in a logging library. What I want to say is I don't care what is used inside, as long as it works fast. I would not choose a logging library just because it is based on coroutines. Actually my benchmarks shown not a good results for native coroutines in some cases. So a simple Worker with a custom queue might work even better.

True, however logging is a I/O intensive task which Coroutines is designed for.