I was surprised that this didn’t have anything to do with CPU registers.
I like the way this information is presented. In particular I appreciate when a framework adequately describes why something works by enumerating all of its variants and then can use that same exhaustive enumeration to show what is missing.
Also this is the first time seeing the idea of Ok-wrapping which I think I love. I struggled with error returning functions for the longest time in Rust. I paired with a co-worker who reminded me of some of those difficulties today. Treating the success case as an auto wrap feels closer to an exception like experience (for example in Ruby). But with Result level control. It doesn’t really change much about how you would code the internals but it feels more intuitive.
The only major downside is that it would be yet another dialect/register to learn as learners would encounter both and eventually have to know both. I feel like I’m this case though exposure to one (Ok-wrapping) would give a better mental model for understanding working with Result directly.
This reminds of the story how unix won over some other OS (forgot the name). When a program failed, unix simply returned non-zero exit code, whereas other OS tried to do something smart. This something smart was never completely implemented before the OS died and unix took over the world. The end.
IIUC, “OK-wrapping”, implemented in the author’s fehler library, is the inverse of do yeet syntax, is that correct? At first glance, it seems like Ok-wrapping would be more useful than do yeet since you would still have to write Ok(_) for the happy paths with do yeet.
This is a very detailed post, and an interesting way to look at difference between programming languages and their features. I wonder if there’s some way to formalize this method of analysis, in the way we formalize semantics and type systems.
I was surprised that this didn’t have anything to do with CPU registers.
I like the way this information is presented. In particular I appreciate when a framework adequately describes why something works by enumerating all of its variants and then can use that same exhaustive enumeration to show what is missing.
Also this is the first time seeing the idea of Ok-wrapping which I think I love. I struggled with error returning functions for the longest time in Rust. I paired with a co-worker who reminded me of some of those difficulties today. Treating the success case as an auto wrap feels closer to an exception like experience (for example in Ruby). But with Result level control. It doesn’t really change much about how you would code the internals but it feels more intuitive.
The only major downside is that it would be yet another dialect/register to learn as learners would encounter both and eventually have to know both. I feel like I’m this case though exposure to one (Ok-wrapping) would give a better mental model for understanding working with Result directly.
This reminds of the story how unix won over some other OS (forgot the name). When a program failed, unix simply returned non-zero exit code, whereas other OS tried to do something smart. This something smart was never completely implemented before the OS died and unix took over the world. The end.
IIUC, “OK-wrapping”, implemented in the author’s fehler library, is the inverse of
do yeetsyntax, is that correct? At first glance, it seems like Ok-wrapping would be more useful thando yeetsince you would still have to writeOk(_)for the happy paths withdo yeet.This is a very detailed post, and an interesting way to look at difference between programming languages and their features. I wonder if there’s some way to formalize this method of analysis, in the way we formalize semantics and type systems.