I have used Kotlin Native a good bit now, and it feels quite natural and easy to use. FFI with nullable pointers fits quite well with the language's compile time null checks. I found it much easier to use than Scala Native, especially as a Windows dev. I am a bit sad they chose CLion as their IDE, but I understand why.
I really want to like CLion (it's pretty good, honestly) except I cannot stand CMake as a build system. Being able to use Kotlin Native with it sounds quite nice, because then I don't have to deal with CMake. It's a pretty solid IDE.
Is there a better alternative to CMake? I find its syntax painful and inconsistent, but once a project is configured, it works reasonably well for producing cross-platform builds.
Ostensibly there are dozens, since it feels like everyone makes their own….
Honestly most of the time I use autotools. I hate autotools, but it breaks less often and is usually easier to fix when it does. CMake will occasionally just refuse to find dependencies or will generate bad makefiles for me on less-common OSes like QNX and even on the BSDs.
I did use Premake for a time which is basically like CMake with less awful syntax and doesn't pollute all your subdirectories with files. Don't expect it to work on OSes other than Windows/Mac/common Linuxes though.
All of my Kotlin Native work was able to leverage Gradle and the konan plugin. I do not know the quality of Groovy support in CLion, but it is decent in IntelliJ.
What do you dislike about CLion? I don't really use C so I thought the minor issues I had with my toy projects wouldn't really translate over to people who professionally use the tools and know the ins and out of the language.
I was hoping to leverage multiplatform work primarily using the JVM and only dipping into native-specific code here and there, but this makes it difficult. It's not like they force me to use/buy WebStorm to use Kotlin JS.
I heard Dart is also going native in Dart 2.0
I am not sure I really understand the trend
The two most popular language (in the job market at least)
are Java and C#
It is weird, because Dart and Kotlin, are targeting being multi-platform, and the historical solution, was .. building a language that compile to byte code for a virtual machine
But now the trend seem to have changed
Now we have language, that compile to Javascript, webassembly, even C
And this is seen as an improvement
And DSLs were once very popular, I think this new trend of new languages that compile to everything, also goes againts building and using DSLs
I am still a believer in using different languages for different levels (Ousterhout's dichotomy), but it will be interesting to see, how this goes
I wouldn't call those policies "stupid", both from a security (a JIT compiler means you can't trust NX bits) and a battery-life/performance standpoint.
The security argument is bogus. The benefit over W^X is miniscule. The battery life argument is even more bogus, as JITs are likely to be faster for dynamic languages.
The benefit over W^X is that they already have it in place and usable.
A JIT, full-stop, is going to consume more battery in the general-purpose mobile case than compiled code will. Break-even points on performance certainly exist but mobile applications don't tend to run for that long. You might be okay with that tradeoff--and it is not an unreasonable one--but Apple does tend to prioritize battery life and performance over developer happiness on their mobile platform. And JIT and garbage collection are both red flags for iOS according to the people I know who've worked on the platform from a performance and a battery-life perspective.
"But dynamic languages"--Apple doesn't seem to care about dynamic languages, do they? Aside from JavaScript, which uses their own, tested, internally blessed, JavaScript runtime. Developers might get frothy about that--but iOS is where the users who actually pay for things are.
Well, one can always advocate that they can validate and secure as much as possible their own JIT compiler, including special OS paths, whereas for 3rd party ones everything goes.
Also Microsoft does exactly the same on store apps.
Just Google doesn't, because they never bothered to ramp up Java AOT compilation at the store level, rather using everyone's batteries and since that went pretty bad, now they have a mix of interpreted/JIT/AOT.
Flutter uses Dart. Flutter targets Android and IOS. IOS does not allow JIT. So they had to make AOT compilation (native) for Dart. Even before Dart 2.0 work started. In Android, first they used JIT but switched to AOT there as well. JIT is used in Dart console applications (server).
The biggest change with Dart 2.0 is that it uses a sound type system (strong mode).
