Thanks for the insight, I wasn't aware of `track_caller`. I'll definitely be looking into this. I was scratching my head trying to figure out how to make file and line number usage consistent and customizable, this looks like the answer!
You're also right that this will pretty much eliminate the need for macros.
That's also a very key insight about Display vs. Debug printing. I'll be looking into that as well.
Anyhow still makes things easier for application development. The main drawback is that the resulting error type doesn't implement std::error::Error, so it's not suitable for library development (as pointed out in the anyhow documentation). Stack Error is a bit less ergonomic, but suitable for library development.
I played around a bit with SNAFU a couple of years ago, but I'm haven't worked deeply with the library so there might well be some features I'm not aware of.
I think SNAFU is more like a combination of anyhow and thiserror into a single crate, rather than Stack Error which leans more heavily into the "turnkey" error struct. Using the Whatever struct, you get some overlap with Stack Error features:
- Error message are co-located.
- Error type implement std::error::Error (suitable for library development).
- External errors can be wrapped and context can easily be added.
Where Stack Error differs:
- Error codes (and URIs) offer ability for runtime error handling without having to compare strings.
- Provides pseudo-stack by stacking messages.
Underlying this is an opinion I baked into Stack Error: error messages are for debugging, not for runtime error handling. Otherwise all your error strings effectively become part of your public interface since a downstream library can rely on them for error handling.
Stack Error is a pragmatic error handling library for Rust that provides helpful messages for debugging, and structured data for runtime error handling.
Features:
- Informative error messages: stack error messages and optionally add file/line context to your messages. This helps convey not just what went wrong, but also how it went wrong, making debugging faster.
- Programmatic error handling: include optional error codes and URIs for robust runtime handling.
- Library-Friendly: define custom error types easily while staying compatible with Rust’s error ecosystem.
If designing good error structures for your projects slows you down, and you need something more library-friendly and structured than anyhow, Stack Error might be what you’re looking for.
This gets discussed in the Roc community. They are exploring designing a language without higher kinded polymorphism.
Here's a snippet from the Roc FAQ.
> It's impossible for a programming language to be neutral on this. If the language doesn't support HKP, nobody can implement a Monad typeclass (or equivalent) in any way that can be expected to catch on. Advocacy to add HKP to the language will inevitably follow. If the language does support HKP, one or more alternate standard libraries built around monads will inevitably follow, along with corresponding cultural changes. (See Scala for example.) Culturally, to support HKP is to take a side, and to decline to support it is also to take a side.
I feel like adding HKP isn't "taking a side" nearly as much as not adding HKP to turn people away because you don't like their cultural contribution.
By adding the feature you aren't actually excluding the people who don't want to use it. They are free to avoid it and maintain parallel ecosystems where HKP is avoided.
You are only excluding them if the standard library forces them to interact with HKP code, which arguably Haskell does, and it makes a PITA for teaching it.
Haskell however isn't doing it with the intention of exclusion.
On the other hand, not adding the feature because you don't like the culture it brings is intentionally exclusionary. You're intentionally taking a side against certain kinds of people and the certain kinds of code they want to be able to express without repetition... and you're hamstringing the expressibility of your language to do it.
I completely understand wanting to avoid HKP for teaching purposes, but maybe that is a problem that could better be resolved by always providing monomorphic options for standard library functions....
But avoiding HKP to avoid a certain kind of culture? Well now it's personal!
As the FAQ entry notes, one of the "sides" in the design space here is "a fragmented ecosystem is best because there's no other way to accommodate the variety of different styles people want to use" - this is a totally reasonable preference to have!
Still, hopefully it's clear why a language designer might want to go down a different path. After all, it's also totally reasonable to prefer an ecosystem which isn't fragmented along these lines (the way it is in, say, Scala) even though it means fewer different programming styles are supported.
Unfortunately you can ask Clint to tell you just about anything. But fortunately it will at least try to tell you that some things are less plausible than others.
Clint should be used only to research information. It provides links to resources. It uses Retrieval Augmented Generation which is less prone providing incorrect information, though it can still happen.
Thank you! That's great feedback. Clint is very much a proof-of-concept, I'm sure this idea can be taken much further when done properly. But to get a "pretty neat" from an RN feels like an accomplishment xD.
I see what you mean about going down the wrong path. I can explore a couple of modifications to help it have better context of the conversation as a whole.
You're also right that this will pretty much eliminate the need for macros.
That's also a very key insight about Display vs. Debug printing. I'll be looking into that as well.
Thank you for the thoughtful reply.