6 ms·

I think the author misses the fact that Swift wasn't truly 'done' when it was introduced, (and still isn't). Objective-C had some 30+ years to evolve, but Swift

I think the author misses the fact that Swift wasn't truly 'done' when it was introduced, (and still isn't). Objective-C had some 30+ years to evolve, but Swift can't have 3? I get that if you're shipping Swift in production you want to refactor as little as possible, but it is pretty hard to come up with the ideal design straight out of the gate. Swift can stop evolving, but it will be THEN when it loses the reason to exist. If Swift is just going to be ObjC with a nicer syntax, (or the features that YOU personally find desirable), then why bother with it at all? Swift is trying to get its design right and that takes time, at the same time I wouldn't want to be stuck with a poorly designed language for the next 30 years, so it's worth the current turbulence for me. (Rust was the same way 2011-2015 to a MUCH bigger degree and it did in fact eventually stabilize as promised.) If it's that much of a problem, ObjC isn't going anywhere, it's your choice. EDIT: Fixed a typo.

nicky0 9y ago
Anyone shipping swift code one day one had to be pretty masochistic. I just couldn't understand why people were doing it. It was obviously not ready for production use, and still isn't. But I'm happy that people are playing with it and the language is being refined so that I can start using it in a few years.
- karmelapple 9y ago
  Why isn't it currently ready for production use? ABI stability is the only real issue I can see now.
  - mikeash 9y ago
    I'd say it's ready, but it's a bit iffy because of the tooling. The compiler is way too easy to crash, the debugger is often worse than useless, and larger projects can be extremely slow to build. You can put up with these, and I think it's worth the tradeoff, but you should definitely consider them carefully before putting a lot of effort into build a real-world Swift code base.
    - adamnemecek 9y ago
      > larger projects can be extremely slow to build Ironically this forced me to start using Swift Package Manager more and to split my projects into frameworks.
      - vlozko 9y ago
        Unfortunately, the rise of frameworks has led to another, often ignored problem: app startup time. Carthage and CocoaPods, while great tools, became enablers and I'm hoping static library support will be announced this WWDC.
        adamnemecek 9y ago
        I dislike both Carthage and CocoaPods with passion. Fortunately SPM doesn't link dynamically.
        orbitur 9y ago
        Too bad there's no package manager for ObjC libraries.
        adamnemecek 9y ago
        Embrace the future and never look back.
  - deleted 9y ago
    [deleted]
- melling 9y ago
  Developers are shipping both small and large projects with Swift. You may have a different opinion, for reasons that you haven't stated, but shipping production Swift apps is not an anomaly.
  - nicky0 9y ago
    It's fine if you don't mind using rudimentary, buggy tools, and converting your whole code base to the latest language changes every 6 months, and you don't mind bloating your app with a mandatory 8Mb runtime. Great for small projects, people coding for fun, learners, and early adopters/neophiles who enjoy keeping up with all the changes. But substantial projects need solid, stable tools. Swift will get there very soon, I'm sure. Admittedly I'm basing my opinion on Swift as it was about 12 months ago so hopefully someone can tell me how wrong I am and that the frequent IDE crashes and compiler bugs are fixed, refactoring is now available, autocomplete works really well, compile times have improved, and the language has no more breaking changes, etc. It's just that I have work to do and Objective C is still solid and dependable. Playing with Swift was fun but I kept running into too many yak-shaving diversions to get even basic things done. So is it time for me to switch?
    - coldtea 9y ago
      Great for small projects, people coding for fun, learners, and early adopters/neophiles who enjoy keeping up with all the changes. But substantial projects need solid, stable tools. Lots of projects more important and substantial than anything you and I have worked on have been shipped with Swift. So that argument doesn't really fly. Apps redone/adopting Swift include Twitter, Pandora, Groupon, Fitbit, etc. (Heck, major billion-dollar companies had built parts of their production infrastructure on Node when the thing was just on very early stages).
      - nicky0 9y ago
        That just shows that big companies can have poor judgment too.
- coldtea 9y ago
  >Anyone shipping swift code one day one had to be pretty masochistic. I just couldn't understand why people were doing it. It was obviously not ready for production use, and still isn't. Obviously because "production" is not some monolithic reality. What's "production" standards for NASA or Google, might not be for some small team making an iOS app or an one-person indie shop. They might prefer to experiment with the language in their app, and get a leg up on learning it starting from the initial release, even if there's gonna be pain. Even for actual commercial code, the supposed "pain" this article mentions is really nothing to write home about. Having to spend a week doing manual code changes because APIs were renamed is no biggie at all in the grand scheme of things. Contrast with whole full blown languages and libraries used in production change completely or get deprecated/abandoned. Things from Microsoft inventing new stacks and deprecating others every few years, to J2EE dropping the crappy EJBs that tons of programmers had based their code on, to React Router being redone in a new style every year, to GTK/QT N to GTL/QT N+1 transitions, ...
  - AsyncAwait 9y ago
    > They might prefer to experiment with the language in their app, and get a leg up on learning it starting from the initial release, even if there's gonna be pain. I agree, but I suppose these kinds of shops wouldn't then write blog posts complaining about this, I think the OP meant shops that do it anyway and then complain...
- valuearb 9y ago
  Because Swift 1.0 was far superior to Objective C in maintainability and code quality. Now I do admit the build times were awful and I had a couple puzzling crashers that were only cleaned up by Swift 1.2 (thankfully didn't ship till after 1.2 was final), but the transition was worth it.
  - objclxt 9y ago
    > Because Swift 1.0 was far superior to Objective C in maintainability and code quality. You can take Objective-C code written three years ago, open it up in Xcode today, and compile it. The same cannot be said for Swift. So saying Swift 1.0 was "far superior" in terms of maintainability is a bit of a stretch, in my opinion.
    - valuearb 9y ago
      Sure, in the edge case where you actually don't maintain code except for once every three years, it's closer. But even in that example, after a couple bad hours/days (given size of your project) updating your swift code, you then have many good days working in much more readable code.
      - deleted 9y ago
        [deleted]
    - dwaite 9y ago
      3 years is long enough for an Objective-C API to be deprecated and obsoleted/removed. It would also be really challenging for Swift code written 3 years ago to compile, because Swift wasn't released yet.
htormey 9y ago
Its fair to say that if you adopted Swift as soon as it was announced you should have expected some pain, especially given all the warnings Apple put out about it. I think the issue is that for the last year or two all of the tutorial websites and the third party library ecosystem have moved from Objective-C to Swift in a big way. If you are new to iOS development this might lead you to have a false sense of security with regard to the overall stability/quality of the language. Swift is a lot of fun when it works. I hope this year's WWDC will mark a big turning point for the language. Last year it was pretty painful, especially if you needed to use third party Swift libraries.
- Apocryphon 9y ago
  It's definitely annoying that most of the major online iOS learning resources are no longer updating their Objective-C material.
  - AlexeyBrin 9y ago
    Maybe it is just a question of analytics, I mean if you have a bunch of Objective-C articles with 100 readers per month and a set of Swift articles with 10000 readers per month, as an author, you will probably chose to invest your time in updating the Swift version.
deleted 9y ago
[deleted]
- deleted 9y ago
  [deleted]
kibwen 9y ago
The comparison with Rust's period of instability is very mistaken. Before 1.0 we were emphatic in telling you that you should not use Rust in a production capacity. The rust-lang.org homepage loudly proclaimed that the implementation was a prototype that would "eat your laundry". Coming into the IRC channels, anyone asking whether Rust was production-ready would be told that it wasn't, and we suggested alternative languages for those needing stability. In contrast, you don't see anyone calling Swift an experimental prototype despite it being as trigger-happy with breaking changes as ancient Rust. I take issue with the messaging that Apple has used to describe Swift's level of stability; just saying "we warned you there were going to be breaking changes :shrug:" drips with contempt. Just because one has given oneself license to break something does not mean that one should exercise that right wantonly. I do think the Swift developers are getting better about that, fortunately, but a lot of developer goodwill has been burned in the meantime.
- AsyncAwait 9y ago
  > the rust-lang.org homepage loudly proclaimed that the implementation was a prototype I get what you're saying, but a 'prototype' is perhaps a bit far. Rust was far from being called a prototype years before being declared stable, however I do agree that branding Swift 1.0 in 2014 was a mistake. Personal theory is that if you want to release something at Apple to the public, and Chris wanted to get feedback, you have to brand it 1.0 > just saying "we warned you there were going to be breaking changes :shrug:" drips with contempt Ouch, that's going a bit too far, Chris Lattner definitely doesn't strike me as someone who has contempt for developers. He gave us LLVM, (which BTW Rust uses as its backend) and by all signs he worked very hard in the background to get Swift open-sourced. Now they're taking a lot of feedback from the community via their Swift Evolution process and the Swift community wants the language to continue to evolve, so it does, not sure what could've they done better in this regard.
  - kibwen 9y ago
    Yes indeed, I don't blame Chris for any of this. Given his pedigree with LLVM, I'd believe that if he had his way Swift would have been open and available for comment from day one. I squarely blame Apple's management, a misapplied corporate culture of extreme secrecy, and an executive allergy to the word "beta" for the issues that I perceive. I apologize if it seemed that I was blaming the Swift developers themselves or denigrating their abilities.

nicky0 9y ago

Anyone shipping swift code one day one had to be pretty masochistic. I just couldn't understand why people were doing it. It was obviously not ready for production use, and still isn't. But I'm happy that people are playing with it and the language is being refined so that I can start using it in a few years.

karmelapple 9y ago
Why isn't it currently ready for production use? ABI stability is the only real issue I can see now.
- mikeash 9y ago
  I'd say it's ready, but it's a bit iffy because of the tooling. The compiler is way too easy to crash, the debugger is often worse than useless, and larger projects can be extremely slow to build. You can put up with these, and I think it's worth the tradeoff, but you should definitely consider them carefully before putting a lot of effort into build a real-world Swift code base.
  - adamnemecek 9y ago
    > larger projects can be extremely slow to build Ironically this forced me to start using Swift Package Manager more and to split my projects into frameworks.
    - vlozko 9y ago
      Unfortunately, the rise of frameworks has led to another, often ignored problem: app startup time. Carthage and CocoaPods, while great tools, became enablers and I'm hoping static library support will be announced this WWDC.
      - adamnemecek 9y ago
        I dislike both Carthage and CocoaPods with passion. Fortunately SPM doesn't link dynamically.
        orbitur 9y ago
        Too bad there's no package manager for ObjC libraries.
        adamnemecek 9y ago
        Embrace the future and never look back.
- deleted 9y ago
  [deleted]
melling 9y ago
Developers are shipping both small and large projects with Swift. You may have a different opinion, for reasons that you haven't stated, but shipping production Swift apps is not an anomaly.
- nicky0 9y ago
  It's fine if you don't mind using rudimentary, buggy tools, and converting your whole code base to the latest language changes every 6 months, and you don't mind bloating your app with a mandatory 8Mb runtime. Great for small projects, people coding for fun, learners, and early adopters/neophiles who enjoy keeping up with all the changes. But substantial projects need solid, stable tools. Swift will get there very soon, I'm sure. Admittedly I'm basing my opinion on Swift as it was about 12 months ago so hopefully someone can tell me how wrong I am and that the frequent IDE crashes and compiler bugs are fixed, refactoring is now available, autocomplete works really well, compile times have improved, and the language has no more breaking changes, etc. It's just that I have work to do and Objective C is still solid and dependable. Playing with Swift was fun but I kept running into too many yak-shaving diversions to get even basic things done. So is it time for me to switch?
  - coldtea 9y ago
    Great for small projects, people coding for fun, learners, and early adopters/neophiles who enjoy keeping up with all the changes. But substantial projects need solid, stable tools. Lots of projects more important and substantial than anything you and I have worked on have been shipped with Swift. So that argument doesn't really fly. Apps redone/adopting Swift include Twitter, Pandora, Groupon, Fitbit, etc. (Heck, major billion-dollar companies had built parts of their production infrastructure on Node when the thing was just on very early stages).
    - nicky0 9y ago
      That just shows that big companies can have poor judgment too.
coldtea 9y ago
>Anyone shipping swift code one day one had to be pretty masochistic. I just couldn't understand why people were doing it. It was obviously not ready for production use, and still isn't. Obviously because "production" is not some monolithic reality. What's "production" standards for NASA or Google, might not be for some small team making an iOS app or an one-person indie shop. They might prefer to experiment with the language in their app, and get a leg up on learning it starting from the initial release, even if there's gonna be pain. Even for actual commercial code, the supposed "pain" this article mentions is really nothing to write home about. Having to spend a week doing manual code changes because APIs were renamed is no biggie at all in the grand scheme of things. Contrast with whole full blown languages and libraries used in production change completely or get deprecated/abandoned. Things from Microsoft inventing new stacks and deprecating others every few years, to J2EE dropping the crappy EJBs that tons of programmers had based their code on, to React Router being redone in a new style every year, to GTK/QT N to GTL/QT N+1 transitions, ...
- AsyncAwait 9y ago
  > They might prefer to experiment with the language in their app, and get a leg up on learning it starting from the initial release, even if there's gonna be pain. I agree, but I suppose these kinds of shops wouldn't then write blog posts complaining about this, I think the OP meant shops that do it anyway and then complain...
valuearb 9y ago
Because Swift 1.0 was far superior to Objective C in maintainability and code quality. Now I do admit the build times were awful and I had a couple puzzling crashers that were only cleaned up by Swift 1.2 (thankfully didn't ship till after 1.2 was final), but the transition was worth it.
- objclxt 9y ago
  > Because Swift 1.0 was far superior to Objective C in maintainability and code quality. You can take Objective-C code written three years ago, open it up in Xcode today, and compile it. The same cannot be said for Swift. So saying Swift 1.0 was "far superior" in terms of maintainability is a bit of a stretch, in my opinion.
  - valuearb 9y ago
    Sure, in the edge case where you actually don't maintain code except for once every three years, it's closer. But even in that example, after a couple bad hours/days (given size of your project) updating your swift code, you then have many good days working in much more readable code.
    - deleted 9y ago
      [deleted]
  - dwaite 9y ago
    3 years is long enough for an Objective-C API to be deprecated and obsoleted/removed. It would also be really challenging for Swift code written 3 years ago to compile, because Swift wasn't released yet.

htormey 9y ago

Its fair to say that if you adopted Swift as soon as it was announced you should have expected some pain, especially given all the warnings Apple put out about it. I think the issue is that for the last year or two all of the tutorial websites and the third party library ecosystem have moved from Objective-C to Swift in a big way. If you are new to iOS development this might lead you to have a false sense of security with regard to the overall stability/quality of the language. Swift is a lot of fun when it works. I hope this year's WWDC will mark a big turning point for the language. Last year it was pretty painful, especially if you needed to use third party Swift libraries.

Apocryphon 9y ago
It's definitely annoying that most of the major online iOS learning resources are no longer updating their Objective-C material.
- AlexeyBrin 9y ago
  Maybe it is just a question of analytics, I mean if you have a bunch of Objective-C articles with 100 readers per month and a set of Swift articles with 10000 readers per month, as an author, you will probably chose to invest your time in updating the Swift version.

deleted 9y ago

[deleted]

deleted 9y ago
[deleted]

kibwen 9y ago

The comparison with Rust's period of instability is very mistaken. Before 1.0 we were emphatic in telling you that you should not use Rust in a production capacity. The rust-lang.org homepage loudly proclaimed that the implementation was a prototype that would "eat your laundry". Coming into the IRC channels, anyone asking whether Rust was production-ready would be told that it wasn't, and we suggested alternative languages for those needing stability. In contrast, you don't see anyone calling Swift an experimental prototype despite it being as trigger-happy with breaking changes as ancient Rust. I take issue with the messaging that Apple has used to describe Swift's level of stability; just saying "we warned you there were going to be breaking changes :shrug:" drips with contempt. Just because one has given oneself license to break something does not mean that one should exercise that right wantonly. I do think the Swift developers are getting better about that, fortunately, but a lot of developer goodwill has been burned in the meantime.

AsyncAwait 9y ago
> the rust-lang.org homepage loudly proclaimed that the implementation was a prototype I get what you're saying, but a 'prototype' is perhaps a bit far. Rust was far from being called a prototype years before being declared stable, however I do agree that branding Swift 1.0 in 2014 was a mistake. Personal theory is that if you want to release something at Apple to the public, and Chris wanted to get feedback, you have to brand it 1.0 > just saying "we warned you there were going to be breaking changes :shrug:" drips with contempt Ouch, that's going a bit too far, Chris Lattner definitely doesn't strike me as someone who has contempt for developers. He gave us LLVM, (which BTW Rust uses as its backend) and by all signs he worked very hard in the background to get Swift open-sourced. Now they're taking a lot of feedback from the community via their Swift Evolution process and the Swift community wants the language to continue to evolve, so it does, not sure what could've they done better in this regard.
- kibwen 9y ago
  Yes indeed, I don't blame Chris for any of this. Given his pedigree with LLVM, I'd believe that if he had his way Swift would have been open and available for comment from day one. I squarely blame Apple's management, a misapplied corporate culture of extreme secrecy, and an executive allergy to the word "beta" for the issues that I perceive. I apologize if it seemed that I was blaming the Swift developers themselves or denigrating their abilities.