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.
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
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!
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.
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
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.
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.
Edit: sorry, I completely forgot googleio is today, and i couldn't believe this kind of news comminng ftom non google domain.
