Hacker News Reader

Hacker News

Comment by adontz | Hacker News Reader

Full thread

adontz

8.5Mb is a little too much for editor named micro. Whole DD-WRT/OpenWRT Linux Image is twice smaller.

View on HN

That's because Go hasn't been historically very good at keeping binaries small.

However things are starting to get better: https://blog.golang.org/go1.7-binary-size.

I think the name is a play on the other popular editor 'nano'.

Allowing it a comfortable 1000-fold growth factor! :-)

For a comparison, my /usr/share/atom folder is >200Mb - just the main Atom executable alone is over 54Mb.

The binary is unstripped. Strip it, and it loses ~3 MB.

also statically linked, at least on osx.

And on x86_64 and ARM.

All go binaries are statically linked. It's supposed to be one of the selling points of the language.

Go packages are statically linked into Go executables, yes. That doesn't mean that C libraries are, though -- and I think it's that level of static linkage that the parent meant.

If you're on macOS, try running $ otool -L some-go-program, or on linux:

  $ ldd ./team-service
        linux-vdso.so.1 (0x00007ffe492af000)
        libpthread.so.0 => /nix/store/9xsjqbsldr86vvs7p5ps4qlkjv9dhc0k-glibc-2.23/lib/libpthread.so.0 (0x00007f47ef267000)
        libssl.so.1.0.0 => /nix/store/v9mq9iv2sg017r7i0fpw8qlifvlpvlks-openssl-1.0.2h/lib/libssl.so.1.0.0 (0x00007f47eeff6000)
        libcrypto.so.1.0.0 => /nix/store/v9mq9iv2sg017r7i0fpw8qlifvlpvlks-openssl-1.0.2h/lib/libcrypto.so.1.0.0 (0x00007f47eeba4000)
        libc.so.6 => /nix/store/9xsjqbsldr86vvs7p5ps4qlkjv9dhc0k-glibc-2.23/lib/libc.so.6 (0x00007f47ee803000)
        /nix/store/9xsjqbsldr86vvs7p5ps4qlkjv9dhc0k-glibc-2.23/lib/ld-linux-x86-64.so.2 (0x00007f47ef484000)
        libdl.so.2 => /nix/store/9xsjqbsldr86vvs7p5ps4qlkjv9dhc0k-glibc-2.23/lib/libdl.so.2 (0x00007f47ee5ff000)

So go libraries can't be GPL'd?

The compressed binary is only ~2.6mb.... Whereas nano is only 141k on my system uncompressed.

And kilo[1] is 28k but it doesn't have as many features. Also a "keyboard" vs "keystroke" editor, editors built before ginormous keyboards became ubiquitous use various keystrokes for commands, ones that came to exist in an assumed presence of a ginormous keyboard use special keys for commands. (example, if the only way to move the cursor up in your editor is the cursor up arrow key, you are a "keyboard" based editor. Not that either choice is better or worse just something I find an interesting distinction.

[1] https://github.com/antirez/kilo

That's weird, I didn't know keyboards used to be smaller. I assumed they started with the space cadet and kept shrinking.

You are right, that isn't the correct analysis. Initial programming editors like EMACS, vi, EDIT, TECO, FINE, SOS, and KED tended to keep cursor motion and edit commands bound to key combinations that would be available on most (if not all) terminals. This minimized the use of "special function" keys, even if they were there, because they weren't there for all terminals. So the working set of keys was smaller even though the keyboards themselves were of nominally average size.

My observation was around the use of the PC's special keys used in "generic" editors because the authors of those editors have chosen to assume that everyone it typing on a keyboard that matches, or emulates, the 101 or 108 key keyboard that the PC made standard.

Relative to: Atom, VS, Sublime Text, the mac Notes app, and modern hard drive sizes - it's pretty small.

No, it's not as small as Nano, but I have a hard time getting my hackles up over a single binary I can download in under a second.

The Notes app executable is 2.4MB uncompressed and Notes handles a whole bunch of stuff this thing doesn't. Sublime is 12.5MB.

Leave it to HN to complain about an 8Mb go binary.

Reply on news.ycombinator.com