Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Swift's Evolution

carpeaqua.com

Post reply on HN
Print view View original

31–40 of 105 posts

Re: Swift's Evolution

#31

Post by AsyncAwait »

AlexeyBrin wrote: post #3

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!

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

Re: Swift's Evolution

#32

Post by karmelapple »

nicky0 wrote: post #30
AsyncAwait wrote: post #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…

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.

Why isn't it currently ready for production use?

ABI stability is the only real issue I can see now.

Re: Swift's Evolution

#33

Post by melling »

nicky0 wrote: post #30
AsyncAwait wrote: post #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…

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.

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.

Re: Swift's Evolution

#34

Post by lazerwalker »

eggy wrote: 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.

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.

Re: Swift's Evolution

#35

Post by htormey »

AsyncAwait wrote: post #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…

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.

Re: Swift's Evolution

#36

Post by asveikau »

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.

Re: Swift's Evolution

#37

Post by [deleted] »

AsyncAwait wrote: post #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…

[deleted]

Re: Swift's Evolution

#38

Post by andybak »

bsaul wrote: post #16

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…

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

Re: Swift's Evolution

#39

Post by xenadu02 »

brutus1213 wrote: post #15

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…

There is never a better time to make a breaking change than right now.

Why does make treat tabs and spaces differently? Because Feldman's original version had that bugs and he didn't want to disrupt the However many users Swift has today, tomorrow there will be more. However many lines of code are written in it, tomorrow there will be more. The pain of making a change will only increase.

Apple was up front with everyone about Swift 1: there will be source-breaking changes in the future. Swift 3 was targeting source stability so it was the last chance to make such large changes.

In contrast, Swift 3.2 and Swift 4.0 are compiled by the same compiler and can be linked together. That means you can upgrade each module separately and don't have to wait for dependencies to upgrade. That's a huge win.

Swift 4 also brings Codable which will shave a massive amount of boilerplate from many codebases. The String overhaul is great too, along with generics improvements. These all affect the standard library and thus ABI stability.

The Law of Exclusivity is in, which is the core of the upcoming memory ownership model, which itself will enable async and other concurrency paradigms. This also affects ABI.

Once ABI stability lands the pace of standard library changes will necessarily slow dramatically. It is important to take the time to get things right, rather than rushing and locking bad or insufficient designs into stone.

Re: Swift's Evolution

#40

Post by andybak »

masklinn wrote: post #27
pscarey wrote: post #20

Earlier quoted context omitted.

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

I agree. Looping over a numeric sequence is simply a specific case of looping over any collection. A language should reflect this. It feels so natural to write:

    for thing in collection: process(thing)
and very easy to move from that to a functional style:

    map(collection, process)
or

    collection.map(process)
The number of times I also need a integer counter is fairly small.
Post reply on HN