Posted an article on the current situation with Li...

# feed

[napperley]

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

[serebit]

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.

[serebit]

Linux x64 has support for most things, but it seems like all the other Linux targets are being ignored at the moment. It's a shame, and I hope they get more attention in the future.

[serebit]

I imagine hierarchical multiplatform will help the situation, at least, since it'll greatly simplify code-sharing across similar platforms.

[Robert Jaros]

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 🙂

[corneil]

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

[jon.peterson]

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.

[corneil]

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.

[cedric]

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

[cedric]

(and I agree WASM is also very strategic)

[serebit]

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.

[cedric]

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

[serebit]

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.

[serebit]

Indeed, that was the reason that reflection was left out of the language entirely—it would add unnecessary bloat.

[cedric]

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

[cedric]

Or maybe Kotlin -> LLVM?

[serebit]

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

[serebit]

I'm not arguing that JB should abandon Kotlin/Native for iOS, because they shouldn't. I'm arguing that Linux shouldn't be playing second fiddle, because K/N is just as useful on Linux, if not more so.

[cedric]

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

[serebit]

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

[serebit]

Remember, this is what K/N was intended for. If it's meant to be a language that can be used for everything, ignoring the embedded systems entirely seems like a dumb move to make.

[cedric]

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

[serebit]

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.

[cedric]

Oh no I don't care about iOS

[cedric]

I'm just looking at the size of the target audience

[cedric]

I don't have a dog in this, just trying to be objective.

[serebit]

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

[cedric]

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

[serebit]

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.

[cedric]

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.

[serebit]

Dealing with Apple is dealing with the devil for sure.

[serebit]

I just don't see why iOS and MacOS should be prioritized over every other target when the whole focus of Kotlin/Native at this point is being multiplatform. Focusing on only one or two targets, or even just one related set of targets, seems rather counterproductive.

[napperley]

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

[serebit]

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.

[serebit]

And right after we have this discussion, the 1.4.0-RC blog post comes out, and all of the platform-specific K/N improvements are Apple-only. 😆

[gildor]

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

[serebit]

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

[serebit]

But we're not arguing that the community needs to rally around Linux. It's clearly already being developed for extensively. We're arguing that JetBrains needs to pay more attention to targets other than iOS, because it feels like they're kind of being ignored.

[serebit]

Hell, the main issue that I can think of with Kotlin/Native on Linux isn't even resolveable by contributors, because it's an issue with JetBrains' patched version of Clang, which we can't modify.

[serebit]

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

[serebit]

And they've know about this issue for months, and I know that it's not a good comparison for me to make, but I feel like that should take priority over the iOS changes made 😛

[gildor]

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

[serebit]

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 😛

[gildor]

I don’t have any particular feelings

[gildor]

I just understand rationale why it looks that there are more effort on iOS

[serebit]

https://github.com/JetBrains/kotlin-native/issues/3771

[serebit]

Which stems from the following issue

[serebit]

https://github.com/JetBrains/kotlin-native/issues/2674

[gildor]

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

[serebit]

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.

[serebit]

Which, obviously, didn't happen.

[gildor]

so?

[gildor]

I follow hundreds issues and some of them have years, some fixed eventually, some has high priority, some low

[serebit]

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.

[gildor]

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

[serebit]

Whether intentionally or unintentionally.

[gildor]

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

[gildor]

tho, alpine is popular, it doesn’t mean that you cannot use any other distribution with glibc

[gildor]

most popular target that the toolchain has according to JetBrains’ own survey

Oh, common

[serebit]

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

[gildor]

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

[gildor]

what I want to say, that it’s possible relatevely easy workaround it

[serebit]

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

[gildor]

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

[serebit]

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

[gildor]

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

[serebit]

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.

[serebit]

Maybe split resources? Both seem reasonably important.

[gildor]

beyond switching distributions

Which sounds not very hard

[serebit]

Do you use Linux?

[gildor]

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

[gildor]

Yes I do, personally and professionally

[gildor]

Alpine is used mostly for docker

[gildor]

and I use docker a lot too

[serebit]

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

[serebit]

Switching your OS for a Docker container? Easy. Switching your OS on your desktop? Significantly less so.

[gildor]

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

[gildor]

Yes, for desktop it’s very unfortunate

[serebit]

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

[gildor]

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

[serebit]

That's not a fair comparison

[gildor]

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

[gildor]

Nevermind, just joking

[serebit]

You're fine :p

[serebit]

I just hope the platform gets more love after HMPP

[gildor]

yeah, hmpp should help a lot with different native targets

[gildor]

I also don’t think that changing memory model is something “mobile specific” as Nick says in this blog post, it allows implement multithreading libraries such us coroutines or ktor a lot more easy, makes it closer to other Kotlin platforms, so It will benefit linux a lot too

After all, full-featured multitheread coroutines for k/n, or ktor server, would be a huge thing for linux cases as serverless

[serebit]

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.

[serebit]

Both of which are Linux-targeted.

[Big Chungus]

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