4 ms·

The alternative is to either stifle improvements, or to bloat the language. And we all know what that looks like looks at C++ I personally am happy they're mak

• dikaiosune 11y ago
  You don't need breaking changes to get many benefits of a language like swift - for example rust has had very little breakage since hitting 1.0.
  • wallacoloo 11y ago
    Thanks for bringing rust into the discussion - they handle language standardization/evolution very effectively, in my opinion. "Experimental" features are added to the language, but they are all effectively #define-gated for at least one release before being concretized (it's done more pragmatically than a literal #define of course, given that rust doesn't have any concept of #defines). This makes sense in my opinion because it gives an opportunity to evaluate proposed language changes under real-world use-cases before making it official, and people must explicitly opt into the possibility of their code not working with future releases, thus fully knowing and accepting the risks.
• edgyswingset 11y ago
  >I personally am happy they're making backwards-incompatible changes, and I hope they always continue doing that. At the very early stages of the language, sure. But ten years down the line with significant assets in Swift? I think your opinion will change.
• yxhuvud 11y ago
  There are more alternatives to handle this. For example, the language could provide a tool that does any rewriting for you.
  • manmal 11y ago
    XCode has migrations for stuff they break. They are not perfect, but most of the time, they work.