Micro: Stripped-down version with smaller binary size

[singalen]

micro is a fantastic editor that finally got it just right. No other editor in console could do it in the recent decades.

I'd love to use it on some very weak ARM devices. 11M binary size is way too much for that.

Is it possible to create a stripped-down version, probably without some features, but that's down to 1M size?

Thanks.

[zyedidia]

I think it will be difficult to get the binary size below 1M. Since Go statically links the standard library, even a hello world program ends up being quite large. On my Mac, a hello world program was 2.1M, and stripping debugging symbols using -ldflags="-s -w" (micro's build does this by default) reduced it to 1.4M.

The real kicker is using upx to compress the binaries. With upx I was able to get the hello world program down to 520K and micro to 4M. If I removed the plugin manager which ends up being a considerable size of the binary I could get it down to around 3M.

[singalen]

Thanks. Oh these modern "buy more RAM" languages 8(

[zyedidia]

It might be possible to dynamically link the runtime by compiling with gccgo but I haven't tried to build gccgo and don't see any prebuilt binaries.

[DanielPower]

It's a tradeoff between development time and optimization. There are plenty of languages that are more efficient in their memory usage, but they generally require more development time for the same program, or the code is more difficult to read, because the programmer needs to be more specific about memory management.

Particularly, a lot of the binary size is for debugging systems that are automatically built into the binary. The part that gives you a nice stack-trace if there's an error.

C may give you an 8000 byte file, but when you try to access an array index that doesn't exist, it just gives you whatever is in the memory it expects that array index to be in, without actually checking anything. And when it crashes, it gives you a nice little Segmentation fault, without any info on what caused the crash.

These new languages aren't just eating up memory because developers don't care about optimization. They're making use of memory that we expect on modern systems. C is going to remain the best language for those applications where the absolute smallest possible memory footprint is necessary, because C is written very similarly to machine code, and doesn't add any unexplicit code, for better or worse.

Discolusre: I am not a Go developer. But I am trying to learn Rust. Rust also has similarly large binaries.

[singalen]

@DanielPower true, except for the assumption that "modern system" is a PC or likely sized computer.
We agree that Go was never a system programming language. OTOH, people have successfully used Rust on microcontrollers, so great choice :)

[sum01]

If you need a super mini editor, use nano, or some hobby project like https://github.com/philiparvidsson/Worlds-Smallest-Text-Editor

[singalen]

Thanks @sum01. I followed your advice and found thee fantastic three:

• wed
• mle
• and dte

Future generations will have a good choice of tools.
Your reference, WSTE, will clearly not work on ARM.

[data-man]

These new languages aren't just eating up memory because developers don't care about optimization. They're making use of memory that we expect on modern systems. C is going to remain the best language for those applications where the absolute smallest possible memory footprint is necessary, because C is written very similarly to machine code, and doesn't add any unexplicit code, for better or worse.

Try Nim! :-)