5 ms·

It's ridiculous. The complete size of Mario 64 with all assets is 6MB.

anthk 5y ago
And the whole 9front weights less than those apps. When I was a Windows user, a video player install of more than 80MB would be slightly bloated. Today my OpenBSD install uses less than 3GB and it has far more stuff than a phone install. Golang binaries are like 5-15x the size of a dinamically linked C binary, yes, but at least they provide everything and run everywhere.
- kuschku 5y ago
  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.
  - antihero 5y ago
    Can’t imagine an IRC client has many high resolution assets.
    - kuschku 5y ago
      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?
  - selfmodruntime 5y ago
    The answer is assets. A lot of assets. Unused assets. Fonts. Gifs. Assets for every device size. Future assets.
  - chakkepolja 5y ago
    200KLOC for IRC client? Where does the majority of code come from?
    - kuschku 5y ago
      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
- dj_mc_merlin 5y ago
  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.
- 2143 5y ago
  > 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_large_binary https://go.dev/doc/faq#Why_is_my_trivial_program_such_a_larg...

And the whole 9front weights less than those apps. When I was a Windows user, a video player install of more than 80MB would be slightly bloated. Today my OpenBSD install uses less than 3GB and it has far more stuff than a phone install. Golang binaries are like 5-15x the size of a dinamically linked C binary, yes, but at least they provide everything and run everywhere.

kuschku 5y ago
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.
- antihero 5y ago
  Can’t imagine an IRC client has many high resolution assets.
  - kuschku 5y ago
    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?
- selfmodruntime 5y ago
  The answer is assets. A lot of assets. Unused assets. Fonts. Gifs. Assets for every device size. Future assets.
- chakkepolja 5y ago
  200KLOC for IRC client? Where does the majority of code come from?
  - kuschku 5y ago
    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
dj_mc_merlin 5y ago
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.
2143 5y ago
> 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_large_binary https://go.dev/doc/faq#Why_is_my_trivial_program_such_a_larg...