5 ms·

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 product

by 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.

by nicky0 9y ago

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.