Direction for the Project

[daboross]

I've been a relatively inconsistent maintainer, and in my estimation this crate is of decreasing and decreasing relevance.

For one, tracing has largely superceded the log crate fern is based on. Don't get me wrong - you can use log, but I don't know why you would.

The biggest value for fern I can see is in it still being maintained for crates already using it. It was released back before 1.0 when we didn't even have a log crate, and it still works largely the same way today.

I've been considering what to do with this crate, and I have some ideas:

1. One-stop easy-to-use CLI logging

   I think it'd be neat if we could consume tracing events, have default formatting available within the crate, and simplify common use cases.

   This would be aiming for what I originally built fern for, but today.

2. Increase efficiency further

   fern has a decently nice feature: an allocation-free logging pipeline.

   Owning up, I have absolutely no idea how useful nor important this is. Especially with modern
   allocators, allocations are cheap.

   However, it's a fun challenge - and we can do a lot more today without allocation. I'd really love to make a lot of fern configuration const-compatible, and allow creating loggers without allocations as well as running loggers without allocations.

   It's unclear how much would need to change in this project to do that, nor how much this would
   conflict with 1.

3. Keep things as they are, let fern fade further away

   Keep maintaining fern, update as we update dependencies. Maybe switch to new dependent crates
   when relevant, but otherwise don't really overhaul the crate.

   I don't know who would find fern useful, but it would at least still be here for familiarity.

4. Hand this off to a maintainer with a different grand vision

   Critical to all of this is one fact: I don't use fern anymore. I mean, I don't write a lot of CLI programs right now, but even if I did, my tastes have changed: I'm almost always going to reach for env_logger and ask the user to interface with that & figure it out, rather than use fern and write a command option myself.

   If I could find someone who A) seems somewhat established, B) prefers high-configuration crates, and C) has the time, I'd love to give someone else leeway to take fern and turn it into it's best self.

To close, I also just want to ask. If anyone's reading this, and uses fern: what's the reason?

Like, I am glad it's used. I even think it's still decently good, even if not with the best underpinnings anymore.

Did you find a tutorial & copy fern usage from there? Were you looking at logging crates, and liked this one more? Or is there some feature in fern that convinced you - maybe the wide variety of backends available?

Any input, and any info, is greatly appreciated. I'd love to understand who's using fern today more, so even without usin git myself, I could direct the project towards a useful end.

[MultisampledNight]

Personally fern is more or less just a thing of the past for me, too. I used it in a project which isn't my responsibility anymore and I think it's used there to this day, but also only because there were no large changes necessary for that application.

Today I'd indeed just grab tracing and some subscriber to go with it, depending on the stack.

I'd find the 1st option absolutely amazing — I love fern's high configurability! And I'd love to see a tracing::Subscriber impl in fern, maybe not with the same API but still with control of what goes where.