I think part of the parent comment's point was that Swift does/will have a lot of users. Right now those 10,000 Go questions cover a lot of server related issues; the 37,000 Swift questions are almost completely iOS questions.

If I started writing an HTTP server in Swift the day it comes out I won't find much help but I'll have a mountain of unrelated answers to filter. Essentially Swift's adoption for iOS apps doesn't help and might hurt efforts to use it elsewhere.

Look at Object-C: extremely common writing software for Apple; almost non-existent elsewhere, despite the fact that it has never been limited to Apple.

Objective-C never caught on outside of the Apple/NeXT ecosystem because its biggest advantages were in the application frameworks, not the language itself. By the time iOS made Objective-C popular there were entrenched alternatives in the C++, Java, and .NET ecosystems. Swift is facing the same challenges, but against a newer generation of competitors that are much less established. It's probably still an uphill battle for Swift to gain outside adoption, but it's not climbing a cliff.

Not to mention, Swift the language itself, which is basically Rust with arguably an easier memory management model (all ARC) and Scala-like pragmatism (an OOP model built-in). Coming from ObjC, developers are showing a high level of interest in Swift. I might look it up when it comes out for Linux!

I have carefully compared the two languages and I do not see more similarity than between Go and Swift or any other language. You have yourself cited the different memory management models, and this is the main characteristic of Rust. The sole common feature is the use of LLVM.

Why would I ever care about Go for Android when I can write apps in Kotlin? Kotlin is fully interoperable with Java. I don't have much experience with Swift but Kotlin is so nice. It has the best features from numerous languages such as Ruby. C#, etc. It's being made by Jetbrains who makes the the core of Android Studio so it will have support. Kotlin is also nearly as fast at runtime as Java with a tiny 200kb runtime. Almost all the magic happens at build time so your build time will be a little longer. Kotlin also works with any existing Java library, even annotation processing libs.

Again, why would any Android developer choose Swift? Kotlin also runs fine on the server and it even compiles to Javascript.

If I were a startup doing an iOS, Android, and a backend I would do either Go or Rust on the backend. You will be able to distribute a native lib with your Android or iOS that shares network and model logic. Go and Rust both are planning on supporting cross compilation to iOS and Android.

That would leave you with Kotlin/Groovy/Clojure/Scala for the view layer of your Android app if you choose not use Java. Which is a good idea since there is no indication from Google Java 8 will be supported which means no lambdas unless you use an alt JVM language. On iOS you write your view layer in Swift. Both apps use the shared binary library.

I found this comparison between Swift and Kotlin interesting, and the point that it would make switching between Android and iOS development easier:

http://blog.translusion.com/posts/swift-is-kotlin/

Kotlin is positively awesome, but when I tried it (admittedly last year) it didn't seem ready for production yet. It worked all well as long as stuff was kept simple, then I used Realm.io, wrote some unit tests and got all sorts of NoClassDefFoundError exceptions, dexmaker errors etc. Long story short, I couldn't fix it. As I said, it's been a while. I hope things have been improving and continue to improve. The language itself is superb

It's pretty damn closed to 1.0. They just released M12 which adds support for interop with Java libs that use annotation processing such as Dagger.

With the just released support for annotation processing Kotlin is now working with e.g. Realm.

I've just been playing with it some in the last couple of weeks. I get the impression that they're still iterating pretty rapidly on it - at least partly because the official practice repo uses trait all over the place, which they apparently deprecated and changed to interface.

I will say that it It looks very promising so far, and seems to have the best of C# and Ruby, assuming you're sticking with compile-time type checking, plus a few more tricks besides. I'm not that up on JVM languages though, so I'm not sure that it's definitively better than any of the other choices.

If you use Scala for your view layer, why would you even want to use Go for your back end?

Very true. I am starting to not see the point of Go. It's about the same performance as the JVM languages and the JVM is just as easy to deploy. On the JVM you get to choose between Clojure, Scala, Ruby, Groovy, Kotlin, and more. JVM is just as easy to deploy as a Go binary too. Personally, I plan to stick with JVM languages plus Rust.

Here is how to see the point of Go:

Open the rosettacode web site. Choice any algorithm you are familiar with. Place Go version and Java version. Compare the number of words and lines.

Compare the Maven hell with how Go solves the same problems.

I bet my Clojure or Groovy version will be simpler. I agree Scala is super complex :). Maven does suck. Gradle wraps it and does not suck. Probably the best build tool I have ever seen.

So, a more succinct Java, that can't leverage the JVM ecosystem? Why is that better than Scala, which can also be more succinct than Java, but can leverage the JVM ecosystem?

Go is enormously simpler than Scala.

(I also don't agree that the deployment story for the JVM and Go are similarly complex, but that's a different argument).

> Why would I ever care about Go for Android when I can write apps in Kotlin

Power consumption.

Since Android Java is compiled to native code on installation time, I don't see any benefit using Go in terms of power consumption.

I guarantee you could write a more power efficient app using the Android SDK versus Go in the NDK.

OTOH There are 70k Go repos on GitHub vs 31k for Swift (vs ~5k for Rust)

- https://github.com/search?l=go&q=stars%3A%3E-1&ref=searchres...

- https://github.com/search?l=swift&q=stars%3A%3E-1&ref=search...

- https://github.com/search?l=rust&q=stars%3A%3E-1&ref=searchr...

The numbers of results there vary wildly upon refreshing the page repeatedly. I'm getting ranges of 39k-79k for Go, 12k-42k for Swift, and 3k-9k for Rust. Also, in the absence of knowledge of what precisely is being measured (e.g. does it include forks?), we should probably only interpret these numbers as order-of-magnitude comparisons.

Swift repos will pass Go within 12 months. I think most iOS developers were holding off on Swift. Heck, Xcode and Swift, etc only became usable earlier this year.

Most people aren't writing open source iOS apps.

No but there are a lot of components.

I think that doesn't support your hypothesis--- 31k in one year compared to 70k in 6 years implies a lot more momentum for swift than go.

It seems to me that Dart would be a more obvious choice should Google choose to push a new application development language for the Android platform. It's closer to JavaScript and has more GUI/visually-oriented libraries. Plus, it's a no-brainer to box such apps in a HTML5 container for iOS/Windows.

> Anyway, 1,000,000 Swift developers will change everything.

All of these objective-C developers changed nothing for non-ios crowd. Why would swift be different?

Linux support.

GCC has supported Objective-C since at least version 2.0, released in 1992

(based on http://www.informatica.co.cr/linux/research/1992/0222.htm)

This is very very true. I remember trying to look into Objective C years and years ago and trying to get somewhere on my Linux box but due to the lack of standard GUI libraries etc. it seemed a non-starter.

Of course, all bets are off once Go becomes a first class citizen on Android.

This cannot happen soon enough.

I'm not saying this because of anything to do with Apple's Swift announcement. I'm saying this because it'll be a huge benefit to Android.

> I'm saying this because it'll be a huge benefit to Android. reply

How so?

The language has a weaker type system than Java, doesn't support exceptions and requires error checking every other line, has very poor tool support (because the compiler was not designed with IDE's in mind).

Except maybe add a few developers who refused to write code on Android because of Java, I really don't see what Go would bring to Android.

You shouldn't be getting down-voted. The idea of anyone rewriting the entire Android Framework in Go when you can use better languages like Kotlin, Scala, Groovy, Clojure is asinine. Go will compile to Android architectures so you could do shared code in Go between iOS and Android like a C++ lib. That makes sense.

> That would leave you with Kotlin/Groovy/Clojure/Scala for the view layer of your Android app if you choose not use Java

> when you can use better languages like Kotlin, Scala, Groovy, Clojure is asinine

You seem to be piggybacking an aspiring JVM language (Kotlin) on top of three other alternative ones that have already made it (Scala,Groovy,Clojure). Because that trick's already been done before with them (i.e. Groovy piggybacked on the quality of Scala and Clojure), it makes your list of examples of alternative JVM languages seem disingenuous.

Sorry about that. They all have tools that make them work on Android. Kotlin is reasonable option imo. It doesn't effect app startup and runtime size is so much smaller compared to the others. Clojure Android adds 3 seconds to startup time for example. I haven't used Scala so I am not sure how nice it is for Android.

Did anyone say anything about rewriting the entire Android Framework? Nope. It was about Go becoming a first class citizen on Android. That doesn't mean it can coexist with Java for someone who needs a fancy IDE.

It already IS. You can compile Android NDK libraries with Go today. It isn't that useful because the NDK isn't hooked up with the Android framework which means you don't get lifecycle events. There was a whole Android framework written over the past decade or so in Java that abstracts this.

Type system strength does not correlate with language adoption. Else, nobody would use C, Python, PHP, Javascript, Perl, Ruby ; C++, C#, Java would be outsiders and almost everybody would use Ada, Haskell, OCaml.

I agree with your last sentence, however.

Unless all those devs with apps on Android want to port all their code?

While that would be nice, every indication is saying that Google has no interest in this right now.