> I know that this is a fairly contrarian take, but I strongly believe than the emphasis on idiomatism is more harm than good. My response is that adherence to

> I know that this is a fairly contrarian take, but I strongly believe than the emphasis on idiomatism is more harm than good. My response is that adherence to common idioms is simultaneously beneficial and harmful. It is beneficial because shared assumptions and shared understanding facilitate cooperation, yet it is harmful because it impedes innovation. Whether it is more beneficial or more harmful on balance depends on the situation and on individual taste. I'd like to think that our perspectives are compatible. > > Not having to deal with "invisible control flow" in Rust is one of the things that makes me much more confident that the code actually does what it looks like it does. > no, you just choose to ignore it. I guess you could characterize things that way. For example, in the Rust library code I write, I choose to ignore certain unrecoverable errors — e.g. out-of-memory panics from allocating ordinary sized objects, even though such panics can theoretically occur. But the distinction here is that I also expect e.g. invalid argument values or "file not found" errors to be handled via Rust's Result type. I don't choose to ignore such events — I expect all recoverable errors to be handled via visible control flow, where you can identify every location in the code that such an error might occur. This makes it easier to reason about control flow for all circumstances save unrecoverable errors. > My sweet spot is to have a few catch handlers around the main loop which catch 99% of the unrecoverable issues Yes, that's an Anders-Hejlsberg-endorsed way of doing things. "The exception handling should be centralized, and you should just protect yourself as the exceptions propagate out to the handler." https://www.artima.com/articles/the-trouble-with-checked-exceptions#part2 https://www.artima.com/articles/the-trouble-with-checked-exc... I think the preference for one way of doing things can depend on what problem domain you work in. That approach is highly suitable for applications programming. (Duffy has done a lot of work on operating systems; my biggest projects have been libraries.) > Consultants sure do love selling it as one though. EDIT: I'm not very happy about that take, and I originally wrote up a lengthy response — but it turns out I had incorrectly recalled that this was not the first such interaction we've had. (I was recalling an obnoxious post from a different European with the first initial "j"). I've deleted my response because it's OT and not worth dealing with if it's not something recurring.