Hacker News Reader

Author here. I agree, Timbre is new, and has some rough edges, but in my projects, I've found them worth putting up with. In my current project (18k LoClojure), I think the only serious dependency I have that uses j.u.logging or SLF4J is Datomic. Timbre has an interop library that will pipe java logs through timbre.

I agree knowledge of how Java logging works is still useful, but I'm not willing to be part of the problem anymore :-)

Agreed on Schema, and how it illustrates deficiencies in the type system. I still want core.typed, or something like it, but it's too immature for production use.

Totally understood re: timbre and not being a part of the problem of the Java logging ecosystem. I'll play with it again next time I have a chance and see if the interop lib can't solve some of the issues I had before.

Yeah, the post you folks put out on core.typed last fall (https://circleci.com/blog/why-were-no-longer-using-core-type...) was certainly disappointing but not unexpected...I'm curious to see if Jaunt goes anywhere at this point too: https://www.arrdem.com/2016/02/22/clojarr_-_a_friendly_cloju...

Anyways, thanks for the piece!

Can you ELIAJPWKVLAC* why Timbre is so much better than, say, Logback? I imagine not having to write XML configuration is one thing, but what else?

* Explain Like I'm A Java Programmer Who Knows Very Little About Clojure

One other thing I will say about Schema (https://github.com/plumatic/schema): while it's a lifesaver in a lot of ways, its mere existence really does expose some of Clojure's deficiencies when it comes to the type system (or lack thereof).

What are good examples of situations where static typing is better than schemas?

I agree, both in the "mostly agree with" and disagreeing with the list regarding timbre. Adding yet another logging library to the mix doesn't fix the mess of Java logging libraries. Especially given that timbre seems to share the logging philosophy which makes Java logging such a mess in the first place; e.g., bundling an e-mail appender.

I'd personally add the potentially controvertial "prefer transducers to lazy sequences." Lazy seq laziness is a big source of errors for newbies, and even for old hands since 1.7 Iterable-backed lazy seqs have surprising chunked realization behavior. Transducers take a bit more up-front effort to gain familiarity, but then yield fewer surprises.

https://www.google.com/search?q=ml+OR+haskell+jvm

I wish more people (could afford to) vote with their feet, as it were.