4 ms·

I haven’t used Swift heavily till recently, but didn’t they say from the beginning there would be lots of breaking changes in the first couple versions? Doesn’t

by zwily 6y ago

I haven’t used Swift heavily till recently, but didn’t they say from the beginning there would be lots of breaking changes in the first couple versions? Doesn’t make it less painful but they were at least up front about it.

fauigerzigerk 6y ago
They still don't have async-await. Once that arrives, a lot of code gets redesigned again.
- plorkyeran 6y ago
  Async/await currently looks like it'll be a non-breaking change. Obviously you'll have to redesign a whole bunch of code to actually take advantage of it, but you won't have to adopt it just to upgrade to the newest version of Swift. If you decide it's not worth the effort, you'll have the option to just not redesign anything.
  - fauigerzigerk 6y ago
    Yes, hopefully not a breaking change, but a lot of APIs and libraries will have to be redesigned completely in order to allow people to take advantage of it. And a lot of old code will look inconsistent for quite a long while. I'm a bit surprised that language support for such a key concurrency feature comes so late in the game. It's not the same issue that Yegge describes though.
    - jen20 6y ago
      “So late in the game” is relative, no? Java doesn’t have it, Rust stabilised it last year after ~9 years (or around the same time period if we’re comparing 1.0 releases). Async/await does not need to be a breaking change - C# managed fine without it being so. The breaking changes in Rust were around the standardisation of std::futures::Future rather than async and await. That said async/await makes a world of difference to the usability of Rust for async code and I’d imagine it will for Swift too.
      - steveklabnik 6y ago
        The only breaking change was that async because a keyword, the Futures stuff didn’t cause any breaking changes. There were three major versions of the library before it moved into the stdlib, though.
        jen20 6y ago
        Right, by “breaking changes” I mean across the ecosystem rather than in the Stdlib. There’s still a decent amount of code based on futures 0.1 and many libraries that depended on it required rework as a result.

by zwily 6y ago

fauigerzigerk 6y ago

They still don't have async-await. Once that arrives, a lot of code gets redesigned again.

plorkyeran 6y ago
Async/await currently looks like it'll be a non-breaking change. Obviously you'll have to redesign a whole bunch of code to actually take advantage of it, but you won't have to adopt it just to upgrade to the newest version of Swift. If you decide it's not worth the effort, you'll have the option to just not redesign anything.
- fauigerzigerk 6y ago
  Yes, hopefully not a breaking change, but a lot of APIs and libraries will have to be redesigned completely in order to allow people to take advantage of it. And a lot of old code will look inconsistent for quite a long while. I'm a bit surprised that language support for such a key concurrency feature comes so late in the game. It's not the same issue that Yegge describes though.
  - jen20 6y ago
    “So late in the game” is relative, no? Java doesn’t have it, Rust stabilised it last year after ~9 years (or around the same time period if we’re comparing 1.0 releases). Async/await does not need to be a breaking change - C# managed fine without it being so. The breaking changes in Rust were around the standardisation of std::futures::Future rather than async and await. That said async/await makes a world of difference to the usability of Rust for async code and I’d imagine it will for Swift too.
    - steveklabnik 6y ago
      The only breaking change was that async because a keyword, the Futures stuff didn’t cause any breaking changes. There were three major versions of the library before it moved into the stdlib, though.
      - jen20 6y ago
        Right, by “breaking changes” I mean across the ecosystem rather than in the Stdlib. There’s still a decent amount of code based on futures 0.1 and many libraries that depended on it required rework as a result.