Why are binaries from kotlin native so much bigger...

# kotlin-native

[ursus]

Why are binaries from kotlin native so much bigger when compared to say Rust?
Is the runtime really contributing 500KB?

[Youssef Shoaib [MOD]]

It has to ship with a GC, so yes that's why. It would be more fair to compare it to another GC language like Go maybe

[ursus]

Go includes runtime in the binary?

[Youssef Shoaib [MOD]]

I think so? At the very least, it is garbage collected, and thus any "full" binary will have to include their GC implementation

[Youssef Shoaib [MOD]]

Kotlin, at the end of the day, compiles to LLVM, same with Rust, Go, etc, so the differences must be in GC and other runtime things

[ursus]

Yea I get that, it's just im surprised theres no vm in the host for GO

[ursus]

but i dont know anything about go, nevermind me

[ursus]

ok thanks

when I compare a simple http request+json parsing its 4.5MB for kotlin native & 3.5MB for rust

which is comparable, good; is probably just the dependency-less hello world that's skewing the numbers

[Youssef Shoaib [MOD]]

Yeah, the "right way" to compare here would be to take the baseline of a hello world app, and then measure the difference in size when you add more dependencies and code.

[ursus]

Yea im just more generally surprised by the sizes when coming from jvm, where the jars are tiny

[Youssef Shoaib [MOD]]

That's because the JVM requires, well, a VM, which has all the GC things and everything. I do wonder if a Kotlin runtime dll of sorts could be made, and simply required to be installed once

[ursus]

yea because its probably not apples to apples when comparing to cpp where the binary is like 20KB

[Arjan van Wieringen]

I dont want to sound pedantic, but in which cases do these sizes nowadays still matter? I am all for small binaries but there is a large continuum here. There are some serious use cases for tiny native binaries, but these are limited and IMHO people often focus too much on this.

[ursus]

Im just wondering where is the size coming from, since same program in swift is 60KB

[Arjan van Wieringen]

Ah, that's fair. These are always good questions. Go compiles with some sort of runtime included, which includes Garbage Collection and reflection capabilities. Rust works in a completely different way of course, having no GC at all and no runtime to speak of. Swift I have no experience with, but note that Swift uses dynamic linking to a shared Swift library of 27MB. So in a lot of cases it not comparing apples to apples.

[ursus]

yea

[Mikolaj]

Is it possible to exclude the GC when building kotlin/native? For example I want to write a simple CLI program. I even would not bother to free the memory myself rather rely on system to reclaim it after program returns. That way spinning up entire GC seems pointless

[loke]

The entire language relies on the GC existing. It's not like not running will have any measurable benefits anyway.

[loke]

Startup time for kotlin native is really fast anyway (compared to the JVM)

[Landry Norris]

If you really want to turn off the GC, you can set it in the gradle properties (see https://kotlinlang.org/docs/native-memory-manager.html#disable-garbage-collection). You should only do this for a program that is bounded in what it can do, and only runs for a short time.