Android now supports Kotlin(venturebeat.com) |
Android now supports Kotlin(venturebeat.com) |
Eh, I'm moving on from Python so if they never threw the ability to build apps for android with python that'd be fine, too.
Am I the only one that finds Java's (and Java 8's) syntax fine. I like the traditional type annotations and perceived verbosity.
If they can deliver good kotlin native experience, then kotlin is unbeatable
Groovy’s creator famously said that, had he known Scala, he’d never have invented Groovy.
Edit: sorry, I completely forgot googleio is today, and i couldn't believe this kind of news comminng ftom non google domain.
I use Pycharm and have used other Jetbrains IDE's in the past. They make me soooo very happy to use. That is, I have tried almost every Python IDE and suped up Vim/Emacs; None of them came close to Pycharm for me. They know cross platform. Their IDE's are just as bad ass on the macOS as they are on Windows... again, for me.
They make IDE's for just about everything and I assume they are all of stellar quality. My assumption, as of about 30 minutes ago, is that Kotlin could be a great bet for cross platform development in the near, near future. Jetbrains has every reason for this language to succeed in as many places as possible. Web, Mobile and Desktop. The fact that it runs on the JVM and compiles to JS out of the box makes me wonder why I haven't tried it yet.
I'm still a few weeks away from launching, but I'm writing a little game that I'm going to ship on iOS, Android, Windows Phone and desktop (UWP), and web (with react-native-web.) They all share 99% of the code, except for a few native modules.
I've had to do a ton of work to get all of this working, but I'm going to release all of my changes, open source libraries, and a boilerplate so that it's easy to get started.
After the initial release, I'm going to be adding support for Mac, Xbox One (UWP), Apple TV, and maybe Linux. Mac and Apple TV are both forks of iOS that share 90% of the native code. Xbox One almost works out of the box, and I just need to add gamepad support. Linux is the only platform that is missing - Canonical's Ubuntu fork has stalled and no-one seems to be working on it.
I'm also keeping an eye on Kotlin. I just found out that it might be possible to write cross-platform React Native modules using Kotlin. (I was planning to use C++ or Rust for some shared code.)
I was aiming for Windows/Linux/Mac/iOS/Android.
In the end the two platform that were closest at the time (summer 2016) were HTML/Javascript and C#. Or C/C++ with OpenGL for the hardcore (not me!).
The real killer these days is the GUI toolkit. Ideally you'd want a SWT/Wx type wrapper around native widgets, most likely with a desktop flavor and a mobile one. Unfortunately nobody's investing in it, I think there's not enough money to be made. And there's no OSS community for it...
Except all those platforms have different paradigms regarding UI, and different ideas regarding base components. Even if you could have your code run on all of them, you'd still be writing platform specific code.
Throw in TornadoFX and Gluon Scene Builder (formerly of Oracle) and you're spinning up high-quality cross-platform GUIs faster than Atom, with a visual editor, and without having to touch Javascript!
I've been trying to find a suitable, high-quality cross-platform GUI kit for a while and this looks like it might challenge my current favorite (GTK)
1. it gets very confused about the focus when alt-tabbing between windows (as alt, on Windows, also toggles focus on the menubar),
2. there is no attempt to solve the problem of submenus disappearing when you attempt to move the pointer towards them, which is solved in Windows and Qt with a delay, and in Mac OS and GTK with ... the solution that is actually documented in the OpenJDK wiki but not implemented: https://wiki.openjdk.java.net/display/OpenJFX/Menu+User+Expe...
So JavaFX might be high-quality in some way I haven't noticed, but to me its immediately noticeable qualities were its general slowness and brokenness.
You might be able to write an ndk app targeting android with you own stack of widget, but that's very different from an 'sdk' app.
Now that you mention it mobile support seems to be in flux: http://stackoverflow.com/questions/20860931/is-it-possible-t...
Check out Codename One which is more like Swing but far more robust. The GUI builder isn't as refined as scene builder but the final product actually works everywhere and far more portable than anything else.
Wondering if Jetbrains will release Kotlin/Native for a set price or charge monthly like most companies are doing these days.
https://blog.jetbrains.com/kotlin/2017/05/kotlin-on-android-...
Unfortunately, corporate policies and hubris matter more in these things.
Kotlin was already mostly working with Android thanks to a community effort. This announcement just gives it Google's blessing and gives you all the Kotlin tools by default in Android Studio. Going forward they'll likely be working closely with the Kotlin developers, but this was primarily community driven.
Apple did a great job with Swift but launched it when it wasn't mature yet but Kotlin will have JetBrains level of IDE support from the get go so and it's mature already only a luddite would stay with Java.
Kotlin was released in 2011. I bet that if Google had adopted it three years ago, it would have helped accelerate Kotlin adoption and Kotlin would be even further along today, having a much larger developer community.
[0] https://blog.jetbrains.com/kotlin/2016/02/kotlin-1-0-release...
Don't confuse professional programmer who would use language whatever client/employer decides with luddite.
Annotation processing works fine with kotlin.
First setup can be a pain though, especially if you are not familiar with Android or the gradle build system.
Is it worth me looking into Kotlin? I am already halfway through investigating Swift so it seems the endless task of keeping up to date with new languages for each platform (keeping up to date with the changes in C++ and the STL is a mammoth task in itself).
But I still suggest you to look into Kotlin. If you know Java, you won't spend much time learning it and with awesome IDE support you can be productive in very short time. You might find that you'll just prefer Kotlin over Java for a lot of little things which makes coding more enjoyable.
Not for long, they're working on Kotlin Native which will make it completely independent from the JVM and portable to all platforms. Killer.
Source: I've been developing Android apps for 2 years and closely follow all developments in the community.
Java is still and always will be the core language of the JVM. It isn't going anywhere and the Java team (comprising mostly ex-Sun people) continues to push the language forward under Oracle's fantastic stewardship. The issue is that Java is required to be more stable than other languages since it powers so many production, enterprise system and hence will be slower to innovate.
I have seen no widespread movement to jump from the Java/JVM ship if anything more and more people are moving towards it because of languages like Scala, Clojure, Kotlin etc.
You do not have to install a preview version of Android Studio, you can install the kotlin plugin in whatever version of AS you're using now. The change in AS 3.0 is simply that it will ship the plugin by default.
1 - skim the language documentation (depending on your familiarity with java, this will be more or less easy)
2 - download intellij, clone the kotlin koans repo and do these exercices.
After finishing the koans, you will have a good grasp at kotlin's basics.
[1] https://discuss.kotlinlang.org/t/android-support-in-kotlinc-...
Kotlin on the other hand has a tiny runtime (< 1 MB before dead-code elimination etc with Proguard) and negligible startup cost - in fact several popular Android libraries have a bigger startup cost impact than Kotlin.
I am not too familiar with Clojure, what would it bring us that kotlin (or java) don't have ?
And lots of other things too. I just wanted to make a lisp joke. I will see myself out.
http://steve-yegge.blogspot.com/2017/05/why-kotlin-is-better...
They're here to stay and they're a joy to use. Jump on the happy wagon and join us!
Will Kotlin add any extra data to an Android app? Does it have it's own runtime, or does it just compile down to the same bytecode as Java?
If the app size is equivalent to Java, then this is amazing. I love Kotlin, and will write all of my React Native libraries in it (as soon as there is some support.)
UPDATE: Looks like the Kotlin runtime is around 859KB. Maybe smaller after ProGuard? In the grand scheme of things, that's smaller than many web pages. But it's probably not suitable for an open source library.
I don't think Facebook would rewrite React Native in Kotlin. I've heard that they might be moving towards C++, so that more code can be shared between the different platforms.
The only thing that Kotlin misses is XML Tags inside the language, but they could be modeled with DSL API.
That said, I don't think that Facebook would rewrite react native. It's an impossible task and they don't really need it. But I hope that some big player will replicate react native with Kotlin.
I don't think the GP meant replacing JS with Kotlin, rather they're referring to implementing React Native modules in Kotlin instead of Java, keeping the JS part untouched. (As you may know, React Native modules/components require native implementations before they can be used in JS).
I hope that clears things up a bit!
Heck, their JS implementation still generates massive binaries. Targeting the JVM/Android? Sure, good to go; otherwise the promised land is a long way off.
"Currently Kotlin/Native uses reference counting based memory management scheme with a cycle collection algorithm. Multiple threads could be used, but no objects shared between threads are allowed."
They have also said that it's pluggable and they might experiment with other collectors on different platforms, but it's hardly "unknown".
The size of generated JS is definitely a problem at the moment but they're working on it:
It seems the only "beta" platform listed there is LLVM, which doesn't even work on Windows yet. The point is that we should expect these things to improve quickly. JetBrains are hardly hacks. Kotlin existed in production being used by major Android apps while significant libraries were still incompatible.
I doubt believe anyone read my comment and thought, "WOW, I should pitch this for production on every platform today without even investigating." It's a useful data point as proof of where they intend to be quite soon.
I am very interested as Jetbrains is also working on Kotlin to native translation. [1]
[1]https://blog.jetbrains.com/kotlin/2017/04/kotlinnative-tech-...
> For more information on getting started with the programming language, check out How to start using Kotlin[0] and the Koans tutorial[1].
[0]: This one's actually broken in the article, but: https://kotlinlang.org/docs/tutorials/kotlin-android.html
Kotlin compiler generates code that's runnable on JVMs supporting Java 6, which makes it work on pretty much any Android device, even running older Androids.
Scala standard library is also huge and pretty much immediately hits the 64K method limit of DEX files forcing you to use the very slow proguard compilation step when running it. It also has issues with interoperability with existing Java 6 code.
All in all, Scala is a terrible value proposition in comparison to Kotlin which was built from ground up to modernize programming while still keeping full compatibility with Java 6 code and JVMs stuck on Java 6 language level.
guess that requires a recent android device :(
The one thing I'm having trouble figuring out, though, is how much it diverges from Java in terms of inheritance, traits, etc. The verbosity of Java is one thing, but its inheritance system is what made me want to pull my hair out.
Languages like Scala, Haskell, Rust, etc. are preferable to me in that way. Kotlin seems nice and clean--from what I've seen so far, with this "Android bump", Kotlin native, etc., I could even see it replacing Python--but I worry there's something lurking deeper.
This is the clearest thing I've found so far, but it's very old at this point:
http://codeofrob.com/entries/looking-at-kotlin---kicking-the...
It includes this quote that stokes my fears: "It feels as if the language designers haven't really designed at this point, they've just thrown a load of stuff at the wall because inheritance is something that all Java developers want and given us a few bad ways of doing something as well as something that has the potential to make us write better Java."
I don't have any attachment to Scala. However, I do think Scala, Rust, etc. have moved language design forward in significant, fundamental ways, and it would be nice to see those advancements recognized in the Android platform.
Take this all with a grain of salt, though, because I know next to nothing about Kotlin.
Developer reasons: Scala is a much more elegant language. Failure reporting in Kotlin completely sucks (in some ways it's worse than Java since they've removed checked exceptions and not offered any substitute - they make a lot of fuss about handling null/options but all that completely breaks down as soon as you want to actually report a reason why something failed). Typeclasses with automatic derivation are really nice. In a big application I might like to be able to do FRP stuff or async pipelines; not only does Kotlin not have an equivalent to fs2 but it's impossible to write one in the language. Every time a new thing comes along Kotlin adds it into the language as a new, different feature because they're allergic to offering general features you could use to implement things yourself (e.g. async/await).
- being documented on https://developers.google.com
- being installed by default with the SDK
- having official tutorials provided by the Android team using Kotlin
- having code samples provided by the Android team using Kotlin
Providing the confidence to many companies out there that Google will not change Android in a way that Kotlin compiled applications would stop working.
This is about: Android now supports Kotlin
Kotlin has been unofficially supported already by the Android tools team for some time. Meaning that they would work with the kotlin team in order to make sure that when a tools update breaks the kotlin build tools, they can be fixed in a timely manner.
Now that it is officially supported, we might have : - idiomatic android api for kotlin (there is already 100% interop, but sometimes java's code can be better expressed in kotlin) - official android documentation in kotlin. - I guess that kotlin will focus even more on Android's support
It is not going to change anything regarding kotlin compatibility with Android. Since kotlin outputs bytecode, it would be almost impossible for Android to permanently break kotlin compatibility without also breaking 99% of all Android's libs.
Official support will also make it easier for people to push for Kotlin in larger projects
Go is going to have better support on Fuchsia OS from Google.
Kotlin, however, interops with Java nicely since it compiles to jvm bytecode. So there's no new APIs to build and no transition performance costs.
Although that said you can actually use Go on Android ( https://github.com/golang/go/wiki/Mobile ) but since Go is native code you're stuck with Android's NDK or dealing with JNI and the performance costs of that.
1) interoperability between existing ecosystem and APIs
2) development environment support.
In case of Kotlin Google had to do nothing: Kotlin is 100% interoperable with existing Java code and libraries, including Android APIs; as for the development environment, JetBrains (the company behind Intellij IDEA and Kotlin itself) provides the same level of development experience for Kotlin as for Java, which means that Android Studio gets the very same nice features for Kotlin.
Now, how would they get the same with Go? For interoperability they would need to either generate tens of thousands of bindings for existing APIs and provide a convenient way to include compiled Go binary as a static library. It is highly doubtful they actually can do, since they have been having troubles to do it for C or C++ code for a very long time. Or as alternative they can improve their support for native code, which then can be used as a base for interoperation with Go code; however it is still considerably less pleasant way to do things than in case of Java + Kotlin.
Now, as for the development environment, Google will have to basically create yet another IDE on top of Android Studio to support Go; they might take an existing plugin (which is not that great, compared to Kotlin support in AS/Intellij), but it means that they would have to collaborate in development on it, which in case of Google takes too much time. Another indicator of how difficult for them implement at least someway decent support for another language on their own is situation with native code - it's being in development for like 3 years, and still is highly unusable.
Go doesn't seem to be used that much other than a few known projects like the stuff that got re-written for YouTube or the download server.
You see this when new Web APIs are released, usually Go isn't part of the preview SDKs, and on Android all the work done on Go mobile has been done by people on the Go team or from the community at large.
On android, everything gets AOT compiled on install already.
http://gluonhq.com/products/mobile/javafxports/get/ <-- android, iOS, ARM
However it seems to be a barebones solution as it lacks mobile-specific controls (they want you to buy Gluon Mobile for that)
Nowadays, you can just copy paste it from an existing github project.
(PS. I am new in both the languages and no Swift expertise)
I don't doubt that 2-3 years from now Kotlin will have a cross platform solution, but to claim so today is borderline delusional. It's understandable that users are excited, Kotlin's on the verge of bigger things, perhaps even mainstream level adoption if everything falls into place, but there's a ways to go before they achieve one-language-to-rule-them-all.
Which allows full control how async/await works, kind of like on the upcoming C++ co-routines, where async/await become syntactic sugar for blessed data structure.
EDIT: Should have provided the actual information.
The feature as introduced in C# 7 is called "Generalized async return types".
What I am not happy with this whole browser platform embedded in frontend apps and called native and amazing. But that's for another discussion:-)
So the Java 8 tools you're talking about essentially take Java 8 compiled bytecode and patch out the parts that aren't compatible with device JVM (e.g. they replace lambda invocations with anonymous classes like you'd use on Java 6 etc.).
This doesn't work for things like Scala which use these new features in patterns those tools can't patch/recognise.
Kotlin has the entire java ecosystem to work with.
I'll keep writing Java to build Android apps though. I'm sure it's "more fun" or whatever, but Java's worked just fine for me thus far. I'm used to the verbosity, and have no desire to start from scratch with another language. If some huge benefits were presented, I would. But, I'm failing to see any.
It’s a huge improvement.
As I learned through the years, anyone that decides to step outside the SDK tooling accepts the lack of productivity that entails the extra work, making the unofficial tools fit into the SDK expectations.
So why should JetBrains spend development resources (work time * salary / hour) into something that isn't a standard tool just to get brownie points?
Source: I closely follow all developments in the Android ecosystem, and have been doing so for over 2 years.
https://en.wikipedia.org/wiki/Kotlin_(programming_language)
Anyway, that's my point. Apple iterated Swift quickly in 3 years, and Swift is a very nice language now. Some sort of support, or even acknowledgement, from Google could have accelerated Kotlin.
Seems that automatic type inference is something that's really nice for one page programs but explodes in complexity for the compiler once you start to do it in big programs with complex structures (nested dictionaries) or methods (like chaining flatMap with filter with join).
I'm trying to work with R.Swift and IBAnalyzer nowadays to have a 100% "if it compiles it doesn't crash" solution even while using Storyboards and that alone increases my productivity more than any left over annoyances at the moment might decrease.
Swift 1.x was horrible though. I had to pick up a project left half finished by a junior to finish it. What a nightmare. Every new Xcode point release broke everything
Regarding Go at Google, if you have better sources of information to share with those living outside Mountain View, it would be very helpful.
I build a simple Pacman game. Running on Android wasn't a problem even though the builds took an entire minute to complete.
Compiling and running on iPhone was a nightmare though: At the beginning of the project I was able to run it - some days later I had to tweak the RAM being allocated to the trans/com/whatever-piler - a week later and the weeks after I was unable to compile it at all, there just wasn't enough in my MacBook to throw at the thing.
And the subjective performance was relatively bad too. They tried to reimplement Material Design and it looks somewhat like it, but it performs pretty badly.
Even their own conference app demoing Gluon Mobile is terrible and that says a lot.
Notice that this is a compile time feature, you don't need to use it for production.
I'm also against "cloud everything" but here they seem to provide an actually useful service.
Actually the NDK is not even finished migrating from makefiles into CMake, let alone switching to even something else.
As you describe it is work in progress, not fully done, without any perspective if it will ever be part of the official SDK.
Also last time I checked AOSP sources where actually slowly being migrated to GB, the only place where Go is kind of used in Android.
So what is again the business value of supporting an unofficial tool, spending development resources, just for getting a few brownie points?
Why do you think that natively compiled Kotlin would be slower than Go, anyway?
This means you could quickly transform any existing app into a Kotlin Native app quickly.
I'm thrilled that Google is supporting Kotlin, though. Official support for Scala was never going to happen, and Kotlin sounds like a huge step up. I regret sinking so much time into struggling with Scala on Android.
They have deep experience with the syntax of a bunch of different languages. They know what Java is missing because they've seen a ton of different things in diverse languages.
Looking at Kotlin myself, they got rid of almost all of the painful syntactical blunders in Java. I'm seriously considering picking it up for my next project just looking at their main page. It looks fantastic.
Also remember that good compatibility with Java is a big priority for Kotlin, so inheritance works very similar to Java and compiles to the same obvious JVM structures.
https://en.wikibooks.org/wiki/Scala/Traits
Or, in another example, how does use of Rust impl map onto Kotlin?
http://www.jonathanturner.org/2016/02/down-the-rabbit-hole-w...
I really don't mean this as a criticism of Kotlin, I'm just trying to map this all out. Kotlin seems nice and like something I could use, but I'm sure it has its boundaries also.
Hey, at least they've got nullable types? That's a big win over Java right there.
Can you elaborate what you mean by nullable types?
You can set Object variables to null and with primitives you can do the same with their boxed alternatives (Integer) but I assume you mean something different?
Like the lack of types which can't be null? I can see how that's useful
In Kotlin/Swift by default all types do not include "bottom" or "null". You add a ? to the type to indicate you may use that value, then the compiler will validate you're checking for the existence of null before you use the type.
It's one approach... I prefer the Haskell approach with a simple Maybe/Option type.
The Kotlin page does a good job of explaining it if you aren't familiar. It's the single most important feature that makes Kotlin worth using over Java in my opinion: https://kotlinlang.org/docs/reference/null-safety.html
After 2 hours with the kotlin koans (short exercises allowing you to learn the language), it was already clear that Kotlin solves most of java's limitations when writing android apps.
higher order functions : so powerful .. at the cost of dex (and I don't really care about dex size), I can get very flexible calls.
nullability backed in the compiler
100 % java interop
data classes
default parameters values ..
etc
IIRC, the larger runtime was what prevented Scala from being interesting on Android. I know that Scaloid has been working on making it more svelte though.
Many of the important devs on the V8 team, like Gilad Bracha, were getting tired of working on the project and started to look elsewhere for a career change.
Allowing them to create their own vision what a JavaScript replacement might look like (aka Dart) motivated them to stay on the team and at Google.
When the Chrome team decided that they wouldn't be merging the Dart VM into Chrome at all and would rather focus on JavaScript, including their efforts for adding type annotations to JavaScript, the Dart team was going to be assigned new tasks.
However in the meantime the AdSense team had started using Dart and they enjoyed using it quite a lot, so a decision was made to move the Dart team away from Chrome into supporting the AdSense team as main role.
If this is not true, I would welcome any Googler that knows better, to correct me.