[more-nitor]

hmm this might be solved in some simple ways:

1. create `with_err` function: some_mayerr_func().with_err_log()?

2. add 'newbie beginner mode(default)' / 'expert mode (optimized)' for rust:

- current Rust default is a bit too focused on code-optimization, too much so that it defaults to removing backtrace

- default should be 'show every backtrace even for handled errors (in my code, not the lib code -- bonus points for "is handled" checkbox)'

[Expurple]

Could you elaborate on your first idea? I don't understand it.

Your second idea is interesting, but I feel like it would be too magical for Rust. You fundamentally need a Backtrace field to add backtraces to your error types. Adding an invisible, inaccessible, always-implicitly-initialized field sounds too weird and non-Rusty to me. The language doesn't have anything like that right now.

Also, which types should even get this special field? Every type that implements the Error trait? Again, it's a very weird special case full of magic.

[more-nitor]

there's ("I'm hoping someone would...") phrase omitted here...

> (I'm hoping someone would) create `with_err` function: some_mayerr_func().with_err_log()

> (I'm hoping someone would) add 'newbie beginner mode(default)' / 'expert mode (optimized)' for rust

about: Adding an invisible, inaccessible, always-implicitly-initialized field sounds too weird and non-Rusty to me

maybe rust-devs are too focused on "zero-cost abstraction"? I mean, if I'm building for embedded sys, I have to make sure I don't waste any ram... but for other cases like web-server dev, it's much better to have some-cost abstraction that helps debugging

(this might actually be one of the reason rust isn't used a lot despite having an extremely good language basis/growth -- other one being async cancellation...)

[Expurple]

To me, it's less about memory usage and performance, and more about language simplicity and constistency (which is another big advantage of Rust, although many people would disagree with me on this).

> this might actually be one of the reason rust isn't used a lot despite having an extremely good language basis/growth

I think, it's mostly these two things:

1. Rust is not suited for a certain exploratory style of programming that many people prefer. It's more suited for writing robust production systems and infrastructure software (which together can still be a large niche).

2. But the ecosystem isn't quite there yet, to justify using it in production over the alternatives. I guess, unless the alternatives are C/C++ and their existing libraries aren't crucial to the domain :D