11–20 of 28 posts
Earlier quoted context omitted.
Cognitive load is more expensive than compilation time.
Compilation time turns into cognitive load via frustration. Death by a thousand cuts.
I have never seen anything use Result , that is such an anti-rust thing to start with.
I have never seen an actual Rist programmer do this, and that was clue #1 that TFA was AI generated without review.
Earlier quoted context omitted.
Cognitive load is more expensive than compilation time.
Compilation time turns into cognitive load via frustration. Death by a thousand cuts.
(compilation time is good for brain switch off time - i.e. reducing cognitive load).
This just feels like recreating exceptions, but with more complicated syntax.
I mean broadly that's my entire problem with errors as values: every implementation wastes a ton of syntax trying to make them like exceptions.
I have never seen anything use Result , that is such an anti-rust thing to start with.
LLMs love to do this. I assume they are trying to write JavaScript or Python or whatever, but in Rust. I have never seen an actual Rist programmer do this, and that was clue #1 that TFA was AI generated without review.
How is this different from the even more ergonomic “#[from]” provided by thiserror?
Are all of these proc macros worth it? The compile times for proc macros explode. I'd rather hand-roll errors than deal with more proc macros. Or better yet, have code gen pay the cost once and never deal with it again.
This just feels like recreating exceptions, but with more complicated syntax.
Rust used to be pretty hard to read and write, now with ai coding agent not anymore.
Earlier quoted context omitted.
I mean broadly that's my entire problem with errors as values: every implementation wastes a ton of syntax trying to make them like exceptions.
The common problems with exceptions isn’t the easy part of try/catch, it’s the execution model and “any function could throw” that causes most contention. Error values are logically simpler and fully document if and what errors the function can return. Checked exceptions solve that too, but in practice nobody used them even where available. And you still end up with hidden control flow with exceptions, the exceptiona…
Most functional-inspired languages would just have a single `f: T -> Result` interface, which supports both (1) a specific error type `E`, which can also be an uninhabited type (e.g. never type) for an infallible operation, and (2) where `U` can be the unit type if the function doesn't return anything on success. That's about as generic as one can get with a single "interface" type.
[1]: https://docs.spring.io/spring-framework/docs/current/javadoc...