Kotlin/Native v0.6 is Here | Hacker News Reader

Kotlin/Native v0.6 is Here

blog.jetbrains.com

79 pointsadamnemecek18 comments

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 guess the reason is that it isn't available for free.

It it is an understandable decision, as they aren't a charity.

However they aren't also an OS vendor, so it remains to be seen how it will evolve.

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

Simple, it's Apple's stupid App Store policies prohibiting JIT compilers.

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.

But Apple's JavaScript engine uses a JIT as well, doesn't it?

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.

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.

Java and C# have gone native since ever.

Most people just don't pay attention to the tools available to them.

.NET never used an interpreter. Code is either JITed on load, or compiled to dynamically linked binaries at installation time via NGEN.

Mono always offered the option to AOT compile and its their default deployment mode in iOS.

Then there is IL2CPP, CoreRT, Bartok MDIL and .NET Native.

The only exception, regarding Microsoft implementations was the .NET Micro Framework, used for example on NETduino.

On Java side, AOT was always available on commercial JDKs, specially the ones targeted to embedded deployment.

Now it is finally becoming available on the free JDK (alternatives like gcj never mattered).

Personally I am happy to see the mix JIT/AOT coming back.

It was the way with Oberon, Lisp, Eiffel, Sather, and we just got distracted because Sun was religiously against providing AOT support themselves.

EDIT: added reference to .NET MF.

dart never compiled to bytecode - there was no bytecode to compile to in the first place https://www.dartlang.org/faq#q-why-didnt-google-build-a-byte...

Dart story is a little different AFAIK.

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).

Reply on news.ycombinator.com