
Kotlin/Native v0.6 is Here - adamnemecek
https://blog.jetbrains.com/kotlin/2018/02/kotlinnative-v0-6-is-here/?
======
kodablah
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.

~~~
PeCaN
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.

~~~
rlp
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.

~~~
PeCaN
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.

------
systems
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

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

~~~
eropple
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.

~~~
modeless
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.

~~~
eropple
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.

