I'm seeing a few people in this thread mention checked exceptions being cruft. I haven't heard this before and was wondering about the reasoning.

Why are checked exceptions cruft?

Because in practice they lead to exceptions not being handled properly with a lot of boilerplate try catches. If you can't do anything sensible with an exception (like retry a couple of times) then they shouldn't be caught. The other alternative is chaining throws on function definitions up the call stack.

Most new libraries don't use checked exceptions. They were a good idea in theory but not in practice.

What do you think of languages like Rust, Go, or Haskell which return errors as part of the return type? That's somewhat akin to having all exceptions be checked.

This is the exact opposite of checked exceptions, it returns an error you don have to handle at all.

It turns me off go and Haskell altogether because they are languages suitable to applications. I think it's going to lead to a lot of apps in the wild ignoring errors.

Rust is a bit different because it's a systems language, it makes sense there.

I don't think it's the exact opposite at all. It forces you to "catch" the exception, but doesn't force you to do anything with it, the same as a checked exception.

Like in Go I can do:

    f, err := os.Open("foo.bar")
    

I am then free to ignore err or do something with it, but the type system forces me to at least acknowledge that it exists. It's the "compiler forces you to acknowledge the possibility of an error" that makes them pretty similar to checked exceptions in my opinion.

Yeah it's similar in that sense, but checked exceptions force you to acknowledge every type of exception that can be thrown, or one generic one. If you can't handle it then they force you to list every type of exception that can be thrown all they way up the chain.