Curly brackets. Yuck.
Google may be considering Swift as a ‘first class’ language for Android
21–30 of 30 posts
Re: Google may be considering Swift as a ‘first class’ language for Android
#22Earlier quoted context omitted.
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).
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.
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.
Re: Google may be considering Swift as a ‘first class’ language for Android
#23Earlier quoted context omitted.
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).
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.
> 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.
Re: Google may be considering Swift as a ‘first class’ language for Android
#24Is Swift actually a good language, what's good about it? From a general perspective. Been using Go, and love it. Many innovative changes to basically be a C for our century. What's Swift, what have its designers learned from the past to make a better language?
Re: Google may be considering Swift as a ‘first class’ language for Android
#25Is Swift actually a good language, what's good about it? From a general perspective. Been using Go, and love it. Many innovative changes to basically be a C for our century. What's Swift, what have its designers learned from the past to make a better language?
Swift includes a lot of high-level features and modern best practices. Off the top of my head, nice stuff that Swift has that Go does not include generics, value-type collections, Optional instead of implicit nil, algebraic data types through enums, let bindings for immutable values, pattern matching, Unicode support at the grapheme cluster level, a REPL, tuples, try/catch error handling, and functional constructs like map/filter/flatMap.
Re: Google may be considering Swift as a ‘first class’ language for Android
#26Why not Rust or Go? The only reason they would pick Swift is because of existing uptake
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....
Re: Google may be considering Swift as a ‘first class’ language for Android
#27Earlier quoted context omitted.
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.
> 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.
> 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).
Re: Google may be considering Swift as a ‘first class’ language for Android
#28Earlier quoted context omitted.
To entice IOS developers to port their app on Android more easily ?
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.
> 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
Re: Google may be considering Swift as a ‘first class’ language for Android
#29This article should be taken with a good pinch of salt. It seems to be more speculation than anything else...
My first thought. Then looking at what Microsoft is doing by offering compelling tool for cross platform development, then there is a possibility that Google is working to offer its own Xamarin like solution. Can only dream it will be one single GUI API for developing apps for Android, iOS, Windows, WebAssembly and Linux desktops using Swift. If Google has this cross platform GUI API, then many are likely to abandon Cocoa API. Google probably sees API as platform and not language.
Re: Google may be considering Swift as a ‘first class’ language for Android
#30Earlier quoted context omitted.
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.
> 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.
GUI frameworks do not require GC, as many examples (Motif, Windows, Atari TOS, Mac OS, etc.) demonstrate. But i mentioned a _shared_ framework that is usable from both GC and non-GC languages.
They could, as you indicate, build two frameworks instead, but it would be a challenge to keep parity between them, both in look and feel and in functionality.
Having both opinions look the same is less important on mobile than on the desktop, but feel is important. For example, click delays should be very, very similar, selection methods should be the same, etc.
Functionality would be an even bigger challenge. If they ever release new functionality, say a new kind of control, for one framework first, and for the other a few months later, it would appear as if they do not consider the two languages to be primary languages on their platform.
So, one GUI framework, IMO, would be the best solution, not on technical, but on social/political grounds. As thevibesman suggests in a sister comment, having the non-GC framework instantiate a JVM is a solution, but only technically. Again, that would make the non-GC language look like a second-class, bolted-on thing.
Finally, all of the above applies non-GUI functionality (for example, if functionality gets added to the address book, it must become available in a GC and a non-GC API) and to third-party developers selling libraries to Android developers, too.