4 ms·

Why not Rust or Go? The only reason they would pick Swift is because of existing uptake

by wrg 10y ago

seren 10y ago
To entice IOS developers to port their app on Android more easily ?
- wrg 10y ago
  This also. It seems purely like a calculated move to undermine iOS as much as possible, but it does make you wonder if it's the Right Thing to do. There are better languages out there that have had much more development take place. And it's not like Google have commit rights or control over Swift. It's sad how they haven't really learned from the Oracle case.
  - Grazester 10y ago
    You make it sound like this is a sure thing. I have serious doubt that it will happen. ...cant we have Go instead Google?
  - hga 10y ago
    It seems purely like a calculated move to undermine iOS as much as possible What's your theory behind that? The only one I can think of is that if they make it easy to write an app for both, and Apple does not accept the app or an update, you haven't suffered a complete loss.
  - thevibesman 10y ago
    > It seems purely like a calculated move to undermine iOS as much as possible I really don't see how this is the case; do you consider Microsoft's Project Islandwood[1] to be a move to undermine iOS? Both seem like an attempt to offer developers more choice and a reason to work on the platform. If this is to undermine anything, I think it would be the various 'hybrid'-webapp solutions as writing a Swift app seems like a better way to "write once, run anywhere" than a JavaScript hybrid solution. > And it's not like Google have commit rights or control over Swift. It's sad how they haven't really learned from the Oracle case. I don't see how not having commit rights is an issue. The licensing terms of Java are/were very different from Swift. Getting behind an Apache-licensed open-source language does not necessarily mean Google is not free to control their own version of the language (why would they?). I don't see the copyrightable API issue coming up with Apple and Swift because of how the open source Foundation has been encouraged (and I really think Apple wouldn't mind / will encourage open-source ports of other Frameworks). [1]: https://developer.microsoft.com/en-us/windows/bridges/ios https://developer.microsoft.com/en-us/windows/bridges/ios
- alphacome 10y ago
  I think so. why bother to learn some new language.
- drivingmenuts 10y ago
  Won't that require that Google finds some way to get people to actually pay for apps comparable to the rate that IOS users pay for theirs?
  - nostrademons 10y ago
    The economic calculus is "cost of porting" < "Android userbase" * "Android conversion rate" * price. iOS stats don't figure into that at all; any money from an Android version is strictly marginal revenue. This change is aimed at significantly reducing the cost of porting; Google probably figures that number is a lot easier to move than the Android conversion rate or price, and they've already made significant progress on increasing the Android userbase.
andybak 10y ago
I'm projecting but hopefully because Swift is in some ways 'higher level' than Rust or Go. From my brief examination Swift has slightly more the conciseness, readability, usability and flexibility of dynamic languages. (I'd love to see native Android apps in Python (or Nim) but that's probably never going to happen. Failing that I could live with a language like Swift.)
TurboHaskal 10y ago
Software is a popularity contest.
convivialdingo 10y ago
Rust is still being designed and Go doesn't have a mature optimizing compiler. Swift has a lot of developer growth, cross-platform library possibilities, and a two optimization pass compiler (SIL and IL).
- Someone 10y ago
  Swift doesn't have a mature compiler, either. It isn't old enough to have fought enough battles. Also, I wouldn't say the rust language definition is less stable than Swift's, which is still very much in flux (with changes such as the removal of C-style for loops in the pipeline or just released) Also, Swift doesn't do garbage collection. That may cause problems when trying to build a shared GUI famework.
  - nostrademons 10y ago
    Swift is in an interesting position compiler-wise: the frontend is bleeding-edge and often unstable (though many of the crashes, in my experience, were fixed with Swift 2.2), but the backend is rock-solid LLVM, which has had a lot of optimization & stability improvements go into it through Clang and Apple's existing Objective-C toolchain. Rust is in the same position.
  - DerekL 10y ago
    > Also, Swift doesn't do garbage collection. That may cause problems when trying to build a shared GUI framework. Do GUI frameworks require garbage collection? Cocoa doesn't. But the current Android frameworks are written to function with GC, so if Google wants to support Swift or any other non-GC language, they would have write and maintain a second framework along side the old Java one.
    - thevibesman 10y ago
      > But the current Android frameworks are written to function with GC, so if Google wants to support Swift or any other non-GC language, they would have write and maintain a second framework along side the old Java one. While it is likely that this is how it could play out, it is certainly possible to have a garbage collected language and a managed memory language working together in the same program (e.g. a manual memory managed C program can start an internal JVM and pass data between the two languages).
ridiculous_fish 10y ago
One possible reason is dynamic linking and ABI stability. Go and Rust like to statically link everything, which doesn't work so well with big GUI frameworks. ABI stability and resilience is on the roadmap for Swift 3.0: https://github.com/apple/swift-evolution/blob/master/README.md https://github.com/apple/swift-evolution/blob/master/README....

Why not Rust or Go? The only reason they would pick Swift is because of existing uptake

by wrg 10y ago

Why not Rust or Go? The only reason they would pick Swift is because of existing uptake

seren 10y ago

To entice IOS developers to port their app on Android more easily ?

wrg 10y ago
This also. It seems purely like a calculated move to undermine iOS as much as possible, but it does make you wonder if it's the Right Thing to do. There are better languages out there that have had much more development take place. And it's not like Google have commit rights or control over Swift. It's sad how they haven't really learned from the Oracle case.
- Grazester 10y ago
  You make it sound like this is a sure thing. I have serious doubt that it will happen. ...cant we have Go instead Google?
- hga 10y ago
  It seems purely like a calculated move to undermine iOS as much as possible What's your theory behind that? The only one I can think of is that if they make it easy to write an app for both, and Apple does not accept the app or an update, you haven't suffered a complete loss.
- thevibesman 10y ago
  > It seems purely like a calculated move to undermine iOS as much as possible I really don't see how this is the case; do you consider Microsoft's Project Islandwood[1] to be a move to undermine iOS? Both seem like an attempt to offer developers more choice and a reason to work on the platform. If this is to undermine anything, I think it would be the various 'hybrid'-webapp solutions as writing a Swift app seems like a better way to "write once, run anywhere" than a JavaScript hybrid solution. > And it's not like Google have commit rights or control over Swift. It's sad how they haven't really learned from the Oracle case. I don't see how not having commit rights is an issue. The licensing terms of Java are/were very different from Swift. Getting behind an Apache-licensed open-source language does not necessarily mean Google is not free to control their own version of the language (why would they?). I don't see the copyrightable API issue coming up with Apple and Swift because of how the open source Foundation has been encouraged (and I really think Apple wouldn't mind / will encourage open-source ports of other Frameworks). [1]: https://developer.microsoft.com/en-us/windows/bridges/ios https://developer.microsoft.com/en-us/windows/bridges/ios
alphacome 10y ago
I think so. why bother to learn some new language.
drivingmenuts 10y ago
Won't that require that Google finds some way to get people to actually pay for apps comparable to the rate that IOS users pay for theirs?
- nostrademons 10y ago
  The economic calculus is "cost of porting" < "Android userbase" * "Android conversion rate" * price. iOS stats don't figure into that at all; any money from an Android version is strictly marginal revenue. This change is aimed at significantly reducing the cost of porting; Google probably figures that number is a lot easier to move than the Android conversion rate or price, and they've already made significant progress on increasing the Android userbase.

andybak 10y ago

I'm projecting but hopefully because Swift is in some ways 'higher level' than Rust or Go. From my brief examination Swift has slightly more the conciseness, readability, usability and flexibility of dynamic languages. (I'd love to see native Android apps in Python (or Nim) but that's probably never going to happen. Failing that I could live with a language like Swift.)

TurboHaskal 10y ago

Software is a popularity contest.

convivialdingo 10y ago

Rust is still being designed and Go doesn't have a mature optimizing compiler. Swift has a lot of developer growth, cross-platform library possibilities, and a two optimization pass compiler (SIL and IL).

Someone 10y ago
Swift doesn't have a mature compiler, either. It isn't old enough to have fought enough battles. Also, I wouldn't say the rust language definition is less stable than Swift's, which is still very much in flux (with changes such as the removal of C-style for loops in the pipeline or just released) Also, Swift doesn't do garbage collection. That may cause problems when trying to build a shared GUI famework.
- nostrademons 10y ago
  Swift is in an interesting position compiler-wise: the frontend is bleeding-edge and often unstable (though many of the crashes, in my experience, were fixed with Swift 2.2), but the backend is rock-solid LLVM, which has had a lot of optimization & stability improvements go into it through Clang and Apple's existing Objective-C toolchain. Rust is in the same position.
- DerekL 10y ago
  > Also, Swift doesn't do garbage collection. That may cause problems when trying to build a shared GUI framework. Do GUI frameworks require garbage collection? Cocoa doesn't. But the current Android frameworks are written to function with GC, so if Google wants to support Swift or any other non-GC language, they would have write and maintain a second framework along side the old Java one.
  - thevibesman 10y ago
    > But the current Android frameworks are written to function with GC, so if Google wants to support Swift or any other non-GC language, they would have write and maintain a second framework along side the old Java one. While it is likely that this is how it could play out, it is certainly possible to have a garbage collected language and a managed memory language working together in the same program (e.g. a manual memory managed C program can start an internal JVM and pass data between the two languages).

ridiculous_fish 10y ago

One possible reason is dynamic linking and ABI stability. Go and Rust like to statically link everything, which doesn't work so well with big GUI frameworks. ABI stability and resilience is on the roadmap for Swift 3.0: https://github.com/apple/swift-evolution/blob/master/README.md https://github.com/apple/swift-evolution/blob/master/README....