5 ms·

Apple already pulled the Python 3 stunt twice with swift. Swift 1 to Swift 2 to Swift 3 were all very much incompatible. Of course the language wasn’t as broad

by pilif 6y ago

Apple already pulled the Python 3 stunt twice with swift. Swift 1 to Swift 2 to Swift 3 were all very much incompatible. Of course the language wasn’t as broadly used back then and Apple is known for quicker churn than Python so the need to write code compatible across Swift versions was much less pronounced

skohan 6y ago
Swift can be very painful from this perspective. I just recently had to do surgery on a project because one of my dependencies changed the tools version. The back-compat promise is one of the reasons I'm investing in Rust for new projects, even if I find the actual programming much more pleasant in Swift. But I'm a bit less optimistic about Rust now given the recent layoffs at Mozilla.
- rapsey 6y ago
  Rust is not that dependent on Mozilla
  - skohan 6y ago
    I don’t think so either, but it does breed confidence when there is a large organization backing a project
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 pilif 6y ago

skohan 6y ago

Swift can be very painful from this perspective. I just recently had to do surgery on a project because one of my dependencies changed the tools version. The back-compat promise is one of the reasons I'm investing in Rust for new projects, even if I find the actual programming much more pleasant in Swift. But I'm a bit less optimistic about Rust now given the recent layoffs at Mozilla.

rapsey 6y ago
Rust is not that dependent on Mozilla
- skohan 6y ago
  I don’t think so either, but it does breed confidence when there is a large organization backing a project

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.