Posted an article on the current situation with Linux development support on Kotlin Native: https://medium.com/@napperley/linux-development-support-on-kotlin-native-ae78885e2d19

It's odd, because K/N was originally intended to be (at least in part) a platform for embedded targets, without the overhead and additional weight of a JVM. Now it seems like JB are just using it as a way to get Kotlin onto iOS, and leaving non-mobile platforms in the dust.

So much to be done ... It surely takes a lot of work and huge investments to meet all the needs with so much goals. And still JB has to earn money somehow, giving us most of their work for free 🙂

Linux ARM deserves a lot of attention. It is growing by the day

I personally think focusing K/N on WASM would be the most bang-for-the-buck personally. Then just execute the LLVM code on any system with a WASI runtime. WASM+WASI is going to take the place of Docker without the need for a Linux kernel.

The WASM effort isn't a replacement for Native. I see a place for both. Native allows you to leverage native libraries and get close to the OS. WASM is a great way to have a universal runtime that can move us beyond containers.

In all fairness, there is a huge difference in size between iOS and Linux. It makes sense to focus on the largest one

Size in what regard? In terms of usage by Kotlin devs, iOS is larger for sure, but I'd argue that embedded+server+desktop Linux outclasses iOS in terms of individual installations. It's incredibly common.

But do you need native on these Linux back ends? Regular Kotlin/JVM is certainly competent there, especially with the emergence of small footprint servers like Micronaut or Quarkus

Not for embedded applications, like I mentioned, which have memory and storage constraints. This was one of the original purposes that Kotlin/Native had—a target more suitable for embedded applications. It has a markedly better memory and storage footprint than Kotlin/JVM.

Ah I missed that. Yes, the footprint matters for embedded, but would you use any translation layer language for embedded? Feels like at best, you'd use Rust, but more likely, it's all C

I would, yes. It all compiles down to a tiny dynamically linked binary in the end—Kotlin, Clang, Rust, take your pick.

I guess I still disagree with that last part, looking purely at the size of the target audience and what alternatives are available.

I could make a similar argument with Objective-C or Swift.

Yes, it is for everything, but there are so many targets that it's critical to prioritize.

And you want iOS to be prioritized because it's more important to you. I understand that. All I'm asking for is Linux to not be ignored.

Oh no I don't care about iOS

Considering the market sizes of Android and Windows, it seems as though those should be prioritized over MacOS and iOS instead :p I think the reason those two are prioritized is because JetBrains uses MacOS extensively, as shown by all their presentations using MacOS demos

Well, current alternatives are a factor too. It's trivial to write Kotlin to run on macOS today (I bet a lot of people here do this on a daily basis). Same argument for Windows: generating .net IL doesn't seem super urgent when you can just use the JVM to run on Windows. But Kotlin on iOS? There is no current way to do this outside of Kotlin Native

iOS has a more apparent market share due to the limited number of individual types of devices that use it. Linux, while rarely directly consumer facing, is massive. Routers, CCTV systems, smart devices, microcontrollers, and especially servers. On these platforms, memory and storage footprints matter, and thus the JVM is largely unsuitable.

It's still a risky bet, mind you. Apple has relaxed some of the restrictions on non Apple languages on iOS, but if ever there comes a time where a lot of iOS apps are being developed in Kotlin to the point that Swift is threatened, Apple could suddenly ban Kotlin from its stores.

Dealing with Apple is dealing with the devil for sure.

In hindsight when I wrote the article I didn't take into account some of the findings from the JetBrains 2019 Kotlin survey ( https://www.jetbrains.com/lp/devecosystem-2019/kotlin/ ). One finding which stood out is that Linux is the top Kotlin Native target used in Kotlin Native based projects (at 74%, iOS is at 28%, Android is higher than iOS at 48%).

Huh, I forgot about that. Like I said, I think HMPP will help out development for Linux targets, since most of the code can be provided within a single source set.

I see a lot of community effort for iOS, including contribution to Kotlin compiler and tooling and see very little from community about Linux, it tells much more about actual demand than survey

If that is the case, it's probably because building for iOS has a lot more pain points compared to building for Linux 😄 Not to mention that Linux has a ton of general-purpose C libraries for use, and so there isn't much reason for us to contribute to tooling when so much already exists for what we need

probably because building for iOS has a lot more pain points compared to building for Linux

Exactly! That is my point! It’s big market, important for MPP with own ecosystem which requires a lot of attention to make it useful

Not to mention that Linux has a ton of general-purpose C libraries for use

Also Exactly! You don’t need pods, xcode or support of simulators, K/N support cinterop for very long time, and it actually similar to what you do when develop using C/C++

because it feels like they’re kind of being ignored.

So, it’s about “feelings”? Because I see commits which related not only on iOS

arguing that JetBrains needs to pay more attention to targets other than iOS

So deprioritize iOS and start publishing docker containers for Kotlin native or write documentation how to use existing linux tools for leak detection? It really looks quite strange for me Tho some points, such as Issues about cinterop looks more important, including task ids to blog post would be much more useful.

That issue being that neither the compiler nor generated binaries run on Alpine or Void Linux.

Why not just build own image based on alpine with K/N dependencies?

it’s an issue with JetBrains’ patched version of Clang, which we can’t modify

Is there an issue/discussion about it?

And they’ve know about this issue for months, and I know that it’s not a good comparison for me to make

There are thousands of issues on Kotlin tracker, and amount related on iOS is not less than specific to linux

I mean, if you want to argue that it isn't about feelings, you're arguing that you feel like iOS is more important because you see more surface-level activity around it 😛

I don’t have any particular feelings

I’m not against Linux, but I completely agree with what Cédric said There are so many differrent use cases for linux, most covered already with JVM, some supported, some not, but it’s only about priorities and demand. And it’s perfect area for contribution, even on some basic level

Which has laid unresolved since February 2019, despite it being mentioned that JetBrains would fix it in the toolchain update that occurred with 1.3.60.

so?

There are important issues that are severely limiting the compatibility of Kotlin/Native with the most popular target that the toolchain has according to JetBrains' own survey, and JetBrains elects to ignore these issues in favor of surface-level papercut issues specific to a single other target.

I see comment on linked issue “this task is too big, we don’t have enough time to complete it for 1.4”, sounds not so bad

Whether intentionally or unintentionally.

honestly, support one particular distribution doesn’t sounds as blocker

"Just use a different distribution" isn't an argument that works

I’m really hope that support of alpine out of the box will be released

The sooner the better, because I have people waiting on Alpine and Void support for one of my projects

Just about comparing with iOS, from which we started, see this issue about support of conusming cocoapods https://youtrack.jetbrains.com/issue/KT-30841 Created more than 1 year ago

Coroutines, Ktor, etc support for targets other than x64 would also be nice

so what should k/n team do? which task? One which has workaroud or one which doesnt?

The Alpine issue doesn't have a workaround beyond switching distributions, and I'm not going to demand that my users switch distributions because of an issue that's out of my control.

beyond switching distributions

Which sounds not very hard

Do you use Linux?

Also it looks that they are going to work on it, they saying it’s a big change

Alpine is indeed used a lot for Docker, but Void isn't. Void is used as a standard Linux desktop.

yes, it’s unfortunate, but for most cases, if you just want to run particular program in docker it’s not hard to use different distribution, yes, you may pay a few dozens megabyte of image for that

That's beside the significant additional storage overhead of using a distribution like Debian for containers.

so, how resources should be splitted? equally by amount of users on iOS and on Linux Void?

That's not a fair comparison

Yes, it’s overhead, I don’t say it’s the same, but honestly it’s not a huge problem in most cases

You're fine :p

yeah, hmpp should help a lot with different native targets

Yeah, I disagree with that point. I can see pretty significant advantages to changing the memory model in two of my three K/N projects.

Let me just remind you guys that KN is still experimental, so you have to accept these issues when living on the bleeding edge