I’ve built a full android IRC client in 4.1MiB. Most UI elements are custom, no web view for anything, lots of custom libraries etc. That’s > 200kLOC. I can’t fathom what you’d have to do to get to 100x that.

The answer is assets. A lot of assets. Unused assets. Fonts. Gifs. Assets for every device size. Future assets.

200KLOC for IRC client? Where does the majority of code come from?

Quassel+Quasseldroid is actually a bouncer and a bouncer-specific client, so Quasseldroid handles none of the IRC parsing and state management parts.

Actually, over time I’ve split out a lot of code into libraries, so the app itself is down to ~70kLOC. Which is a normal amount of complexity for something like this. It has to handle notifications, chat formatting, avatar parsing and display, a ton of different UIs for configuring all the different options, etc.

· ~15kLOC bouncer internal protocol code

· ~1kLOC local caching + persistence

· ~40kLOC state handling and UI

· ~13kLOC fixing android bugs and compatibility with older versions

With the split, that moves 24kLOC into the internal protocol lib. Another ~100kLOC are now generated at build time through ksp (a type of macro preprocessor for kotlin).

Further breakdown of the UI part:

· ~7kLOC XML layouts

· ~7kLOC included default settings

· ~7kLOC Chat UI Code

· ~5kLOC Settings UI Code

· ~3kLOC Setup and initial configuration wizard

· ~10kLOC background processes, notifications, protocol handlers, etc

Can’t imagine an IRC client has many high resolution assets.

Why should it? Android supports vector assets, I ship everything as vector drawables. 98 vector assets, full text of 11 licenses and translations for 9 languages are > 90% of the 4.1MiB

That said, what assets does an email client need beyond what I use as well?

C and Go are at a very similar level of portability. Statically link your C binary with musl and it will run everywhere the Go binary (built on the same system) would. Neither Go nor C will run outside their architecture or OS, but both can cross compile.

Go makes both processes more user friendly. Statically linking with musl is simple in C (musl-gcc), but cross compiling is a bit of a pain the ass to set up (building your toolchain from the ground up). Not too bad, and if you're messing with building portable executable this kind of knowledge is assumed.

> Golang binaries are like 5-15x the size of a dinamically linked C binary, yes, but at least they provide everything and run everywhere.

I once ported a shoddily written (by me) Python script to Go. About 400 LOC in Go. The compiled executable size was a whopping 7 mb!

This was more than I expected.

It turns out there's a reason for large executable sizes in Go [1], and apparently it can be made smaller.

[1] https://go.dev/doc/faq#Why_is_my_trivial_program_such_a_larg...