Live data from Hacker News

‘Woof’, a pure Scala 3 logging library

medium.com

11–20 of 50 posts

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

#11
post #7

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 wor…

As an observer of this exact phenomenon, I suggest that it is due to the culture that comes with scala. In any given scala-centric organization, there's going to eventually be someone who has mastered the art of talking High Scala. Unless there is someone equally skilled on both dimensions (persuasion and SW eng), and unfortunately, someone approximately as senior, then there is an interative game where added abstraction and complexity become the primary way to distinguish yourself as a "real" engineer.

This happens outside of scala shops, and I've seen it there, too, especially in C++ shops, but scala seems to attract these people.

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

#12
post #10

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.

Sadly the effect system isn't granular to narrow down what effect is happening other than "IO", which could be logging, network, disk access, rm -rf /. And without that visibility it doesn't provide you much advantage.

Haskell similarly suffers, I'd like to see IO broken down into composable units of functionality so I can see if e.g. my logging library has some ridiculous network constraint.

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

#13
post #10

Earlier quoted context omitted.

> 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.

Sadly the effect system isn't granular to narrow down what effect is happening other than "IO", which could be logging, network, disk access, rm -rf /. And without that visibility it doesn't provide you much advantage. Haskell similarly suffers, I'd like to see IO broken down into composable units of functionality so I can see if e.g. my logging library has some ridiculous network constraint.

I suspect the same re: this library: IO is indeed too broad, and a logging system needs to do IO.

You could use other monads though.

> Haskell similarly suffers

Haskell practitioners aim to write as much code as possible outside the IO monad. If everything you write lives inside that monad, what's the benefit?

The nice thing about Haskell is that if you write every function with IO in its signature, it's bound to raise eyebrows in code reviews, whereas in most other mainstream languages everything lives in an IO monad by default!

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

#14
post #7

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 wor…

This problem with the scala community exists because it is composed of two different philosophical schools of thought. There's the ML camp, which is where we get all of the awesome pragmatic features of the ML family of languages (Martin Odersky has been very clear that Scala is philosophically an ML-family language).

And then we get the Haskell camp, which rightly determined that the Haskell ecosystem was terrible. But instead of adopting an ML mindset of pragmatic functional programming, they decided to bring along their puritan religiosity with them and make the Scala ecosystem terrible too.

The funny thing about Scala's pure functional programming ecosystem is that in its quest to make all programs pure in the sense of not having side effects, they pollute the entire ecosystem with hordes of incompatible dependencies, which need all sorts of bullshit adapters to make them play nice with each other. A far cry from what most people think of with the word "pure".

To quote one of the best essays on the ML philosophy:

> My point is that the ML module system can be deployed by you to impose the sorts of effect segregation imposed on you by default in Haskell. There is nothing special about Haskell that makes this possible, and nothing special about ML that inhibits it. It’s all a mode of use of modules.

> So why don’t we do this by default? Because it’s not such a great idea. Yes, I know it sounds wonderful at first, but then you realize that it’s pretty horrible. Once you’re in the IO monad, you’re stuck there forever, and are reduced to Algol-style imperative programming. You cannot easily convert between functional and monadic style without a radical restructuring of code. And you are deprived of the useful concept of a benign effect.

https://existentialtype.wordpress.com/2011/05/01/of-course-m...

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

#15
There is also https://github.com/valskalla/odin for a pure/fp Scala logging library (also includes a slf4j bridge if you need to work with java stuff)

It also has some "fancy" features like changing log level if exception happens

https://github.com/valskalla/odin#extras-conditional-logging

Though we have not yet upgraded it to Scala 3 it should work with Scala 3 just fine. (We do compile a Scala 3 release of most of the stuff but the codebase itself is mostly Scala 2 for now)

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

#16
post #7

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 wor…

As an observer of this exact phenomenon, I suggest that it is due to the culture that comes with scala. In any given scala-centric organization, there's going to eventually be someone who has mastered the art of talking High Scala. Unless there is someone equally skilled on both dimensions (persuasion and SW eng), and unfortunately, someone approximately as senior, then there is an interative game where added abstrac…

Erik Meijer, one of the early practitioners and contributors of Scala, and a coauthor of Odersky's Coursera courses on Scala, believes that

"Mostly Functional Programming Doesn't Work" [1]

Note it's "mostly functional" that doesn't work, not functional. He believes you have to go all in to reap its benefits, other way you're just deluding yourself with another faddish "miracle cure".

All of the above are Meijer's opinions, I'm just the messenger. I know Odersky doesn't share these opinions.

My own opinion: I'm unsure. Though I wonder, these days if you're not a strong FP advocate, and instead look to Scala as an improved Java, why not use Kotlin instead?

[1] https://queue.acm.org/detail.cfm?id=2611829

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

#17
post #9

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?

the so called "purity" is achieved by using a higher kinded type and the cats IO monad. it's like adding "1+1" with a "mathematical-calculation-monoid-combine-factory-builder-singleton-locator-evaluator-pattern". I remember keeping it simple as an ultimate goal but maybe I am just too for this FP peeing contest? why is it such a frickin' deal to log a message somewhere?

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

#18
post #9

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?

It's using IO monads

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

#19
post #9

Earlier quoted context omitted.

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?

the so called "purity" is achieved by using a higher kinded type and the cats IO monad. it's like adding "1+1" with a "mathematical-calculation-monoid-combine-factory-builder-singleton-locator-evaluator-pattern". I remember keeping it simple as an ultimate goal but maybe I am just too for this FP peeing contest? why is it such a frickin' deal to log a message somewhere?

> I remember keeping it simple as an ultimate goal but maybe I am just too for this FP peeing contest? why is it such a frickin' deal to log a message somewhere?

Don't know about others but for me it is about being able to easily verify that my logging is setup correctly.

Once you write your logging to some monad (the library we use does not require it to be IO) testing it becomes trivial with a WriterT monad where it just write your logs into some list/buffer and check that what was logged in various cases was actually what you wanted.

We do the same with tracing checking that spans are created as we wanted and the tags/logs on the spans are setup correctly.

Post reply on HN