I understand the reasoning for not including checked exceptions in the lang, but when it comes to java interop I need to deal with environmental errors somehow. So far I'm using my own biased Either, whose semantics I prefer over try/catch. That said, it's entirely dependent on my disciple to check if any java function I call throws some checked exception. Have any best practices emerged? Is there any linting or equivalent that can alert me to uncaught checked exceptions?

Ideally you must always keep in mind all exceptions that your code can throw, checked or not. So nothing really changed here except that propagating the exception is always the default in kotlin

this actually forces you to have a catch all somewhere whereas with Java, you were under the impression that you were catching exceptions when runtime exceptions just slipped through the cracks

@voddan The removal of checked exceptions transfers the burden from the compiler to the programmer, which is a clear loss in safety

My point is that the burden has always been on the programmer alone. The removing of checked exceptions is less about safety, and more about comfort.

It's about safety too since the compiler is no longer keeping the developer accountable

In your example with static types the compiler always knows the correct resolution - the types much or they don't. With exceptions, the resolution of a problem is always up to the developer. The developer must tell the compiler what to do with an exception - log it, ignore it, rethrow it, etc. Basically, you could substitute checked exception with a pop up agreement "Are you sure you know what to do with this and that exception", which the developer must sign "yes I do" in order for the code to compile.