> Because MB don't matter

I beg your pardon, but since Linux is increasingly used nowadays in quite resource constrained embedded devices, MB definitely does matter. (No, I don't claim that the individual 10 MB is very much on most devices that are actually capable of running linux. But once you go down that road and start having something else bloated than just the text editor, you are a few hundred MBs poorer in no time, and that is a lot.)

>I beg your pardon, but since Linux is increasingly used nowadays in quite resource constrained embedded devices, MB definitely does matter.

How are those relevant in our context?

Most of those "constrained embedded devices" (from smartphones to IoT and set top boxes) don't run terminals and editors anyway. And those that do belong to a niche, and those people can install whatever they want, be it nano, micro or whatever fits.

If you're concerned about the programmers of those "constrained embedded devices", that might want to ssh and edit something on them, then those programmers don't use nano anyway, so this doesn't concern them either.

I don't entirely agree with coldtea either but in defence of this project it is very easy to shrink the ELF binaries that Go spits out as there's a lot of debugging hooks in there that arguably you don't need on production boxes:

https://blog.filippo.io/shrink-your-go-binaries-with-this-on...

Sure, my meaning wasn't to talk down the project itself, it looks neat! The "MB does not matter" just jumped at me (somewhat out of context, I have to admit) since I work in the embedded land, and the pain is sometimes too real there.

Obviously the MB don't matter in this case and for the target audience of the editor, not in general and in every context.

embedded boxes run something like busybox to get just the coreutils rather than including all the packages that ship with, e.g., debian.

https://busybox.net/about.html