‘Woof’, a pure Scala 3 logging library

#1

Post by Ivoah » Fri, Dec 17, 2021, 2:36 PM UTC

‘Woof’, a pure Scala 3 logging library
medium.com

Re: ‘Woof’, a pure Scala 3 logging library

#2

Post by sg47 » Sat, Dec 18, 2021, 5:40 PM UTC

Does it have jndi support?

Re: ‘Woof’, a pure Scala 3 logging library

#3

Post by armchairhacker » Sat, Dec 18, 2021, 5:43 PM UTC

I'm sorry but I don't understand why. It seems like this falls for the same kind of over-engineering which caused log4j's issues in the first place.

> Announcing Bark! A logging library written purely in C! Blazingly fast! 0 dependencies! It even prints file and line numbers!

    #ifdef DEBUG
    #define LOG(msg, ...) printf("[__FILE__ __LINE__]: " msg, ...)
    #else
    #define LOG(msg, ...)
    #endif

Re: ‘Woof’, a pure Scala 3 logging library

#4

Post by megumax » Sat, Dec 18, 2021, 6:24 PM UTC

armchairhacker wrote: post #3

I'm sorry but I don't understand why . It seems like this falls for the same kind of over-engineering which caused log4j's issues in the first place. > Announcing Bark! A logging library written purely in C! Blazingly fast! 0 dependencies! It even prints file and line numbers! #ifdef DEBUG #define LOG(msg, ...) printf("[__FILE__ __LINE__]: " msg, ...) #else #define LOG(msg, ...) #endif

Never be so sure, https://twitter.com/vm_call/status/1405937492642123782 .

Re: ‘Woof’, a pure Scala 3 logging library

#5

Post by esarbe » Sat, Dec 18, 2021, 6:59 PM UTC

This is very exciting; one more library making use of the amazing features that come with Scala 3.

It's a beautiful and simple language, more so than Scala 2 and I cannot recommend it highly enough for many productive use-cases.

Re: ‘Woof’, a pure Scala 3 logging library

#6

Post by esarbe » Sat, Dec 18, 2021, 7:00 PM UTC

armchairhacker wrote: post #3

I'm sorry but I don't understand why . It seems like this falls for the same kind of over-engineering which caused log4j's issues in the first place. > Announcing Bark! A logging library written purely in C! Blazingly fast! 0 dependencies! It even prints file and line numbers! #ifdef DEBUG #define LOG(msg, ...) printf("[__FILE__ __LINE__]: " msg, ...) #else #define LOG(msg, ...) #endif

Could you point to what you think is over-engineered here?

Re: ‘Woof’, a pure Scala 3 logging library

#7

Post by weego » Sat, Dec 18, 2021, 7:02 PM UTC

Having been primarily a Scala dev for the last 12 years I feel like people have slowly lost their minds over what pragmatic FP in Scala should be.

People are willingly recreating the Java situation of 'I don't know the project yet but I know we need Spring!' with these ridiculous libraries from Haskell zealots for no obvious benefit.

The ergonomics of this lib out of the box are literally worse for no reason, and worse than most other existing logging libs, because of it

Re: ‘Woof’, a pure Scala 3 logging library

#8

Post by macpete42 » Sat, Dec 18, 2021, 7:06 PM UTC

I don't get it: Why do we need category theory and monads for every little fart?

Re: ‘Woof’, a pure Scala 3 logging library

#9

Post by the_af » Sat, Dec 18, 2021, 7:10 PM UTC

macpete42 wrote: post #8

I don't get it: Why do we need category theory and monads for every little fart?

Where did you read "category theory" in that article?

I'm not familiar with Woof but it looks like an attempt at writing a pure logging lib. What is wrong with that?

Re: ‘Woof’, a pure Scala 3 logging library

#10

Post by the_af » Sat, Dec 18, 2021, 7:16 PM UTC

armchairhacker wrote: post #3

I'm sorry but I don't understand why . It seems like this falls for the same kind of over-engineering which caused log4j's issues in the first place. > Announcing Bark! A logging library written purely in C! Blazingly fast! 0 dependencies! It even prints file and line numbers! #ifdef DEBUG #define LOG(msg, ...) printf("[__FILE__ __LINE__]: " msg, ...) #else #define LOG(msg, ...) #endif

> this falls for the same kind of over-engineering which caused log4j's issues in the first place

Because it uses an effects system, which are designed to control side effects like the one which caused log4j's vulnerability, it looks like a reaction against log4j, not "more of the same problem".

Whether this is a sound approach or not, I cannot say. But definitely not a case of log4j-like overengineering.