3 ms·

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

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

megumax 5y ago
Never be so sure, https://twitter.com/vm_call/status/1405937492642123782 https://twitter.com/vm_call/status/1405937492642123782 .
esarbe 5y ago
Could you point to what you think is over-engineered here?
the_af 5y ago
> 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.
- discodachshund 5y ago
  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.
  - the_af 5y ago
    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!
    - thowaway202107 5y ago
      I think the point was that for that remaining bit that can’t be extracted into pure functions still is really broad in what it can do with just “IO” IO on it’s own could mean disk, network, environment variables, sub processes, etc. My take away is that they’d like to see IO defined as the union of its parts that can also be decomposed, so you’d have a DiskIO monad or ExecIO That way you can be more certain that you’re not accidentally going to do a bunch of network io before your sub process kicks off. Right now you can’t have that guarantee (out of the box, at least. idk if there’re any user land libraries to do such a thing)
      - the_af 5y ago
        Agreed, and as another person commented, a logging system doesn't actually need to live in the (too broad) IO monad.
  - still_grokking 5y ago
    Who isn't waiting to finally get an usable effect system? But there is something on the horizon for Scala: https://github.com/lampepfl/dotty/blob/release-3.1.0/docs/docs/reference/experimental/canthrow.md#outlook https://github.com/lampepfl/dotty/blob/release-3.1.0/docs/do... One can have a proper effect system on the JVM also already today with Flix: https://en.wikipedia.org/wiki/Flix_(programming_language)#Polymorphic_effects https://en.wikipedia.org/wiki/Flix_(programming_language)#Po...
pjmlp 5y ago
Ah, but does it also plug into syslog and is able do cluster logging via Sun RPC?
- the_af 5y ago
  You jest but we needed syslog in a past job so this snippet indeed wouldn't have worked. The old adage holds true: "users only need 20% of this system's features, but the problem is that every user needs a different 20%!"

megumax 5y ago

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

esarbe 5y ago

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

the_af 5y ago

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

discodachshund 5y ago
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.
- the_af 5y ago
  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!
  - thowaway202107 5y ago
    I think the point was that for that remaining bit that can’t be extracted into pure functions still is really broad in what it can do with just “IO” IO on it’s own could mean disk, network, environment variables, sub processes, etc. My take away is that they’d like to see IO defined as the union of its parts that can also be decomposed, so you’d have a DiskIO monad or ExecIO That way you can be more certain that you’re not accidentally going to do a bunch of network io before your sub process kicks off. Right now you can’t have that guarantee (out of the box, at least. idk if there’re any user land libraries to do such a thing)
    - the_af 5y ago
      Agreed, and as another person commented, a logging system doesn't actually need to live in the (too broad) IO monad.
- still_grokking 5y ago
  Who isn't waiting to finally get an usable effect system? But there is something on the horizon for Scala: https://github.com/lampepfl/dotty/blob/release-3.1.0/docs/docs/reference/experimental/canthrow.md#outlook https://github.com/lampepfl/dotty/blob/release-3.1.0/docs/do... One can have a proper effect system on the JVM also already today with Flix: https://en.wikipedia.org/wiki/Flix_(programming_language)#Polymorphic_effects https://en.wikipedia.org/wiki/Flix_(programming_language)#Po...

pjmlp 5y ago

Ah, but does it also plug into syslog and is able do cluster logging via Sun RPC?

the_af 5y ago
You jest but we needed syslog in a past job so this snippet indeed wouldn't have worked. The old adage holds true: "users only need 20% of this system's features, but the problem is that every user needs a different 20%!"