4 ms·

Naysayers. The world will pour billions of dollars in Swift the coming years and they will keep complaining about it. The most important advantage of Swift is

Naysayers. The world will pour billions of dollars in Swift the coming years and they will keep complaining about it. The most important advantage of Swift is that it allows you to code from the server to the desktop, mobile, watch, tv, IoT, in one language. Swift will be everywhere and some are afraid of that, very afraid.

seanparsons 10y ago
What on earth is this all about? Having spent a year working mostly in Swift I can't wait to see the back of it, even "billions" of dollars spent wouldn't turn it into a halfway decent programming language.
- eternalban 10y ago
  I haven't looked at Swift at all. would you mind elaborating?
  - seanparsons 10y ago
    Other people have listed issues in here like compiler crashes from valid code, gotta spend time unwinding changes until it works and write the code differently. Simple things like "a + b +...+ n" cause compile times to balloon exponentially, which means for arrays you end up refactoring concatenation of immutable arrays into a mutable array you call appendContentsOf on a bunch of times. SourceKit on the surface sounds great, but in truth it's a simple text parser that doesn't understand type aliases for example. The compiler _really_ struggles with anything beyond very simple generics, first the type inference starts to fail and then it'll refuse to compile until you break the code apart and add type ascriptions. The compile errors are often absolute nonsense, pointing nowhere near the actual errors or are like the Magic 8-ball coming up "ask again later". The project I'm working on has been a mix of Swift and JavaScript, we're happily increasing the ratio in favour of the latter because of all the pain we've had with Swift. I personally don't even like JavaScript but it's not even a contest between the two.
    - eternalban 10y ago
      (Sorry for late reply!) Thank you, that was very informative.
- Razengan 10y ago
  The problems you've listed in reply to my sibling commenter are all on the tooling side, not with the language, and yes they could definitely be fixed by spending "billions" on people and resources dedicated solely to improving them. You didn't specify anything that says Swift isn't a "halfway decent programming language."
  - seanparsons 10y ago
    I don't think I've ever seen anyone regard the compiler as tooling, SourceKit for sure that makes sense, but not the compiler. Especially in this case as there really is just the one compiler for it so those are issues that will hit anyone using Swift now. But if you want problems with the language itself, let me see: It suffers from similar problems to Scala, where it tries to blend OO concepts in with FP concepts. Variance is where this flares up terribly because it doesn't provide any explicit support for covariance or contravariance. You end up with invariance and subtyping in a bunch of places which is not a nice combination. Protocols like Equatable and Hashable are implemented with compiler magic for arrays and tuples. Which means that you run into trouble with generic functions that say accept two instances of the same type which is Equatable if you pass an array of ints. The underlying reasons behind this (which mostly escape me at midnight on a Sunday) are something to do with protocols on generic types. You can't say "for a List if the elements are Equatable the List is equatable" IIRC. This one annoys me no end as we've had to fudge our way around it several times on the same project. For some reason that eludes me, Optional<T> is given all sorts of special case syntax ("if let" and "guard let") which is like a crap version of "for yield" from Scala or do notation in Haskell that only works on that. As a result a lot of convenient abstractions are just not possible you end up writing all kinds of horrid looking chained map/flatMap calls instead. Sometimes because of this dissonance between things a block of code might have a guard let block, then some other stuff, then an if let block with an else condition. Whereas if you wrote the same thing in Haskell it would be one do block and that's it. Concurrency and parallelism support is effectively Grand Central Dispatch, which is the most imperative API ever on macOS/iOS and on other platforms (according to the Github page I just looked at for it) is in the early stages of development. You're just calling the old Objective-C API and the language doesn't help at all there. Edit: As a bonus addition, it's a statically typed "FP" language which doesn't have higher kinded types which means a bunch of handy abstractions are a real pain. See the Swiftz project for how they have to define things like monads as an example. Is that enough problems?
sydd 10y ago
Actually the opposite is true, Swift is an Apple ecosystem language, and thats why it sucks. I'd love if it could replace languages like Java or C#, but we're decades from that with the current pace (if it will ever happen). They open sourced the language more than a year ago. The Linux builds are crappy, for example there is no release for Ubuntu 16.10. The IDE support on Linux is basically non-existent. There are some initial offerings, but they are in alpha or pre-alpha state. The situation on Windows is even more bleak, you can only get the compiler via some Linux emulation. All of this results obviously in no or very very few libraries that are not aimed towards iOS/OSX development. So no, Swift does not allow you to code anywhere. And if Apple continues the way they do it now, it will end up as Objective-C, a language that is solely used by iOS/OSX devs.
- tormeh 10y ago
  I don't know about this. I think maybe it will take the node.js route: A language is required for one platform (web/iOS) and since developers like using a single language for everything it will be used for all kinds of other things, even things the language is not suited for.
  - pjmlp 10y ago
    I like Swift, because it will make everyone that cares about Mac/iOS/tvOS/watchOS aware of ML like programming languages and FP concepts. Outside Apple ecosystems, Haskell, OCaml, F#, Rust are much better options in terms of tooling, libraries and multiple OSes support.

seanparsons 10y ago

What on earth is this all about? Having spent a year working mostly in Swift I can't wait to see the back of it, even "billions" of dollars spent wouldn't turn it into a halfway decent programming language.

eternalban 10y ago
I haven't looked at Swift at all. would you mind elaborating?
- seanparsons 10y ago
  Other people have listed issues in here like compiler crashes from valid code, gotta spend time unwinding changes until it works and write the code differently. Simple things like "a + b +...+ n" cause compile times to balloon exponentially, which means for arrays you end up refactoring concatenation of immutable arrays into a mutable array you call appendContentsOf on a bunch of times. SourceKit on the surface sounds great, but in truth it's a simple text parser that doesn't understand type aliases for example. The compiler _really_ struggles with anything beyond very simple generics, first the type inference starts to fail and then it'll refuse to compile until you break the code apart and add type ascriptions. The compile errors are often absolute nonsense, pointing nowhere near the actual errors or are like the Magic 8-ball coming up "ask again later". The project I'm working on has been a mix of Swift and JavaScript, we're happily increasing the ratio in favour of the latter because of all the pain we've had with Swift. I personally don't even like JavaScript but it's not even a contest between the two.
  - eternalban 10y ago
    (Sorry for late reply!) Thank you, that was very informative.
Razengan 10y ago
The problems you've listed in reply to my sibling commenter are all on the tooling side, not with the language, and yes they could definitely be fixed by spending "billions" on people and resources dedicated solely to improving them. You didn't specify anything that says Swift isn't a "halfway decent programming language."
- seanparsons 10y ago
  I don't think I've ever seen anyone regard the compiler as tooling, SourceKit for sure that makes sense, but not the compiler. Especially in this case as there really is just the one compiler for it so those are issues that will hit anyone using Swift now. But if you want problems with the language itself, let me see: It suffers from similar problems to Scala, where it tries to blend OO concepts in with FP concepts. Variance is where this flares up terribly because it doesn't provide any explicit support for covariance or contravariance. You end up with invariance and subtyping in a bunch of places which is not a nice combination. Protocols like Equatable and Hashable are implemented with compiler magic for arrays and tuples. Which means that you run into trouble with generic functions that say accept two instances of the same type which is Equatable if you pass an array of ints. The underlying reasons behind this (which mostly escape me at midnight on a Sunday) are something to do with protocols on generic types. You can't say "for a List if the elements are Equatable the List is equatable" IIRC. This one annoys me no end as we've had to fudge our way around it several times on the same project. For some reason that eludes me, Optional<T> is given all sorts of special case syntax ("if let" and "guard let") which is like a crap version of "for yield" from Scala or do notation in Haskell that only works on that. As a result a lot of convenient abstractions are just not possible you end up writing all kinds of horrid looking chained map/flatMap calls instead. Sometimes because of this dissonance between things a block of code might have a guard let block, then some other stuff, then an if let block with an else condition. Whereas if you wrote the same thing in Haskell it would be one do block and that's it. Concurrency and parallelism support is effectively Grand Central Dispatch, which is the most imperative API ever on macOS/iOS and on other platforms (according to the Github page I just looked at for it) is in the early stages of development. You're just calling the old Objective-C API and the language doesn't help at all there. Edit: As a bonus addition, it's a statically typed "FP" language which doesn't have higher kinded types which means a bunch of handy abstractions are a real pain. See the Swiftz project for how they have to define things like monads as an example. Is that enough problems?

sydd 10y ago

Actually the opposite is true, Swift is an Apple ecosystem language, and thats why it sucks. I'd love if it could replace languages like Java or C#, but we're decades from that with the current pace (if it will ever happen). They open sourced the language more than a year ago. The Linux builds are crappy, for example there is no release for Ubuntu 16.10. The IDE support on Linux is basically non-existent. There are some initial offerings, but they are in alpha or pre-alpha state. The situation on Windows is even more bleak, you can only get the compiler via some Linux emulation. All of this results obviously in no or very very few libraries that are not aimed towards iOS/OSX development. So no, Swift does not allow you to code anywhere. And if Apple continues the way they do it now, it will end up as Objective-C, a language that is solely used by iOS/OSX devs.

tormeh 10y ago
I don't know about this. I think maybe it will take the node.js route: A language is required for one platform (web/iOS) and since developers like using a single language for everything it will be used for all kinds of other things, even things the language is not suited for.
- pjmlp 10y ago
  I like Swift, because it will make everyone that cares about Mac/iOS/tvOS/watchOS aware of ML like programming languages and FP concepts. Outside Apple ecosystems, Haskell, OCaml, F#, Rust are much better options in terms of tooling, libraries and multiple OSes support.