> the `anyhow` crate is basically mandatory from an ergonomics standpoint in every Rust project I start

If you use `anyhow`, then all you know is that the function may `Err`, but you do not know how - this is no better than calling a function that may `throw` any kind of `Throwable`. Not saying it's bad, it is just not that much different from the error handling in Kotlin or C#.

I know a ‘C’ code base that treats all socket errors the same and just retries for a limited time. However there are errors that make no sense to retry, like invalid socket or socket not connected. It is necessary to know what socket error occurred. I like how the Posix API defines an errno and documents the values. Of course this depends on accurate documentation.

This is an IDE/documentation problem in a lot of cases though. No one writes code badly intentionally, but we are time constrained - tracking down every type of error which can happen and what it means is time consuming and you're likely to get it wrong.

Whereas going with "I probably want to retry a few times" is guessing that most of your problems are the common case, but you're not entirely sure the platform you're on will emit non-commoncases with sane semantics.

Yeah, `anyhow` is basically Go error handling.

Better than C, sufficient in most cases if you're writing an app, to be avoided if you're writing a lib. There are alternatives such as `snafu` or `thiserror` that are better if you need to actually catch the error.

Yes. I prefer ‘snafu’ but there are a few, and you could always roll your own.

Yeah, with SNAFU I try to encourage people going all-in on very fine-grained error types. I love it (unsurprisingly).

+1 for snafu. It lets you blend anyhow style errors for application code with precise errors for library code. .context/.with_context is also a lovely way to propagate errors between different Result types.

How does that compare to "this error for libraries and anyhow for applications"?

You don't have to keep converting between error types :)

To be pedantic, concurrency in OCaml has been fine with lwt. Single threaded concurrency, not unlike how JS does it.

Saw this on Twitter a while ago:

https://www.tracingwoodgrains.com/p/reliable-sources-how-wik...

I don't think I've seen salt compartments in dishwashers in North America.

I have one in mine. though it's a bosch which is german owned.

Only Bosch and Miele have them, that I've seen.

"Fast" in title. But I don't see any benchmarks, or discussion on how to reason about the performance of STM code.

> how that ties in with subtyping

In Swift it does not. But in Kotlin, `String?` is not an enum (sum type), but instead means `String | null`, a union type.

In other words, this remove slop creators' ability to waste a minute of my life with bait. How is that not a good thing?

I grew up hearing about Java vulnerabilities over and over before I really learned programming, so I could not point to any specific ones. But this discussion expresses the same sentiment: https://security.stackexchange.com/questions/57646/why-do-i-...

Will we still have compiler plugins? What will this mean for projects like ts-patch?

I think I've seen somebody compared lettuce and raw milk to argue that the latter isn't too bad.