The backlash against jigsaw may turn out to be justified. "Modularizing" the JVM would be exactly what you would expect as a first step to making some parts proprietary. If Oracle can wall off parts of the JVM completely they can claim GPL exemption for these parts and start closed source development of "enterprise" level features.
Kotlin will do a lot to derail attempts to make Java proprietary. Since it works fine on Java6 JVM's it sends a strong signal to Oracle that "we don't need you, if you piss us off we'll just fork the language".
The mention of Jigsaw is a red herring. Jigsaw, after long years of design-by-committee, suddenly devolved into a proxy war between enterprise players invested in existing module solutions. It's not about making parts proprietary at all; rather, it's about protecting existing investments in modularization ecosystems, the kinds of which form an important part of several companies' business models, all interspersed with legitimate technical and practical concerns about how to be prescriptive without being overly restrictive. The concern whether parts of a Java implementation can be made proprietary doesn't depend on the Jigsaw question, because there are several Java implementations today that are proprietary in part or whole, ranging from mediocre to marvellous, and they still manage to attract clientele.
However, I do agree that Kotlin is a signal to Oracle. It's a signal that Google has given the Android programming question, and the Java question a good amount of thought, and may have found a way to slowly transition off of a technology whose use literally resulted in them being sued, outcome notwithstanding; with Kotlin they can leverage compatibility with the lowest levels of the Java platform (and thus, all existing Java-coded Android code), give people a modern language that offers niceties and high productivity -- all courtesy of a partner whose interests align well with those of Google, and with whom they have cooperated before.
With Kotlin, Android can migrate off of Java without throwing away their existing investment in the body of code that happens to run on Android today, and do so in a way that makes it likely that developers will migrate voluntarily, vs. being forced.
Oracle killed Apache Harmony which is how Android got "stuck" at Java 6.
Statement by the ASF Board on our participation in the Java Community Process:
> Through the JSPA, the agreement under which both Oracle and the ASF participate in the JCP, the ASF has been entitled to a license for the test kit for Java SE (the "TCK") that will allow the ASF to test and distribute a release of the Apache Harmony project under the Apache License. Oracle is violating their contractual obligation as set forth under the rules of the JCP by only offering a TCK license that imposes additional terms and conditions that are not compatible with open source or Free software licenses. The ASF believes that any specification lead that doesn't follow the JCP rules should not be able to participate as a member in good standing, and we have exercised our votes on JSRs -- our only real power on the JCP -- accordingly. We have voted against Sun starting and continuing JSRs, and have made it clear that we would vote against the JSR for Java SE 7 for these reasons. https://blogs.apache.org/foundation/entry/statement_by_the_a...
Harmony ran into plenty of other challenges, but despite the odds it managed to produce a working J2SE 5 implementation. It was speculated that Sun was theoretically okay with a copyleft open source Java, but not one that wasn't copyleft, like Harmony. Specifically, they laid out conditions in the license for the Java Compatibility Kit, the conformance test suite needing to be passed to claim that you're "Java", that disallowed certain "Field[s] of Use" i.e. natures of deployment .
The "Field of Use" restrictions that Sun has imposed restrict software certified with the TCK to "general computing devices" which would for instance restrict use on kiosks or mobile devices. 
The Field of Use restrictions limiting J2SE 5 implementations to "General Purpose Computing Devices" and excluding special-case appliances, kiosks, mobile computing devices and other interesting applications constitutes an "additional restriction" that would be unacceptable to us (the ASF), and equally to the FSF (by the GPL's no-additional-restrictions policy). 
Oracle initially supported Apache on the matter, but reversed their stance once they bought Sun . Reading Sun's Field of Use restrictions heavily insinuates that covert, embedded, non-copyleft deployments -- like the future Android, a mishmash of old Harmony code, various other open source code, and closed source code -- are the exact kind of application they were hoping to curtail. Instead, Sun released OpenJDK under the copyleft GPLv2.
Throughout this journey, I've slept well at night knowing that Sun has done our utmost to balance the priorities of open source communities along with the responsibilities and obligations that we have with the myriad of enterprises, individual developers and consumers who have invested in the promise of "Write Once, Run Anywhere". The choice of the GPLv2 license was and is key to this balance, because it takes away the potential for a closed fork of the code, ensuring that we can all maintain compatibility. (...)
We knew when we chose the GPL and the free software model for Java technology that we couldn't satisfy everyone's desires. This is the case for the Apache Harmony Project at the Apache Software Foundation. The Harmony Project has applied for a license to use the JCK under the JCP's Scholarship Program for qualified not-for-profit organizations. Sun has offered Apache Harmony a license to use the JCK and the Java Compatible logo at no charge once their implementation passes the tests, and were even offering free support to help Apache run the JCK. But because the Apache code is not governed by the GPL, and does not require code sharing by any entity using or modifying Harmony, the terms of this license are the same terms under which Sun licenses the JCK to commercial entities that build their own independent implementations of the Java SE platform. As was made clear in their open letter to Sun, the ASF is not satisfied with these terms. (...)
For what it's worth, I completely understand why there is disagreement. There are fundamental principles and goals that separately define the GPL and Apache Software Licenses. Unlike the GPL, the Apache open source license does not require innovation to remain in the open. Java technology governed by the Apache license could be altered by any organization -- commercial or non-profit -- and rendered both incompatible and inaccessible to the community. The trust and value of Write Once Run Anywhere could not be upheld. (...)
We believe that copyleft is both unambiguous and instrumental in fulfilling goals of both communities and commerce. (...)
One view is that they wouldn't pass it, because, in their (lawyers') own words:
Although software applications for the Android platform may be written in the Java programming language, the Dalvik bytecode is distinct and different from Java bytecode. The Dalvik VM is not a Java VM. 
At various points in time, certain key Google employees contemplated whether they should or shouldn't .
And then since Android N is only 7% of the market, it means giving up on the stream libraries and the remaining features that are Android 7 only?
Finally, because lambdas are implemented with inner classes instead of new JVM bytecodes like on the real thing, Java 8 code on Android will have a performance impact?
And yes, there is also a lack of Android knowledge on HN, as many don't even know the restrictions the NDK has.
And yes, I know you can't use all features of java 8, but this isn't what the posts are on about. They just ignore all facts and go straight to "android is stuck at java 6" and nobody really challenges them on this belief. I guess neither will you.
The issue regarding lambdas has to do how they are implemented, by making use of inner classes instead of doing what Oracle has done in Hotspot and is being followed by most third party JVM implementations, meaning making use of invokedynamic infrastructure, thus being as if there was special bytecodes for lambdas.
This allows for more performance and optimization opportunities, which are much harder to achieve with plain inner classes.
Also those of us that like Java, always mean both the language and platform when talking about Java. The current situation is that now we need to write Android specific libraries instead of being able to pick any random Java 7 or 8 library and use it on Android applications, without any change.
The Google that still doesn't support all of Java 8 on Android?
I think the Kotlin Android phenomenon is really more a result of Android developers being unhappy with Google's stewardship than they are with Oracle's.
On the other end, some people in the community seem willing to sacrifice their position on the community board to stop Jigsaw.
There doesn't seem to be any consensus on exactly what makes Jigsaw bad and everyone seems to have their own laundry list of reasons. Even stranger, the use cases and utility of Jigsaw seem limited to just about everyone as the existing package system is quite good.
So why is there so much pushing from both ends? Maybe something isn't being said because it would damage the relationships between Oracle and Java sponsors. It's one thing to say "I don't like this module system for these technical reasons". It's another thing entirely to say "I don't trust your company to keep important parts of the JVM on the GPL".
A large java partner company accusing Oracle of closing off Java would make big waves in the community that would hurt both parties. Much better to just cause these initiatives to fail by political means.
Jigsaw is important for everyone in the community (less so for Oracle actually) because it reduces the startup time and memory footprint of the JVM. This enables it to be used in more places and on more devices and benefits all of the JVM languages in one hit.
The issues raised within the JSR group have been transparently raised and are purely technical and ideological. There could be a commercial aspect but really it's irrelevant. Red Hat, IBM etc do not depend on OSGi or other module systems for their commercial success. Any ulterior motives really don't make much sense.
OpenJdk has a linking exemption which would allow Oracle to develop closed source extensions to the JVM if it was built in a modularized way. Why else would Oracle continue to push something that's been so controversial for years? The only explanation I can think of is that it would allow them to put other more profitable plans into motion.
It's definitely speculation but not totally baseless. Oracle has been increasingly aggressive about monetizing Java in the last few years. I don't think it's unreasonable for them to add language features to increase their ability to make money from Java licensing.
Module systems sound great in theory. But we already have a bunch of existing ones, some simple and ad-hoc (like how we package things into JARs, publish to Maven Central or another artifact repository and load using regular old classloaders) and some are very formal and complex (OSGi or any of the big J2EE Application Servers).
How so? There is additional machinery needed to be started, the module system, and additional checks needed to be performed (module access) and additional metadata to be kept at runtime (module metadata). How is that helping startup time and and footprint? If anything that should make it worse.
Class loading has been lazy since day one, so if you don't use CORBA then CORBA classes are not loaded. This has been the case since Java 1.0.
JVM startup time is actually pretty good. If your application takes seconds to start that's because your startup code takes seconds to run. Jigsaw isn't going to help you there.
It is also part of how the upcoming AOT compiler to native code will work.
Nope, that's an entirely proprietary, intentionally unspecified extension.
> it is possible to create a JRE for distribution having only the code that actually matters for the application.
I don't see how this reduces the startup time and memory footprint of the JVM. If a class is not needed by your application it's not loaded, that has been the case since Java 1.0. I don't see how it not being present on disk makes any difference.
> It is also part of how the upcoming AOT compiler to native code will work.
Nope. It also works on classes and plain old JARs 
I guess at this point many just do not understand the enormity of Java in industry and Android in particular. Kotlin is welcome addition to Android but thinking it can challenge Java is like Nerf toys can challenge Nuclear powers.
Why does Oracle need a GPL exemption on source code they own?
Plus you are forgetting that everything still runs on top of Java and the JVM, just the code on the actual devices does not.
And why in the world would Google want to light a fire under Oracle's ass? Perhaps I'm missing something...
As for Oracle trying to close Java - any attempt to do so would be a disaster. IBM, Red Hat and other major players in the Java space would organize and fork the language.
Link? Superior in what way? Is there any LLVM based JVM implementation that runs faster than the current JVM android is using and no compatibility issue?
When I see those claims without any actual code, I would stay suspicious and call it farce, until it proves itself.
Azul uses LLVM as its last tier JIT compiler now :)
I don't think anyone is going to argue they don't have the fastest JVM around.
The performance numbers they give are:
" Falcon bests Oracle's HotSpot Java platform by anywhere from 5 to 250 percent in production performance, depending on the application, according to Azul. "
Server and mobile application have vastly different assumption of workload and metrics to take a look at. However, this announcement definitely better than OP's vague performance claim, which I agree. But as I said, there is no proof at this point, that LLVM based implementation on Android improve the the performance.
Quite on the contrary, Google include LLVM in 5.0 then remove it later:
And it was never used as the primary option anyway. So there is definitely not enough confidence to claim the superiority, until somehow make it work in the first place.
Using a JVM or CLR by MS (who with C# was making their own Java) seems cumbersome compared with direct code generation with the LLVM as intermediate code.
Apple derives $150 billion per year as an iOS phone headset company and it chose to use LLVM years ago when the processors were not nearly as powerful as today. When an Android headset even with good hardware would require 1 GB RAM, iPhones could run with better performance on 500 MB.
That cumbersome JVM can optimise based on runtime knowledge of the characteristics of the running code. In many cases, that kind of optimisation is more effective than the static compile-time sort.
Edit: the question is moot for Android, since it never used the JVM anyway, but the question is still sensible if you interpret it as "why use high level object oriented vm instead of low level vm"
(Azul made all of this work to make it their last tier java compiler).
It didn't take that many people or that long.
(Though in compilers, hard work on existing thing beats shiny shiny almost all of the time)
Assuming you already have a best-in-class JVM execution platform and have been building JVM execution environments for over a decade, you mean.
The parent was about what LLVM can and can't do.
I pointed out it does all the things the parent says it can't, and was made to do those things relatively quickly.
I gave a link showing it gives 5-250% better code than hotspot while doing so.
I'm not sure what relevance the existing execution platform would have to any of that.
As far as I can tell, it has "none".
Among other reasons, what the last tier compiler does has to be better than the other tiers, or it's a pointless waste of time. It's not like it can generate worse code and you can get away with it.
It also was not built in a way that requires their jvm execution platform, or anything like that.
You could take it and hook it into another JVM if you wanted, in roughly the same time frame.
The only difference is that instead of pretending it's hard or impossible, they just did the hard work to do it.
If the point you are trying to make is that you can't use it as a first tier or second tier jit, and that it would never work without some magical existing jvm technology, this would also be wrong.
"and have been building JVM execution environments for over a decade, you mean"
The folks involved had not.
I feel like you are just going off on a random tangent without a lot of data here, just because you don't want to say "yeah, i guess the parent was wrong".
I could also point out that LLVM is just about as old as Hotspot, for example (1999 vs 2000), and both are a decade older than Azul's compilers (2010).
Okay, but, uh... having never been involved in the conversation until that point, I could have just... not said anything about the parent? It just sounded like you were trivializing something which likely wasn't an easy thing to do.
The native API is pretty crappy, but trying to shoehorn LLVM IR into a Java bytecode replacement (which is not an easy task, see PNaCl) doesn't do anything to help.
Edit: ART handles Dalvik bytecode, not Java bytecode.
* Developers are adopting it to begin with, without the announcement, locally to Orlando it's a rising language for Android developers, nobody's forcing the language on them, they try it, like it and bam.
* Oracle lawsuit makes it a no brainer to accept other languages into the Android stack that could get them off their back.
* Kotlin native would allow Android to maybe someday ditch the Java based VM altogetherm potentially.
The tooling is also great and the language seems to be rather healthy.
Also code is still compiled to the same format that the Dalvik VM consumed. ART is just a different system for getting from Java bytecode to something executable.
mods: can we get this changed to the original title?
"The Language that Stole Android Developers’ Hearts"
1. The IDE support (without it, it would be somewhat more painful)
2. The fact JetBrains have built a really great new syntax and still have it compile down to regular java bytecode - and bytecode that isn't a total nightmare (I'm looking at you Scala!)
3. JetBrains use it themselves for their own suite of commercial products (mostly code editors) - this made me feel like it was less likely to become a toy language.
4. The fact that coming from Java it is absolutely painless - familiar syntax, automatic code conversion that works well for the most part, and full interop with Java.
This isn't a problem for most people but it is an issue for anyone who uses stuff like byte code instrumentation - take a look at this issue for example: https://github.com/puniverse/quasar/issues/45
It's not a criticism of Scala (the language is just a LOT richer so has to cater for more sophistication).
But the difference matters to me which is why I prefer Kotlin over Scala and I'm prepared to miss out on some of that sweet Scala magic.
> Peter couldn’t have known that more than three centuries and 5,500 miles removed...
However, if you are from eastern Europe, chances are you've ran into large brand of tomato products known by same name:
Kotlin is already popular in Android dev crowd. That is the one and foremost factor that why Google would support it. Because there is already a community and a robust toolchain(Thanks to Jetbrain) over there. It is a low-hanging effort for Google to claim by simply signaling a gesture with very little to commit really.
The Google announcement excites me for reasons beyond Android - I'm hoping that Google's huge investments in machine learning, play off along with the amount of investment it is going to do in Kotlin.
I would love to see a whole bunch of server side infrastructural components built out in Kotlin ... including things like Tensorflow, Spark, etc
More than Oracle, I think this is pretty much the death knell for Scala. When you have a far more pleasant language, with IDE integration that is mind blowing, and is supported by one of the largest companies in the world ... And probably is ALREADY MUCH MUCH more popular than Scala at this point
but I know what you are talking about - Spark is written in Scala.
So this is good news for kotlin...And bad for scala ;)
New life will come to Dart when fast Dart to JS compiler (so called DDC) will be released.
That's what I get at wikipedia for each language.
It would be far more accurate to say that Swift took inspiration from Scala (and Scala from ML, Smalltalk, Haskell, etc.)
Thought experiment: To be truly "original" a child that grew up with wolves in the jungle would have to come up with it (okay, not even that since it learns from the wolves). Everything else is "not truly original". Duh.
Now that we have established that no truly "original" ideas exist in any human's head (assuming "original" means going from totally empty, nothingness, to the idea), can we just get rid of all comments pointing out that X didn't really invent Y but was inspired by P?
Of course, what I just wrote isn't original in the slightest, I just don't know the names of all the people who said it before.
Kotlin copied Scala directly, renaming `def` to `fun`, `case` to `data` and so on. There's a big difference between creating and copying.
Anyway, in hindsight it was a great idea to cherry pick from Scala as the language seems poised for much bigger things (i.e. potentially becoming a mainstream language).
The Android APIs are still a major problem for me. In web front-ends we've basically gone full FRP and I'm sitting here with my resource files and 10 line invocations to make a notification.
This is partly because it's necessary for Java, but I'd love to see a first party API that tries out something a bit more fluent
It always feels like Android shipped with the low-level API but forgot to provider a higher-level API for the 95% case
Does Google not accept (major) external contributions to the build toolchains? Is it the official documentation that's getting rewritten for Kotlin? Or is Google releasing Kotlin-ified wrappers for the Android APIs? Maybe I don't fully understand what new privileges Kotlin is getting.
Google obviously won't support competing first class toolkits on Android. You can already use most JVM languages on Android as is, especially since the switch to OpenJDK. Giving Kotlin first class support is just adding it to their own in house tools. You can already use Scala, for example, if you want.
Qt is a great example of how hard it is to bring a 3rd party language to Android. Qt app on Android cannot use native theme, cannot interact with most other apps, don't behave like other apps perfectly, and can be a mess to deploy because of how many Qt libraries you need to bundle in. Google doesn't actively stop you from shipping a Qt app on Android, but it took the Qt company a lot of work to get support where it is now, and its still far from seamless (if you want an example of a great Qt on Android app, try Subsurface Mobile that uses the Kirigami widget set).
And yes, adding new things to Android is ... problematic, because Google doesn't accept pull requests. (It accepts bug reports, and sometimes patches of bugs.) And of course you can propose a big patch adding [see https://source.android.com/source/life-of-a-patch ] .. let's say Swift to the Android Platform, but the project owners are Google employees, and the community cannot really influence what gets accepted. [ https://source.android.com/source/roles ]
Are there any notable Android forks that are more progressive about supporting new languages? If so, is their market share consequential?
Replicant is the most "open".
Also, it's not hard to package all the stuff a language needs and put it into an APK. It's just messy and there are a lot of "edge cases" and things to work out (like the problem of interacting with the Platform, you'd need to call into a "Java" interface from your language, you'd need to run your app inside ART/Dalvik, maybe fork - https://stackoverflow.com/questions/39006044/repeatedly-fork... ).
And so if you spend half a year just getting something to run, and on the next Android version Google makes a change, and bamm, you might get left in the cold, because security or whatever.
I worked for an OEM at the time Google kicked us out of the SDK manager update list, so am familiar with the about face. If you do try to make your own toolkit, you'll have to fight very hard to do so. JetBrains writes IDEs and licensed Android Studio to Google, so there's no harm in Google helping them, but anyone else would be in for a lot of pain.
Won't the platform APIs designed for Java look and feel very non-idiomatic in Kotlin?
Android is stuck on older Java versions. Kotlin brings Java 8 improvements, and more, without all the Java baggage.
If that is true, why are these changes not being brought to Java itself, if they can be done without a change to the runtime?
Kotlin, on the other hand, can do much more intelligent transformations (look at its inline functions).
I've written few Kotlin applications. I didn't use Kotlin libraries, I used only JDK and Java libraries. I never felt that I would be better using Java. Kotlin is better in every aspect or at least not worse.
As pointed out, other JVM languages also have "Java interoperability" as top priority. Clojure does.
Clojure is getting popular lately, why isn't a "great candidate for the masses"? Because it is a Lisp? During most of the 1980s, the #1 programming language to teach children how to program was LOGO, which is basically Lisp in disguise...
Where is Algol on TIOBE?
If I would be starting with the platform now I'd start with it but now I dont see any reason!
Have you actually tried it or you just think you will be confused?
Swift was a giant improvement on Obj-c, imo. It was apparent in every way when I first looked at the language. I'm not getting that same vibe here with Kotlin.
Go: https://github.com/xlab/android-go and maybe https://github.com/gonativeio/gonative-android
JetBrains was already targeting Android as a big selling point for Kotlin because Android was still on Java 6 and lacked lambdas and streams and all cool new things Java has gained. Kotlin is also very close to Java. It adds some niceties for sure, but they worked hard to make Kotlin very close to Java. Data classes are great, but you could easily turn a data class into a POJO by generating the getters/setters/equals/hashCode/toString. The lambdas are great, but you could easily turn that into a Java 8 lambda or a Java 6 anonymous function. You might lose some elegance in the conversion to Java, but there isn't a lot of ambiguity in the conversion.
Kotlin support is relatively easy for Google. It already existed via the normal Java support. Supporting Go and Dart means supporting an entirely parallel set of things.
pub global run dart_repl
And I'm sure Go has a repl too.
Kotlin Native (Kotlin <-> C & Objective C) just came out this month, is still a technology preview, and AFAIK is really rough around the edges. Haven't tried it.
Kotlin has always had a very good Java interop story, in both directions. I've been using it for a year with Hadoop, AWS, JSoup, Rome, Jackson, DropWizard, Jetty, Apache Commons, ElasticSearch, Weka, and many other standard Java libraries and never had a problem. You basically drop in a library and go. Several of those libraries are either really old (eg. Weka was written in the last millenium) or pretty complex (Jackson is all annotation/reflection based), and I've never really had a problem. You do need to keep track of nulls yourself when crossing the Java boundary, and you need to understand what code Kotlin generates if you're implementing an interface or placing annotations, but both of those are well-documented and pretty typical tasks for any FFI work.
I'd been doing a bunch with smartwatches a year or two back, so the project before this was in Swift (because when I talked to potential customers & looked at market share numbers, starting with anything other than the Apple Watch was indefensible), and two projects before then were in Java (because the Apple Watch wasn't out yet and Android Wear & Pebble were the only games in town). There were also a couple ideas that I'd tested out using just WordPress and YouTube, with no coding at all.
JVM languages in general tend to "ignore" making Java native interface "work". Usually you're stuck writing java there.
Kotlin doesn't change any of that - you still need to go through JNI bridge and properly mark and pin objects as they're being owned by the other language.
And sorry for the poor phrasing in my question, I see how it can get confusing but I'm coming from iOS and I'm used to things being a bit more simple.
Also it might help to develop or improve live update features. If I'm developing server applications, I'm usually using JRebel which allows live reloads of bytecode and that's tremendous productivity gain. Same with React Native. I'm not sure about pure Android development.
The Android toolchain used to be horrendously slow but has gotten a lot better since they switched from Eclipse and Ant to IntelliJ and Gradle – assuming you have enough RAM to dedicate a few GB to the persistent Gradle process. It now has incremental compilation (of Kotlin and Java), incremental dexing (i.e. converting the compiled Java bytecode to Dalvik bytecode) and incremental reloading ("Instant Run"). And the emulator can run the x86 version of Android nowadays, so it's no longer slowed down by emulating ARM. It's pretty nice.
I just find it funny how Scala guys are saying "me too" at every opportunity. But that always comes with an asterisk, if you look closely.
IDE support is as good, Java interop is as good, etc.
Scala was around for a long time, perhaps if I could look at it with fresh eyes now I would consider it, but somehow I always had a feeling that Scala isn't for me. And now as Kotlin gaining momentum I'd rather stick with Kotlin.
I want first class IDE support and straightforwardness in my workhorse languages. For hobby languages I'd rather play with something like Red or Perl 6.
edit: so i checked this out myself. i have no idea why this is a big deal. another app language? i thought reactnative was all the jazz?
Kotlin is a language that is like a "better Java", just like C# is a better Java.
It happens to provide extension methods, it allows easy creation of domain specific languages, it fixes the Billion Dollar Mistake (no more problems with null!), etc. It’s basically Java, without all the boilerplate, and a lot more modern.
Which means any Android dev can easily use it, and be more productive, and create less bugs.
Google employees can destroy any post on reddit. Jetbrains copied that model. Anything about Jetbrains will have tons of artificial posts at the top, their crew upvoting it.
It's useless this sort of thing is killing social media completely.
WTF is kotlin and why would anyone in their right minds use a language from a text editor company. Beats me.
They also probably have an enormous team manipulating Reddit and hackernews votes (perhaps they run a internal email for everyone to vote and comment).
Kotlin is an unneeded solution to an inexistent problem. A language in no way comparable to Scala or Java. If you adopt it in your project you'll be in deep shit a couple years from now.
Devs are people like everybody else and can be hyped.
Let's give it time. Not sure what's the big fuss about. Yes I've read about GUI toolkits that reduce the development time. This still doesn't mean much IMO. The business owners will simply become more greedy and will demand more work for less money.
I really don't see how the devs will win.
Interoperability of Swift with the existing APIs and JVM is not impossible, but it is a significant barrier that needs to be overcome and needs very, very significant advantages to justify that.
You could use the same arguments in the article you posted to posit that everyone will be developing on a Mac.
It's not very convincing to me.
I suppose that Kotlin outside of JVM has a similar problem to Swift outside an Apple platform. You lose a support for quite a lot of already existing libraries. Rewriting everything in Kotlin and Swift will take effort and by the time we'll get there not many will want to abandon their preferred ecosystem.
Nothing that google says about Kotlin could possibly mean that it's not a phase, to be abandoned like other cult favorites before it. Is Kotlin more official than Wave? Reader? Fiber? Loon? Boston Dynamics? Picasa? Titan? Glass? Google+? Labs? Gears? Code Search? Health? Knol? Orkut? Answers? Deskbar? Page Creator? Sites?
Google has the right to stop supporting whatever they want, but there is a hard-to-measure cost in developer trust (and goodwill).
> How many products and services has Apple or Microsoft abandoned or shut down during their span?
Microsoft is the best example for commitment to API compatibility over decades, i.e. the polar opposite of Google.
It's really convenient for you that you only mentioned products that Google shut down and skipped the many products that Google still supports and constantly improving thru this day.
People mainly want sane APIs and a retained-mode graphics stack that does not suck. Instead, we got lipstick on our pig (and even here, Google has never been the driving force, but merely reacted to the community).