I agree with the overall sentiment, that ergonomics should not come at the cost of less safety or correctness. However, two of the three examples, I would actua

I agree with the overall sentiment, that ergonomics should not come at the cost of less safety or correctness. However, two of the three examples, I would actually consider to be _unergonomic_. Specifically, empty/null values and exceptions. For small code examples they might seem ergonomic at first glance, but from esperience with large projects in scala, java, and c++. The actually add writing code more difficult (at least if you care about handling error cases at all). Regarding null, I think it is much more economic to work with an Option or Maybe type, with operations like `map`, `unwrap_or`, and pattern matching than checking if values are null all over the place. Not to mention that if values can be null, you have to know the details of any function you call to know if you need to worry about null values at all. See https://www.lucidchart.com/techblog/2015/08/31/the-worst-mistake-of-computer-science/ https://www.lucidchart.com/techblog/2015/08/31/the-worst-mis... for more on how terrible null is. Likewise with exception systems, in large codebases you end up with try/catch statements all over the place, because it's hard to know if the functions you are calling will throw an exception, and even if you know they don't _now_, maybe someone will add a throw later. With explicit result types, you know if you need to handle errors or not, and that won't change unless the signature of the function changes. As for implicit type conversion, the example in the OP is obviously bad. But I don't think it sacrifices safety to allow implicit conversions for widening integer or floating point types, such as widening u32 to u64 or f32 to f64 (but not u32 to i32, i32 to u64, etc. I think u32 to i64 would be ok, but I'm not 100% sure).