7 ms·

I hate to say this, but Swift is to Objective-c, what Scala is to Java.... It was very exiting and promising at first, but it became bogged down due to its she

I hate to say this, but Swift is to Objective-c, what Scala is to Java.... It was very exiting and promising at first, but it became bogged down due to its sheer run-away complexity and over-academic approach to programming.... To an outsider, or iOS new comer, Swift looks much better than Objective-c, (due to Objective-c weird syntax), but to many insiders, Swift seems like a huge missed opportunity... The use of Swift, outside Apple's ecosystem is going to be limited.

shmerl 7y ago
I think Rust supersedes it in most aspects, especially in not being Apple driven.
- skohan 7y ago
  I would kill for a language with Swift's productivity and usibility and Rust's tooling and ecosystem.
  - zozbot234 7y ago
    Rust can be quite usable and productive if you know the right shortcuts. The tradeoff is somewhat lowered performance (and Rust makes sure that you're aware of where you're choosing that tradeoff) but that's just the way it goes. It's not like Swift is any different.
    - skohan 7y ago
      I think Rust is a fine language, but it's undeniable that it involves more tedium than other languages to use. If there is some tradeoff between safety, performance, and usability, Rust has prioritized safety and performance, where swift has chosen safety and usability. And that's perfectly fine. I am glad that Rust exists for those use-cases where the performance is important, but there are also cases where it's more important to be able to write a lot of code quickly with less friction. It doesn't devalue Rust to admit that there are places where it is not the optimal choice.
      - zozbot234 7y ago
        > more tedium than other languages Perhaps you haven't programmed in Java. Or even C++, for that matter (modern "Core C++" programming can be quite tedious at times). I'd say the jury is still out when it comes to Rust vs. "higher level languages", yes, even Swift. The point of my comment is that the "friction" you're pointing to need not be an inherent property of something like Rust, any more than it is in C++. It remains to be seen if the 'tradeoff' you mention is a binding one.
        skohan 7y ago
        > Perhaps you haven't programmed in Java. Or even C++, for that matter I never said Rust was the most tedious language, and I would hope it has learned something from those decades old languages. I agree that Rust has some usability issues which can be improved upon without sacrificing safety and performance, but I think that trade off will always be there at some level. For example, Swift’s copy-on-write makes it very easy to reason about value types, but comes at the cost of performance since there will be a lot of copies which aren’t strictly necessary. You can get essentially the same behavior in Rust by cloning everything, but it takes a lot more typing and adds visual noise to your code, because Rust has made the default to be more parsimonious with memory usage. At some level trade offs have to be made. No one language can be all thing a to all people.
        pjmlp 7y ago
        Thing is, yes it might cost performance, but does it matter? It all boils down to, does it deliver what the customer of an application written in Swift is asking for?
        skohan 7y ago
        Yeah that is exactly my point. In many cases all the extra work you put into writing Rust code for the additional performance is just that: extra. It doesn’t add any meaningful value to the final product, and it comes at the opportunity cost of that time you could have spent adding or improving features in a more productive language.
  - panpanna 7y ago
    Go? Kotlin?
    - skohan 7y ago
      Go is a nice language for some use-cases, but a bit too light on abstractions for my needs. When I tried Kotlin a couple years ago, it seemed to be marginally behind Swift in terms of the power of the type system and some of the cool things you can do in Swift, and I'm not wild about targeting JVM, but I understand that situation has been evolving so maybe I should give it a second look at some point.
    - lokedhs 7y ago
      Kotlin Native is nice, but its compile times are absolutely horrible. I guess some of this comes from Gradle, which is another mess in itself, but when it takes over half a minute to compile Hello World, there is a problem.
- deleted 7y ago
  [deleted]
- jbverschoor 7y ago
  So we’ll refuse go, typescript and react? Apple has the best engineering talent of all tech companies.
  - enitihas 7y ago
    Off course, that's why they keep having security issue after security issue (macOS root exploit to iPhone issue reported by project zero).
  - saagarjha 7y ago
    I think the parent cared more about it being driven by a specific company’s interests than Apple’s in particular, because this makes it somewhat difficult to use on other platforms. And I’d argue that Apple’s engineering talent, while good, is not “the best”.
  - shmerl 7y ago
    Hard to say if it's the best, but likely the worst attitude of the management on top when it comes to collaboration and general progress (which languages should enable).
    - jbverschoor 7y ago
      Oh def. Apple has been too slow and/or conservative about opensource.
  - terminaljunkid 7y ago
    > Apple has the best engineering talent of all tech companies. Are you trolling or are you that kind of extremist apple fanboy?
saagarjha 7y ago
I find Swift to be significantly more usable and less academic than Scala, and I like it much more as a result. Sure, it takes a number of cues from Scala, but it takes care to not fall into the same traps.
melling 7y ago
Nah, Swift is an easy language. I have a Cookbook here: http://www.h4labs.com/dev/ios/swift_cookbook.html http://www.h4labs.com/dev/ios/swift_cookbook.html I’m in the process of putting it on Github. https://github.com/melling/SwiftCookBook https://github.com/melling/SwiftCookBook SwiftUI probably means that millions of apps will eventually move to Swift, making Swift a top 10 language. https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/
- RandallBrown 7y ago
  Swift is already a top 10 language according to TIOBE.
  - 6700417 7y ago
    TIOBE’s methodology and rankings seem very dubious to me. When was the last time you met someone who primarily programs in C? (I was one of those people for 14 years, but that was a while ago). Red Monk seems much closer to reality: https://redmonk.com/sogrady/2019/07/18/language-rankings-6-19/ https://redmonk.com/sogrady/2019/07/18/language-rankings-6-1...
    - saagarjha 7y ago
      TIOBE is probably not worth looking too much at, but a number of embedded engineers use C almost exclusively. They’re just not all that visible :)
    - lykr0n 7y ago
      There are worlds of software developers outside of the Startup sphere.
      - 6700417 7y ago
        I’ve never worked at a startup. I know very few people who have been involved in the startup world. I have exclusively used C and C++ in my professional work (with a tiny bit of python for scripting). Yet I haven’t know anybody who primarily or even occasionally used C in their work for over a decade. I know they exist but the majority of C programmers moved on to C++ a long time ago. There are areas like kernel and driver development where C is still in widespread use but these jobs represent a tiny fraction of developers. Any language popularity metric that ranks C as the second most popular language is massively flawed.
pavlov 7y ago
For a language whose nearly exclusive use case is writing Cocoa applications, it’s odd how Swift ignored most of what had made Obj-C so good for GUI apps. Instead they just doubled down on everything that C++ was and Obj-C actively had tried to avoid.
- jzelinskie 7y ago
  Would you mind expanding on these feature sets a bit more? Because I just started playing with SwiftUI/Combine without ever using ObjC/UIKit, I don't know what parts of ObjC shined.
  - saagarjha 7y ago
    Objective-C was a good fit for dynamic, object-oriented GUI frameworks like Cocoa because that’s how it itself was structured. SwiftUI and Combine are simply a different way of structuring UI code that fits a lot better with Swift’s strengths.
    - solarkraft 7y ago
      Could you expand on that? How do the structures differ?
- deleted 7y ago
  [deleted]
- jcelerier 7y ago
  That is the first time in my life I hear objc and good in the same sentence. Every UI developer I know who has worked in it actively despised it.
skohan 7y ago
Can you go into any specifics? Personally I've found Swift to be incredibly easy to read and write, and that it largely delivers in terms of rolling out complexity through progressive disclosure. Most of the complexity is only there if you need it in my experience.
- ken 7y ago
  I keep hearing about this concept of "progressive disclosure", but I can't say I've seen it in Swift. Even the simplest functions I want to write, I tug on a little thread of an idea that I have, and pretty soon I'm pulling out this giant tangle that's got 3/4 of the Swift type system dangling off of it. What you're saying may be technically true. My issue is with the "if you need it" part. Unfortunately, I don't get to choose what I think I need. The compiler does. For example, every beginning Swift programmer runs into "Protocol can only be used as a generic constraint because it has Self or associatedType requirements" [1]. You start by thinking, I'm going to write a simple little type!, and then 30 seconds later you're digging through the least-documented parts of the Swift manual trying to figure out if there's a simple fix for this. (There isn't.) It's not like Objective-C where you write an -isEqualTo:(id) method and call it a day. This happens all over the place. Swift lambdas are weirder than Objective-C blocks. Swift errors are weirder than Objective-C exceptions. Swift strings are weirder than Objective-C strings. Ultimately, there is always a reason for the complexity (often: performance), but the upshot is that for any Swift feature I've wanted to use, I always had to learn a lot of extra details before I was able to use it. I feel there are a lot of other languages which are both easier to read and write, and do a much better job at progressive disclosure. [1]: https://www.youtube.com/watch?v=XWoNjiSPqI8&t=53s https://www.youtube.com/watch?v=XWoNjiSPqI8&t=53s
  - skohan 7y ago
    Interesting. I guess in my opinion, there is a difference between "swift has some pain points" and "swift is inherently over-complex". I have run into the associated types issue (which is improved a bit by the addition of existential by the way) but my reaction was more that this is a particular design pattern to avoid, rather than that the language is null and void. Given that you've made the comparison to Objective-C, are you sure you're not just running up against the learning curve of a new language? There are cases where Swift is a bit stricter, and therefore it's harder to type code which will compile on the first try, but in many of those cases it's because the strictness is allowing you to avoid entire categories of runtime bugs, which would give a non-specific error in Objective-C given the dynamic nature of the language.
chc 7y ago
I don't think there's any world where Swift is popular outside Apple's ecosystem. It's not anything wrong with the language that's the problem, it's that the primary reason you'd use Swift over similar languages like Rust or Nim is its integration into Apple's ecosystem. It has some unique features outside of that, but not enough to make up for how deep in the wilderness you'd be running Swift on non-Apple platforms. Rust, for example, is probably more complex then Swift — but I'd still choose it over Swift for cross-platform development because the language has a strong cross-platform story.
- skohan 7y ago
  > I don't think there's any world where Swift is popular outside Apple's ecosystem. I wouldn't go quite that far. I agree that Swift's cross-platform story is lacking, but as someone who follows the language closely, the story is improving all the time. I see it as largely a chicken-and-egg problem: i.e. there's not enough activity outside the Apple ecosystem to improve the situation quickly, but I don't think it's impossible for it to get there. For instance, it's already possible to use Swift in AWS Lambda, and some support for Azure's alternative offering, as well as Google's work on Swift for Tensorflow. All of these cases involve running Swift code in a very controlled environment, like a container, and this is very tenable even in Swift's current state. So even if it might be a bit of a pain to get Swift up and running on whatever exotic linux distro you run on your workstation, there are already starting to be some "easy" use-cases for Swift outside of Apple platforms. As the scope of these one-off use-cases grows, I think it's likely there will be increased demand to improve the cross-platform story in general. Personally this is appealing to me, because while I agree that Rust is miles ahead in terms of cross-platform support, I find Swift so much more productive and pleasant to work with that I welcome more opportunities to use it.
ryuukk_ 7y ago
LOL, rust is scala swift is as pragmatic as kotlin
ryuukk_ 7y ago
oh and btw, exposed ;)

shmerl 7y ago

I think Rust supersedes it in most aspects, especially in not being Apple driven.

skohan 7y ago
I would kill for a language with Swift's productivity and usibility and Rust's tooling and ecosystem.
- zozbot234 7y ago
  Rust can be quite usable and productive if you know the right shortcuts. The tradeoff is somewhat lowered performance (and Rust makes sure that you're aware of where you're choosing that tradeoff) but that's just the way it goes. It's not like Swift is any different.
  - skohan 7y ago
    I think Rust is a fine language, but it's undeniable that it involves more tedium than other languages to use. If there is some tradeoff between safety, performance, and usability, Rust has prioritized safety and performance, where swift has chosen safety and usability. And that's perfectly fine. I am glad that Rust exists for those use-cases where the performance is important, but there are also cases where it's more important to be able to write a lot of code quickly with less friction. It doesn't devalue Rust to admit that there are places where it is not the optimal choice.
    - zozbot234 7y ago
      > more tedium than other languages Perhaps you haven't programmed in Java. Or even C++, for that matter (modern "Core C++" programming can be quite tedious at times). I'd say the jury is still out when it comes to Rust vs. "higher level languages", yes, even Swift. The point of my comment is that the "friction" you're pointing to need not be an inherent property of something like Rust, any more than it is in C++. It remains to be seen if the 'tradeoff' you mention is a binding one.
      - skohan 7y ago
        > Perhaps you haven't programmed in Java. Or even C++, for that matter I never said Rust was the most tedious language, and I would hope it has learned something from those decades old languages. I agree that Rust has some usability issues which can be improved upon without sacrificing safety and performance, but I think that trade off will always be there at some level. For example, Swift’s copy-on-write makes it very easy to reason about value types, but comes at the cost of performance since there will be a lot of copies which aren’t strictly necessary. You can get essentially the same behavior in Rust by cloning everything, but it takes a lot more typing and adds visual noise to your code, because Rust has made the default to be more parsimonious with memory usage. At some level trade offs have to be made. No one language can be all thing a to all people.
        pjmlp 7y ago
        Thing is, yes it might cost performance, but does it matter? It all boils down to, does it deliver what the customer of an application written in Swift is asking for?
        skohan 7y ago
        Yeah that is exactly my point. In many cases all the extra work you put into writing Rust code for the additional performance is just that: extra. It doesn’t add any meaningful value to the final product, and it comes at the opportunity cost of that time you could have spent adding or improving features in a more productive language.
- panpanna 7y ago
  Go? Kotlin?
  - skohan 7y ago
    Go is a nice language for some use-cases, but a bit too light on abstractions for my needs. When I tried Kotlin a couple years ago, it seemed to be marginally behind Swift in terms of the power of the type system and some of the cool things you can do in Swift, and I'm not wild about targeting JVM, but I understand that situation has been evolving so maybe I should give it a second look at some point.
  - lokedhs 7y ago
    Kotlin Native is nice, but its compile times are absolutely horrible. I guess some of this comes from Gradle, which is another mess in itself, but when it takes over half a minute to compile Hello World, there is a problem.
deleted 7y ago
[deleted]
jbverschoor 7y ago
So we’ll refuse go, typescript and react? Apple has the best engineering talent of all tech companies.
- enitihas 7y ago
  Off course, that's why they keep having security issue after security issue (macOS root exploit to iPhone issue reported by project zero).
- saagarjha 7y ago
  I think the parent cared more about it being driven by a specific company’s interests than Apple’s in particular, because this makes it somewhat difficult to use on other platforms. And I’d argue that Apple’s engineering talent, while good, is not “the best”.
- shmerl 7y ago
  Hard to say if it's the best, but likely the worst attitude of the management on top when it comes to collaboration and general progress (which languages should enable).
  - jbverschoor 7y ago
    Oh def. Apple has been too slow and/or conservative about opensource.
- terminaljunkid 7y ago
  > Apple has the best engineering talent of all tech companies. Are you trolling or are you that kind of extremist apple fanboy?

saagarjha 7y ago

I find Swift to be significantly more usable and less academic than Scala, and I like it much more as a result. Sure, it takes a number of cues from Scala, but it takes care to not fall into the same traps.

melling 7y ago

Nah, Swift is an easy language. I have a Cookbook here: http://www.h4labs.com/dev/ios/swift_cookbook.html http://www.h4labs.com/dev/ios/swift_cookbook.html I’m in the process of putting it on Github. https://github.com/melling/SwiftCookBook https://github.com/melling/SwiftCookBook SwiftUI probably means that millions of apps will eventually move to Swift, making Swift a top 10 language. https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/

RandallBrown 7y ago
Swift is already a top 10 language according to TIOBE.
- 6700417 7y ago
  TIOBE’s methodology and rankings seem very dubious to me. When was the last time you met someone who primarily programs in C? (I was one of those people for 14 years, but that was a while ago). Red Monk seems much closer to reality: https://redmonk.com/sogrady/2019/07/18/language-rankings-6-19/ https://redmonk.com/sogrady/2019/07/18/language-rankings-6-1...
  - saagarjha 7y ago
    TIOBE is probably not worth looking too much at, but a number of embedded engineers use C almost exclusively. They’re just not all that visible :)
  - lykr0n 7y ago
    There are worlds of software developers outside of the Startup sphere.
    - 6700417 7y ago
      I’ve never worked at a startup. I know very few people who have been involved in the startup world. I have exclusively used C and C++ in my professional work (with a tiny bit of python for scripting). Yet I haven’t know anybody who primarily or even occasionally used C in their work for over a decade. I know they exist but the majority of C programmers moved on to C++ a long time ago. There are areas like kernel and driver development where C is still in widespread use but these jobs represent a tiny fraction of developers. Any language popularity metric that ranks C as the second most popular language is massively flawed.

pavlov 7y ago

For a language whose nearly exclusive use case is writing Cocoa applications, it’s odd how Swift ignored most of what had made Obj-C so good for GUI apps. Instead they just doubled down on everything that C++ was and Obj-C actively had tried to avoid.

jzelinskie 7y ago
Would you mind expanding on these feature sets a bit more? Because I just started playing with SwiftUI/Combine without ever using ObjC/UIKit, I don't know what parts of ObjC shined.
- saagarjha 7y ago
  Objective-C was a good fit for dynamic, object-oriented GUI frameworks like Cocoa because that’s how it itself was structured. SwiftUI and Combine are simply a different way of structuring UI code that fits a lot better with Swift’s strengths.
  - solarkraft 7y ago
    Could you expand on that? How do the structures differ?
deleted 7y ago
[deleted]
jcelerier 7y ago
That is the first time in my life I hear objc and good in the same sentence. Every UI developer I know who has worked in it actively despised it.

skohan 7y ago

Can you go into any specifics? Personally I've found Swift to be incredibly easy to read and write, and that it largely delivers in terms of rolling out complexity through progressive disclosure. Most of the complexity is only there if you need it in my experience.

ken 7y ago
I keep hearing about this concept of "progressive disclosure", but I can't say I've seen it in Swift. Even the simplest functions I want to write, I tug on a little thread of an idea that I have, and pretty soon I'm pulling out this giant tangle that's got 3/4 of the Swift type system dangling off of it. What you're saying may be technically true. My issue is with the "if you need it" part. Unfortunately, I don't get to choose what I think I need. The compiler does. For example, every beginning Swift programmer runs into "Protocol can only be used as a generic constraint because it has Self or associatedType requirements" [1]. You start by thinking, I'm going to write a simple little type!, and then 30 seconds later you're digging through the least-documented parts of the Swift manual trying to figure out if there's a simple fix for this. (There isn't.) It's not like Objective-C where you write an -isEqualTo:(id) method and call it a day. This happens all over the place. Swift lambdas are weirder than Objective-C blocks. Swift errors are weirder than Objective-C exceptions. Swift strings are weirder than Objective-C strings. Ultimately, there is always a reason for the complexity (often: performance), but the upshot is that for any Swift feature I've wanted to use, I always had to learn a lot of extra details before I was able to use it. I feel there are a lot of other languages which are both easier to read and write, and do a much better job at progressive disclosure. [1]: https://www.youtube.com/watch?v=XWoNjiSPqI8&t=53s https://www.youtube.com/watch?v=XWoNjiSPqI8&t=53s
- skohan 7y ago
  Interesting. I guess in my opinion, there is a difference between "swift has some pain points" and "swift is inherently over-complex". I have run into the associated types issue (which is improved a bit by the addition of existential by the way) but my reaction was more that this is a particular design pattern to avoid, rather than that the language is null and void. Given that you've made the comparison to Objective-C, are you sure you're not just running up against the learning curve of a new language? There are cases where Swift is a bit stricter, and therefore it's harder to type code which will compile on the first try, but in many of those cases it's because the strictness is allowing you to avoid entire categories of runtime bugs, which would give a non-specific error in Objective-C given the dynamic nature of the language.

chc 7y ago

I don't think there's any world where Swift is popular outside Apple's ecosystem. It's not anything wrong with the language that's the problem, it's that the primary reason you'd use Swift over similar languages like Rust or Nim is its integration into Apple's ecosystem. It has some unique features outside of that, but not enough to make up for how deep in the wilderness you'd be running Swift on non-Apple platforms. Rust, for example, is probably more complex then Swift — but I'd still choose it over Swift for cross-platform development because the language has a strong cross-platform story.

skohan 7y ago
> I don't think there's any world where Swift is popular outside Apple's ecosystem. I wouldn't go quite that far. I agree that Swift's cross-platform story is lacking, but as someone who follows the language closely, the story is improving all the time. I see it as largely a chicken-and-egg problem: i.e. there's not enough activity outside the Apple ecosystem to improve the situation quickly, but I don't think it's impossible for it to get there. For instance, it's already possible to use Swift in AWS Lambda, and some support for Azure's alternative offering, as well as Google's work on Swift for Tensorflow. All of these cases involve running Swift code in a very controlled environment, like a container, and this is very tenable even in Swift's current state. So even if it might be a bit of a pain to get Swift up and running on whatever exotic linux distro you run on your workstation, there are already starting to be some "easy" use-cases for Swift outside of Apple platforms. As the scope of these one-off use-cases grows, I think it's likely there will be increased demand to improve the cross-platform story in general. Personally this is appealing to me, because while I agree that Rust is miles ahead in terms of cross-platform support, I find Swift so much more productive and pleasant to work with that I welcome more opportunities to use it.

ryuukk_ 7y ago

LOL, rust is scala swift is as pragmatic as kotlin

ryuukk_ 7y ago

oh and btw, exposed ;)