8 ms·

Swift's Evolution

106 points by carpeaqua 9y ago

coldcode 9y ago
I use Swift daily in a mixed application of both languages. I worked with ObjC since back in the NeXT days and I used to like the language but today nothing could ever drive me back. Xcode on the other hand is nightmare I despise daily but that's a different issue. The sooner ObjC goes away the better.
- protomyth 9y ago
  I'm the exact opposite. I have been forcing myself to use Swift daily to rewrite utilities and help with an iOS app. I hate their take on the Smalltalk-style selector (the unnecessary parentheses is a pain) and other parts of the language. I'll use it, but it is much like Transact-SQL or Perl was for me (become an expert but not really like the language or programming in it).
- AsyncAwait 9y ago
  Swift on iOS and Kotlin on Android are a great update from their predecessors both in terms of syntax and safety, (Optionals etc.), which I really appreciate. I also like how they both provide just enough functional tools to be interesting and useful, yet at the same time remain firmly in the familiar OO land, makes the adoption cost a lot lower.
- Larrikin 9y ago
  After developing Android apps for a while and finally taking an iOS class, XCode felt like such a step back compared to Android Studio. I ended up downloading AppCode and only using XCode for UI related task.
AlexeyBrin 9y ago
The biggest problem Swift has is breaking changes from a version to another. Took me about 10 days to manually convert a Swift 2.5 project to Swift 3 to find out that Swift 4 will also introduce at least two breaking changes. I'm all for progress and modern ideas in a programming language, just don't break my old code!
- timjver 9y ago
  They were pretty clear about this from the beginning... Sometimes you need to break a few things here and there to make it a more pleasant language for the decades to come.
  - oscargrouch 9y ago
    And for the skeptics, C++ evolution is a strong statement for why keeping old cruft just for the sake of the early adopters maybe is not the right thing to do. I prefer the Swift way, and had to move 2ish to 3ish code myself and it didnt suck that bad.
- AsyncAwait 9y ago
  > I'm all for progress and modern ideas in a programming language, just don't break my old code! I doubt that they want to, but it is really hard to redesign something you didn't get right the first time in a programming language, without breaking some code. The choice is then to leave the bad design as is, but be stuck with it for the next few decades, (which would be kind of terrible, given Swift was meant to eventually replace ObjC precisely because of this), or you can suffer the pain now, while relatively early, to not have to suffer latter. I think they made the right choice, in terms of prioritising long-term benefit over short-term gain. ObjC is still fully supported for those who want it and in the meantime, we can get a more perfect Swift.
ebbv 9y ago
The author says they lost a week of their life to the Swift 3 renaming but wasn't there a utility that helped with that? I agree that Swift has seemed to been infected with the disease so many open source projects get; focusing on over polishing instead of big picture and innovation but it's still my favorite new language. Edit: I missed the author mentioning the utility sucked. Sorry!
- huxley 9y ago
  He mentions it: "The migration tool caused more issues than it automatically resolved, leaving a manual migration as the only sane path forward. How that migration tool ever made it through QA is beyond me, but I'd have felt better if Apple just said 'good luck' instead of offering a half-baked utility."
- clouddrover 9y ago
  > but wasn't there a utility that helped with that? Yes, but in the article he writes, "The migration tool caused more issues than it automatically resolved, leaving a manual migration as the only sane path forward."
- AlexeyBrin 9y ago
  For small projects and if you don't use third party libraries (who doesn't ?) the Xcode migration assistant may work. Otherwise, manually doing the conversion is the law of the land.
- protomyth 9y ago
  The automated tool couldn't even automate the conversion of the Apple examples on their developer cleanly. Those examples were fundamental demonstrations (e.g. table with views), so that indicates a pretty big problem if you are trying for a complicated app. It also makes it difficult for people just starting.
sheeshkebab 9y ago
And I thought 2017 is the year when I start a new app in swift... guess will be sticking to objc and react native depending on what makes sense where.
- andreasley 9y ago
  Just give it a try. While Swift is not perfect, it really is great for macOS/iOS development and continuously getting better. I'd never go back to ObjC.
- leeter 9y ago
  as much as I like swift, wait for it to become stable. Don't subject yourself to the pain yet. That said do take advantage of using literally all the things that have been added to Objective-C for compatibility as they provide useful information and diagnostics.
  - valuearb 9y ago
    It is stable. I would wager that more people are building professional apps in Swift today than Objective C.
    - sheeshkebab 9y ago
      While renaming for loops? Even js is more stable than this...
- nicky0 9y ago
  I'm with you. I see few advantages of switching my large existing codebase to swift, only disadvantages. Maybe in a few years the balance will change.
  - orbitur 9y ago
    > I see few advantages of switching my large existing codebase to swift There are none. Don't transition an existing, stable ObjC project. I don't understand why this is a thought anyone would entertain, especially since ObjC itself isn't going anywhere. If you are starting a new project in Swift and it will be pure Swift, that's fine. Go for it. Do not attempt to migrate existing ObjC projects or use Swift in them.
eggy 9y ago
Will Kotlin Native be able to compete with Swift on iOS? The syntax is very similar and it would make for a nice cross platform PL. I was holding off on Swift to see where it was going, but I'd like to add iOS to my dev targets. Objective-C was too verbose for me years ago, but I've heard it has changed a bunch.
- tyingq 9y ago
  At some point it looks like Dart and Flutter might be an option as well. Though with emulated widgets vs native.
- htormey 9y ago
  I don't think so. Mobile development is almost more about the underlying frameworks than the language itself. At some point Kotlin etc will have to wrap these things. The internal apple swift dev team will always be one step ahead of them as they will have access to the new frameworks before they are released to the public. Also swift and kotlin are very similar. The folks from kickstarter gave a great presentation about their android/iOS app being written in Swift/Kotlin at a conference I spoke at (UIkonf). Their whole mobile team writes/reviews for both platforms.
- lazerwalker 9y ago
  On a technical level, it's easy to see how someone might ship a Kotlin compiler that targets LLVM the same way you can e.g. C# via Xamarin. Practically, though, any solution like that is going to be a second-class citizen in a world where Apple jumps and you ask how high. Xamarin's a great example here, even if Kotlin might be sexier as a language: there are certainly teams building good native iOS apps using Xamarin / C#, but it's hard to see it ever being anything more than a niche tool.
- virtualwhys 9y ago
  Kotlin Native doesn't exist beyond pre-alpha software at this point, so the the question is a bit premature. In 3-5 years Kotlin might be where Swift is now, but there's nothing guaranteed, just coming up with a GC solution alone is a gigantic engineering effort -- Kotlin, like Scala, Clojure, etc. all benefit from world class GCs, just by being hosted on the JVM. With LLVM you essentially start from scratch, same for porting Java libraries, there's a ton of work involved. tl;dr; for now it's separate languages for iOS and Android unless you cut some corners with React Native to avoid writing the same app twice.
brutus1213 9y ago
This post hits it right on ... the renaming thing and the removal of traditional for loops ... I'm just bewildered by it. When I saw it, my reaction was ... WHY??? The incompatibilities between swift 2 and swift 3 made me thankful I did not invest the language prior to 3. While I stepped into it at this point, and think the language has a lot of potential (not changing the damn language .. I mean having a large eco system of useful libraries around it). Apple still has an opportunity if they don't screw it up further.
- chrisoverzero 9y ago
  > the removal of traditional for loops […] When I saw it, my reaction was ... WHY??? For all of these reasons, at least: https://github.com/apple/swift-evolution/blob/master/proposals/0007-remove-c-style-for-loops.md https://github.com/apple/swift-evolution/blob/master/proposa...
  - pscarey 9y ago
    Thanks for sharing that link. I found it quite an interesting read. (I much prefer Swift to ObjC after a conversion of about 10k lines in an iOS app). C style for loops come pretty early in most programming tutorials, but I wonder how much non-C programming does actually use them nowadays (from the Community Responses, it seems not much Swift courtesy of other options). Usually, a C style for would be to loop over an array, and a safer way to do that probably could have stopped countless vulnerabilities & bugs occurring over the years.
    - masklinn 9y ago
      > C style for loops come pretty early in most programming tutorials Meh. Many languages don't have c-style for loops in the first place. Neither Python nor Ruby do for instance. I don't think Rust ever had them either[0]. [0] https://www.reddit.com/r/rust/comments/2957fg/can_i_request_a_c_style_for_loop/ https://www.reddit.com/r/rust/comments/2957fg/can_i_request_...
      - 9y ago
bsaul 9y ago
I'm actually pretty happy swift moves the server side story forward, because i'm convinced the "next big language" will have to run on mobile and server. Actually, i think they don't go fast enough, especially regarding concurrency ( which on the server goes beyond just providing async await, as lattner said they were aiming at something closer to the actor model). I don't think the "maybe objc is still relevant for new project" trend we've been seeing the last few months on HN is going anywhere. I'm currently in the process of converting a large codebase from objc to swift, and there is absolutely no doubt that the language is WAY better, and brings a lot of safety enhancements as well. The only big remaining pain point now is clearly in the tooling, but now that they're stabilized the language a bit more, it's probably going to get better fast.
- andybak 9y ago
  > because i'm convinced the "next big language" will have to run on mobile and server Wouldn't it also need to be cross-platform in that case? It's sad that Kotlin and Swift are so similar but not similar enough. (Although I'd prefer a dynamic language to be the "next big language" - it seems the pendulum is currently swinging back towards static typing...)
  - jnbiche 9y ago
    > Wouldn't it also need to be cross-platform in that case? Swift is absolutely cross-platform. I've used it a lot on Linux. I think I even prefer it to Rust for things like server applications. I think Swift may even be available on Windows now. But it's definitely available and rapidly maturing on Linux. And having struggled with large code bases in dynamic languages for years, I'm very happy that statically-typed languages are resurgent now.
    - valuearb 9y ago
      I would like to see Swift for WebAssembly
- ngrilly 9y ago
  > which on the server goes beyond just providing async await, as lattner said they were aiming at something closer to the actor model I'd be interested in further information about this, if you can share some link here.
deleted 9y ago
[deleted]
RamenJunkie_ 9y ago
No mention of when it manifested human form and became a successful pop singer.
jcizzle 9y ago
If you follow the Apple dev community, there is a group of folks that make their living on books and speaking. That's fine, but they are using the platform differently than someone shipping software. They are also often the authors of some of the more ideological, less pragmatic proposals. This has a large impact on the disconnect the author describes - which incurs a cost on folks who ship software. I do wish the Swift team said no more often, but as with any dependency, you're never gonna get 100% alignment.
- mikeash 9y ago
  Maybe I'm in the wrong part of the Apple dev community, but I don't know of anyone who makes a living on books and speaking. I know many who write books and do a lot of speaking, but there isn't enough money in it for it to be anything more than a side gig.
  - plorkyeran 9y ago
    Yeah, there's certainly some people who would like to make a living on books and speaking, but every single one of them that I know of has a job as an iOS (or macOS) developer of some sort and no one's even in the range where they can pretend that maybe one day they'll be able to quit their day job.
  - mpweiher 9y ago
    I thought so as well, but apparently the Swift transition has enabled at least a bit of this. Yay! :-)
AsyncAwait 9y ago
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.
asveikau 9y ago
Very distracted by the lack of the accusative case in the name of the site. Unless he is instructing the water to seize, I think it should be carpe aquam.
aaronbrethorst 9y ago
> The biggest travesty was the "Great Renaming" which touched every line of Swift code I had and burned a week of my life on tedium The sheer amount of churn in Swift between v1 and v3 was what has kept me on the sidelines. It was only that Apple plainly stated last summer that they were done radically changing the language that I was willing to get into Swift at all.
dep_b 9y ago
I didn't have a really rough time with the Big Rename but some subtle differences bit me, simply the way how strings are constructed for example: var someId: Int! ... let urlString = "\(baseUrl)/\(route)/\(someId)" Result in Swift 2: "http://ac.me/products/123" result in Swift 3: "http://ac.me/products/Optional(123)" Happy hunting! Some of this ended up in production :( They've changed it to a warning in later versions of Xcode 8 at least. But that was too late for me. Apart from that it's a big step forward, less wordy than Objective-C yet it's still "readable language" instead of a bunch of almost random generic English words. I'm not sure about async / await. Whenever I deal with it in .Net languages I never find it that intuitive compared to blocks. But you know every programmer suffers from Stockholm Syndrome at least a bit so it could just be my mind warped to not only accepting but even glorifying the flaws in a language. There are people out there that genuinely like JavaScript for instance!
- eschaton 9y ago
  You should be using the methods on the URL struct to compose a URL, rather than string interpolation. You wouldn't use string interpolation or concatenation to compose an SQL query, would you?
  - rudedogg 9y ago
    What's the advantage of using URL versus strings? The networking libraries I've worked with just use string interpolation: https://github.com/Moya/Moya/blob/master/docs/Targets.md https://github.com/Moya/Moya/blob/master/docs/Targets.md https://github.com/Alamofire/Alamofire#routing-requests https://github.com/Alamofire/Alamofire#routing-requests
  - dep_b 9y ago
    Actually it's behaviour seemed to be geared more towards debugging than actual string formatting. The expected behaviour should be either a compile error, or the value when it's set and nothing, nil or None if it would be allowed to compile.
jordansmithnz 9y ago
The author mentions that Apple often nudge their idea of the future forward each year at WWDC. I see no different with Swift: the introduction of Playgrounds, teaching resources, finesse over small details, etc - to me indicate Apple wants to make this a language that the next generation of developers grow up learning and using. Quite a good move on their part if it is successful. If kids start learning Swift at school, they get exposed to Apple devices (not necessarily but this is where the teaching resources are aiming), and they've got developers in their arena from an early age. Yeah, Swift needs ABI stability, but I also understand that they don't want to screw it up by adding it too soon. Because the goal of Swift seems more long term oriented, short term ABI stability isn't worth risking a 10 year goal for.
- Someone 9y ago
  "Quite a good move on their part if it is successful." I haven't used it, nor do I work in education, but what I have read of it, it at least is successful in the sense that those who use Apple's Swift training material find it to have good quality. For example, http://www.speirs.org/blog/2017/6/1/a-year-of-teaching-swift http://www.speirs.org/blog/2017/6/1/a-year-of-teaching-swift: "In times past the experience was that, if you were an able student in Computing, you would get your programs working. If you were not an able student, your experience would be almost insurmountable challenges to get anything working. Working or not-working was the differentiator in the class. In the Learn to Code curriculum, I found that everyone got something working. The difference between the stronger students and the weaker students then was more to do with evaluations of the complexity of their solution, the understandability and style of their solutions or other factors like memory and time efficiency. I have never really had these kinds of conversations in classes at this level before. It has been an incredibly satisfying year to get the opportunity to debate which of three possible solutions is the 'best' for a given problem and, further, what definition of 'best' we should accept." It also is good to see that Apple expands its offering. https://www.apple.com/newsroom/2017/06/swift-playgrounds-expands-coding-education-to-robots-drones-and-musical-instruments/ https://www.apple.com/newsroom/2017/06/swift-playgrounds-exp...: "Apple is working with leading device makers to make it easy to connect to Bluetooth-enabled robots within the Swift Playgrounds app, allowing kids to program and control popular devices, including LEGO MINDSTORMS Education EV3, the Sphero SPRK+, Parrot drones and more. The Swift Playgrounds 1.5 update will be available as a free download on the App Store beginning Monday, June 5."
y_u_no_rust 9y ago
Man why is Apple still around?
mpweiher 9y ago
"Apple's path with Swift doesn't seem to solve the problems I have as a day-to-day iOS developer. " That's the key take-away for me. Of course Swift has an easier time with some syntactic issues than Objective-C, which is two languages crashed into each other. And yes, Objective-C was way, way overdue for a better replacement. Heck, just dropping the "C" part from the language syntax and reducing it to type annotations in a nice typed Smalltalk (see Strongtalk, or TS) would have fit the bill. It's not as if there aren't lots of problems (and your list will almost certainly be different). For example, applications are no longer just code, non-code resources are just as important, but support for them is at best rudimentary. So with pluggable scheme handlers and polymorphic identifiers, we could write checkBoxImage := img:checkbox. And have the "img" scheme handler statically check resource availability against a list automatically imported from Xcode's resources (pluggable, see F# type providers). Of course, the internet also happened, so shoppingPage := http://amazon.com/ should also work, because why should obtaining resources outside your machine have so much extra ceremony. Abstracting should of course also work: scheme:amazon := ref:http://amazon.com asScheme shoppingPage := amazon:/ And of course you can compose scheme handlers, so you add JSON or XML decoding and then use the resulting scheme handlers as if the original data source Then there is keeping UI and model in sync. There were bindings, but these were hacky, somewhat unreliably, undebuggable etc. Much better to generalize and integrate a constraint mechanism into the language: -<void>setupTemperatureConverter { ivar:f |= (9.0/5.0) * ivar:c + 32 . ivar:c |= (ivar:f - 32) * (5.0/9.0). ivar:k |= ivar:c + 273. ivar:c |= ivar:k - 273. ivar:c =|= ivar:celsiusTextField/intValue. ivar:f =|= ivar:fahrenheitTextField/intValue. ivar:k =|= ivar:kelvinTextField/intValue. } That's actual code for a temperature converter app, setting up relationships that get automatically maintained. And if you make constraint handling support pluggable as you should, you also have a proper syntax for writing autolayout constraints. And Makefiles. Together with composable scheme handlers (see above), this gets rid of the vast majority of your view controller code. Then there's the nib vs code dance. Or storyboards. All semi-solutions to problems that are largely (but not entirely) architectural in nature. All can be aided tremendously by good linguistic support, putting to rest many of the recurring problems we have with these technologies (or conversely with not adopting them). Swift does nothing for any of this.
bernadus_edwin 9y ago
Nothing wrong with swift but the build tool team. I can tolerate method name convention that always changing. And also still not support async await. Xcode build tool is the worst. Compiler time is the most hurt. Very slow. Android, react and xamarin already support hot swap compile. Migration tool is not working. I'm not sure this year xcode able to refactoring rename method
minmaxmux 9y ago
I was happy using early swift.. but now it start to be pain a bit.. i liked more early version. Somehow too verbose and clomsy language.
minmaxmux 9y ago
After every update old code do not work.. aaargh! Thats reslly time consuming..

106 points by carpeaqua 9y ago

I use Swift daily in a mixed application of both languages. I worked with ObjC since back in the NeXT days and I used to like the language but today nothing could ever drive me back. Xcode on the other hand is nightmare I despise daily but that's a different issue. The sooner ObjC goes away the better.

protomyth 9y ago
I'm the exact opposite. I have been forcing myself to use Swift daily to rewrite utilities and help with an iOS app. I hate their take on the Smalltalk-style selector (the unnecessary parentheses is a pain) and other parts of the language. I'll use it, but it is much like Transact-SQL or Perl was for me (become an expert but not really like the language or programming in it).
AsyncAwait 9y ago
Swift on iOS and Kotlin on Android are a great update from their predecessors both in terms of syntax and safety, (Optionals etc.), which I really appreciate. I also like how they both provide just enough functional tools to be interesting and useful, yet at the same time remain firmly in the familiar OO land, makes the adoption cost a lot lower.
Larrikin 9y ago
After developing Android apps for a while and finally taking an iOS class, XCode felt like such a step back compared to Android Studio. I ended up downloading AppCode and only using XCode for UI related task.

AlexeyBrin 9y ago

The biggest problem Swift has is breaking changes from a version to another. Took me about 10 days to manually convert a Swift 2.5 project to Swift 3 to find out that Swift 4 will also introduce at least two breaking changes. I'm all for progress and modern ideas in a programming language, just don't break my old code!

timjver 9y ago
They were pretty clear about this from the beginning... Sometimes you need to break a few things here and there to make it a more pleasant language for the decades to come.
- oscargrouch 9y ago
  And for the skeptics, C++ evolution is a strong statement for why keeping old cruft just for the sake of the early adopters maybe is not the right thing to do. I prefer the Swift way, and had to move 2ish to 3ish code myself and it didnt suck that bad.
AsyncAwait 9y ago
> I'm all for progress and modern ideas in a programming language, just don't break my old code! I doubt that they want to, but it is really hard to redesign something you didn't get right the first time in a programming language, without breaking some code. The choice is then to leave the bad design as is, but be stuck with it for the next few decades, (which would be kind of terrible, given Swift was meant to eventually replace ObjC precisely because of this), or you can suffer the pain now, while relatively early, to not have to suffer latter. I think they made the right choice, in terms of prioritising long-term benefit over short-term gain. ObjC is still fully supported for those who want it and in the meantime, we can get a more perfect Swift.

ebbv 9y ago

The author says they lost a week of their life to the Swift 3 renaming but wasn't there a utility that helped with that? I agree that Swift has seemed to been infected with the disease so many open source projects get; focusing on over polishing instead of big picture and innovation but it's still my favorite new language. Edit: I missed the author mentioning the utility sucked. Sorry!

huxley 9y ago
He mentions it: "The migration tool caused more issues than it automatically resolved, leaving a manual migration as the only sane path forward. How that migration tool ever made it through QA is beyond me, but I'd have felt better if Apple just said 'good luck' instead of offering a half-baked utility."
clouddrover 9y ago
> but wasn't there a utility that helped with that? Yes, but in the article he writes, "The migration tool caused more issues than it automatically resolved, leaving a manual migration as the only sane path forward."
AlexeyBrin 9y ago
For small projects and if you don't use third party libraries (who doesn't ?) the Xcode migration assistant may work. Otherwise, manually doing the conversion is the law of the land.
protomyth 9y ago
The automated tool couldn't even automate the conversion of the Apple examples on their developer cleanly. Those examples were fundamental demonstrations (e.g. table with views), so that indicates a pretty big problem if you are trying for a complicated app. It also makes it difficult for people just starting.

sheeshkebab 9y ago

And I thought 2017 is the year when I start a new app in swift... guess will be sticking to objc and react native depending on what makes sense where.

andreasley 9y ago
Just give it a try. While Swift is not perfect, it really is great for macOS/iOS development and continuously getting better. I'd never go back to ObjC.
leeter 9y ago
as much as I like swift, wait for it to become stable. Don't subject yourself to the pain yet. That said do take advantage of using literally all the things that have been added to Objective-C for compatibility as they provide useful information and diagnostics.
- valuearb 9y ago
  It is stable. I would wager that more people are building professional apps in Swift today than Objective C.
  - sheeshkebab 9y ago
    While renaming for loops? Even js is more stable than this...
nicky0 9y ago
I'm with you. I see few advantages of switching my large existing codebase to swift, only disadvantages. Maybe in a few years the balance will change.
- orbitur 9y ago
  > I see few advantages of switching my large existing codebase to swift There are none. Don't transition an existing, stable ObjC project. I don't understand why this is a thought anyone would entertain, especially since ObjC itself isn't going anywhere. If you are starting a new project in Swift and it will be pure Swift, that's fine. Go for it. Do not attempt to migrate existing ObjC projects or use Swift in them.

eggy 9y ago

Will Kotlin Native be able to compete with Swift on iOS? The syntax is very similar and it would make for a nice cross platform PL. I was holding off on Swift to see where it was going, but I'd like to add iOS to my dev targets. Objective-C was too verbose for me years ago, but I've heard it has changed a bunch.

tyingq 9y ago
At some point it looks like Dart and Flutter might be an option as well. Though with emulated widgets vs native.
htormey 9y ago
I don't think so. Mobile development is almost more about the underlying frameworks than the language itself. At some point Kotlin etc will have to wrap these things. The internal apple swift dev team will always be one step ahead of them as they will have access to the new frameworks before they are released to the public. Also swift and kotlin are very similar. The folks from kickstarter gave a great presentation about their android/iOS app being written in Swift/Kotlin at a conference I spoke at (UIkonf). Their whole mobile team writes/reviews for both platforms.
lazerwalker 9y ago
On a technical level, it's easy to see how someone might ship a Kotlin compiler that targets LLVM the same way you can e.g. C# via Xamarin. Practically, though, any solution like that is going to be a second-class citizen in a world where Apple jumps and you ask how high. Xamarin's a great example here, even if Kotlin might be sexier as a language: there are certainly teams building good native iOS apps using Xamarin / C#, but it's hard to see it ever being anything more than a niche tool.
virtualwhys 9y ago
Kotlin Native doesn't exist beyond pre-alpha software at this point, so the the question is a bit premature. In 3-5 years Kotlin might be where Swift is now, but there's nothing guaranteed, just coming up with a GC solution alone is a gigantic engineering effort -- Kotlin, like Scala, Clojure, etc. all benefit from world class GCs, just by being hosted on the JVM. With LLVM you essentially start from scratch, same for porting Java libraries, there's a ton of work involved. tl;dr; for now it's separate languages for iOS and Android unless you cut some corners with React Native to avoid writing the same app twice.

brutus1213 9y ago

This post hits it right on ... the renaming thing and the removal of traditional for loops ... I'm just bewildered by it. When I saw it, my reaction was ... WHY??? The incompatibilities between swift 2 and swift 3 made me thankful I did not invest the language prior to 3. While I stepped into it at this point, and think the language has a lot of potential (not changing the damn language .. I mean having a large eco system of useful libraries around it). Apple still has an opportunity if they don't screw it up further.

chrisoverzero 9y ago
> the removal of traditional for loops […] When I saw it, my reaction was ... WHY??? For all of these reasons, at least: https://github.com/apple/swift-evolution/blob/master/proposals/0007-remove-c-style-for-loops.md https://github.com/apple/swift-evolution/blob/master/proposa...
- pscarey 9y ago
  Thanks for sharing that link. I found it quite an interesting read. (I much prefer Swift to ObjC after a conversion of about 10k lines in an iOS app). C style for loops come pretty early in most programming tutorials, but I wonder how much non-C programming does actually use them nowadays (from the Community Responses, it seems not much Swift courtesy of other options). Usually, a C style for would be to loop over an array, and a safer way to do that probably could have stopped countless vulnerabilities & bugs occurring over the years.
  - masklinn 9y ago
    > C style for loops come pretty early in most programming tutorials Meh. Many languages don't have c-style for loops in the first place. Neither Python nor Ruby do for instance. I don't think Rust ever had them either[0]. [0] https://www.reddit.com/r/rust/comments/2957fg/can_i_request_a_c_style_for_loop/ https://www.reddit.com/r/rust/comments/2957fg/can_i_request_...
    - 9y ago

bsaul 9y ago

I'm actually pretty happy swift moves the server side story forward, because i'm convinced the "next big language" will have to run on mobile and server. Actually, i think they don't go fast enough, especially regarding concurrency ( which on the server goes beyond just providing async await, as lattner said they were aiming at something closer to the actor model). I don't think the "maybe objc is still relevant for new project" trend we've been seeing the last few months on HN is going anywhere. I'm currently in the process of converting a large codebase from objc to swift, and there is absolutely no doubt that the language is WAY better, and brings a lot of safety enhancements as well. The only big remaining pain point now is clearly in the tooling, but now that they're stabilized the language a bit more, it's probably going to get better fast.

andybak 9y ago
> because i'm convinced the "next big language" will have to run on mobile and server Wouldn't it also need to be cross-platform in that case? It's sad that Kotlin and Swift are so similar but not similar enough. (Although I'd prefer a dynamic language to be the "next big language" - it seems the pendulum is currently swinging back towards static typing...)
- jnbiche 9y ago
  > Wouldn't it also need to be cross-platform in that case? Swift is absolutely cross-platform. I've used it a lot on Linux. I think I even prefer it to Rust for things like server applications. I think Swift may even be available on Windows now. But it's definitely available and rapidly maturing on Linux. And having struggled with large code bases in dynamic languages for years, I'm very happy that statically-typed languages are resurgent now.
  - valuearb 9y ago
    I would like to see Swift for WebAssembly
ngrilly 9y ago
> which on the server goes beyond just providing async await, as lattner said they were aiming at something closer to the actor model I'd be interested in further information about this, if you can share some link here.

deleted 9y ago

[deleted]

RamenJunkie_ 9y ago

No mention of when it manifested human form and became a successful pop singer.

jcizzle 9y ago

If you follow the Apple dev community, there is a group of folks that make their living on books and speaking. That's fine, but they are using the platform differently than someone shipping software. They are also often the authors of some of the more ideological, less pragmatic proposals. This has a large impact on the disconnect the author describes - which incurs a cost on folks who ship software. I do wish the Swift team said no more often, but as with any dependency, you're never gonna get 100% alignment.

mikeash 9y ago
Maybe I'm in the wrong part of the Apple dev community, but I don't know of anyone who makes a living on books and speaking. I know many who write books and do a lot of speaking, but there isn't enough money in it for it to be anything more than a side gig.
- plorkyeran 9y ago
  Yeah, there's certainly some people who would like to make a living on books and speaking, but every single one of them that I know of has a job as an iOS (or macOS) developer of some sort and no one's even in the range where they can pretend that maybe one day they'll be able to quit their day job.
- mpweiher 9y ago
  I thought so as well, but apparently the Swift transition has enabled at least a bit of this. Yay! :-)

AsyncAwait 9y ago

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.

asveikau 9y ago

Very distracted by the lack of the accusative case in the name of the site. Unless he is instructing the water to seize, I think it should be carpe aquam.

aaronbrethorst 9y ago

> The biggest travesty was the "Great Renaming" which touched every line of Swift code I had and burned a week of my life on tedium The sheer amount of churn in Swift between v1 and v3 was what has kept me on the sidelines. It was only that Apple plainly stated last summer that they were done radically changing the language that I was willing to get into Swift at all.

dep_b 9y ago

I didn't have a really rough time with the Big Rename but some subtle differences bit me, simply the way how strings are constructed for example: var someId: Int! ... let urlString = "\(baseUrl)/\(route)/\(someId)" Result in Swift 2: "http://ac.me/products/123" result in Swift 3: "http://ac.me/products/Optional(123)" Happy hunting! Some of this ended up in production :( They've changed it to a warning in later versions of Xcode 8 at least. But that was too late for me. Apart from that it's a big step forward, less wordy than Objective-C yet it's still "readable language" instead of a bunch of almost random generic English words. I'm not sure about async / await. Whenever I deal with it in .Net languages I never find it that intuitive compared to blocks. But you know every programmer suffers from Stockholm Syndrome at least a bit so it could just be my mind warped to not only accepting but even glorifying the flaws in a language. There are people out there that genuinely like JavaScript for instance!

eschaton 9y ago
You should be using the methods on the URL struct to compose a URL, rather than string interpolation. You wouldn't use string interpolation or concatenation to compose an SQL query, would you?
- rudedogg 9y ago
  What's the advantage of using URL versus strings? The networking libraries I've worked with just use string interpolation: https://github.com/Moya/Moya/blob/master/docs/Targets.md https://github.com/Moya/Moya/blob/master/docs/Targets.md https://github.com/Alamofire/Alamofire#routing-requests https://github.com/Alamofire/Alamofire#routing-requests
- dep_b 9y ago
  Actually it's behaviour seemed to be geared more towards debugging than actual string formatting. The expected behaviour should be either a compile error, or the value when it's set and nothing, nil or None if it would be allowed to compile.

jordansmithnz 9y ago

The author mentions that Apple often nudge their idea of the future forward each year at WWDC. I see no different with Swift: the introduction of Playgrounds, teaching resources, finesse over small details, etc - to me indicate Apple wants to make this a language that the next generation of developers grow up learning and using. Quite a good move on their part if it is successful. If kids start learning Swift at school, they get exposed to Apple devices (not necessarily but this is where the teaching resources are aiming), and they've got developers in their arena from an early age. Yeah, Swift needs ABI stability, but I also understand that they don't want to screw it up by adding it too soon. Because the goal of Swift seems more long term oriented, short term ABI stability isn't worth risking a 10 year goal for.

Someone 9y ago
"Quite a good move on their part if it is successful." I haven't used it, nor do I work in education, but what I have read of it, it at least is successful in the sense that those who use Apple's Swift training material find it to have good quality. For example, http://www.speirs.org/blog/2017/6/1/a-year-of-teaching-swift http://www.speirs.org/blog/2017/6/1/a-year-of-teaching-swift: "In times past the experience was that, if you were an able student in Computing, you would get your programs working. If you were not an able student, your experience would be almost insurmountable challenges to get anything working. Working or not-working was the differentiator in the class. In the Learn to Code curriculum, I found that everyone got something working. The difference between the stronger students and the weaker students then was more to do with evaluations of the complexity of their solution, the understandability and style of their solutions or other factors like memory and time efficiency. I have never really had these kinds of conversations in classes at this level before. It has been an incredibly satisfying year to get the opportunity to debate which of three possible solutions is the 'best' for a given problem and, further, what definition of 'best' we should accept." It also is good to see that Apple expands its offering. https://www.apple.com/newsroom/2017/06/swift-playgrounds-expands-coding-education-to-robots-drones-and-musical-instruments/ https://www.apple.com/newsroom/2017/06/swift-playgrounds-exp...: "Apple is working with leading device makers to make it easy to connect to Bluetooth-enabled robots within the Swift Playgrounds app, allowing kids to program and control popular devices, including LEGO MINDSTORMS Education EV3, the Sphero SPRK+, Parrot drones and more. The Swift Playgrounds 1.5 update will be available as a free download on the App Store beginning Monday, June 5."

y_u_no_rust 9y ago

Man why is Apple still around?

mpweiher 9y ago

"Apple's path with Swift doesn't seem to solve the problems I have as a day-to-day iOS developer. " That's the key take-away for me. Of course Swift has an easier time with some syntactic issues than Objective-C, which is two languages crashed into each other. And yes, Objective-C was way, way overdue for a better replacement. Heck, just dropping the "C" part from the language syntax and reducing it to type annotations in a nice typed Smalltalk (see Strongtalk, or TS) would have fit the bill. It's not as if there aren't lots of problems (and your list will almost certainly be different). For example, applications are no longer just code, non-code resources are just as important, but support for them is at best rudimentary. So with pluggable scheme handlers and polymorphic identifiers, we could write checkBoxImage := img:checkbox. And have the "img" scheme handler statically check resource availability against a list automatically imported from Xcode's resources (pluggable, see F# type providers). Of course, the internet also happened, so shoppingPage := http://amazon.com/ should also work, because why should obtaining resources outside your machine have so much extra ceremony. Abstracting should of course also work: scheme:amazon := ref:http://amazon.com asScheme shoppingPage := amazon:/ And of course you can compose scheme handlers, so you add JSON or XML decoding and then use the resulting scheme handlers as if the original data source Then there is keeping UI and model in sync. There were bindings, but these were hacky, somewhat unreliably, undebuggable etc. Much better to generalize and integrate a constraint mechanism into the language: -<void>setupTemperatureConverter { ivar:f |= (9.0/5.0) * ivar:c + 32 . ivar:c |= (ivar:f - 32) * (5.0/9.0). ivar:k |= ivar:c + 273. ivar:c |= ivar:k - 273. ivar:c =|= ivar:celsiusTextField/intValue. ivar:f =|= ivar:fahrenheitTextField/intValue. ivar:k =|= ivar:kelvinTextField/intValue. } That's actual code for a temperature converter app, setting up relationships that get automatically maintained. And if you make constraint handling support pluggable as you should, you also have a proper syntax for writing autolayout constraints. And Makefiles. Together with composable scheme handlers (see above), this gets rid of the vast majority of your view controller code. Then there's the nib vs code dance. Or storyboards. All semi-solutions to problems that are largely (but not entirely) architectural in nature. All can be aided tremendously by good linguistic support, putting to rest many of the recurring problems we have with these technologies (or conversely with not adopting them). Swift does nothing for any of this.

bernadus_edwin 9y ago

Nothing wrong with swift but the build tool team. I can tolerate method name convention that always changing. And also still not support async await. Xcode build tool is the worst. Compiler time is the most hurt. Very slow. Android, react and xamarin already support hot swap compile. Migration tool is not working. I'm not sure this year xcode able to refactoring rename method

minmaxmux 9y ago

I was happy using early swift.. but now it start to be pain a bit.. i liked more early version. Somehow too verbose and clomsy language.

minmaxmux 9y ago

After every update old code do not work.. aaargh! Thats reslly time consuming..