Cool, thanks. I mostly want to make sure we don't have any blind spots here; this is an issue we care about deeply. I think it's also important to remember that even languages which are known for "no breaking changes" do introduce breaking changes. Take Java for example, known for being an exemplar in this space.
> However, implementation of some Java SE 8 features required changes that could
> cause code that compiled with Java SE 7 to fail to compile with Java SE 8.
Especially in a statically-typed language, technically breaking changes are a fact of life. The key is to make them as minimal as possible, so that you don't struggle to update.
(Oh, and glad to hear you like the errors: we're actually working on making them even better. Elm is really leading the way here...)
Between Rust's and Elm's error messages, Go's focus on compilation speed, and even GCC's improvements in diagnostics, I'm really enjoying this focus on developer UX I see. It's made me more UX-conscious in my own tools.
Especially in a statically-typed language, technically breaking changes are a fact of life. The key is to make them as minimal as possible, so that you don't struggle to update.
(Oh, and glad to hear you like the errors: we're actually working on making them even better. Elm is really leading the way here...)