Live data from Hacker News

Swift's Evolution

carpeaqua.com

21–30 of 105 posts

Re: Swift's Evolution

#21

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.

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.

Re: Swift's Evolution

#23
post #10

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.

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.

Re: Swift's Evolution

#24
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.

Re: Swift's Evolution

#25
post #2

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.

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.

Re: Swift's Evolution

#26

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 s…

As you indicate, the renaming may be a net loss for those who have to do he renaming, but, from Apple's viewpoint, is more than offset by the expected gains when writing new code by both current developers (where the gain may be small, zero, or even negative because they already are familiar with the API) and developers yet to start using Swift.

So, the question should be whether Apple should have prioritized new users of the language over their existing language users. I think they made the right call, more so because they pre-announced it. Not only didn't they claim the language was frozen, the specifically said it would see changes.

Re: Swift's Evolution

#27
post #20

Earlier quoted context omitted.

> 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/proposa...

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…

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

Re: Swift's Evolution

#28
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.

Re: Swift's Evolution

#29

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.

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.

Re: Swift's Evolution

#30

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…

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.

Post reply on HN