skrger

It's very hard to impossible to really judge based on these short examples but I can totally relate to both of you. E.g. if you see a feature that seems to be free in terms of coding it is very hard to resist offering it. If you do that over and over you realize there are at least two problems with this:

* It's never free. Do you have tests for this? + it will restrict your way you can refactor the code.

* Product features are not always good, product complexity is actually a bad thing and it is unlikely that you don't increase it.

That said, it will make some users happy, so it may be worth it - all I'm saying is that this should be a conscious decision, it isn't a no-brainer.

Well it is a deliberate choice, calling it a feature may still be a stretch. The log becomes unreadable because if you have many Rails instances (Like 25 unicorn workers in my case) writing unbuffered in one log file it becomes a holy mess. This is happening only in production because you usually don't have multiple workers in development and you also don't have hundreds of requests per second.

I think you have to add some code flushing the BufferedLogger after each request to really get the old behavior.

But this is not my point, for me rails has been about sane defaults - this is what makes it fun to start and easy to work with. I just don't see why we fix something that is not broken at all.