The advantage of Nano is that it is written in C, has zero required dependencies other than libc, and the compiled binary is 200 kilobytes. This makes it possible to include it in the base system, even on very tiny distros.
(I get "no dependencies", but that seems orthogonal to being written in C. Specifically, what does C bring that isn't minimal dependencies, or a small binary?)
It adds a massive new dependency to the build process for base system. C is itself a massive dependency, but it's already there for pretty much everyone.
This matters more for distros and OSes where building things from source - either everything, as in e.g. Gentoo, or at least the base system, as in the BSDs - is pretty common and expected.
No, the C compiler. Both gcc and Clang are pretty big, even before you account for the standard library. I suppose you could get away with something like tcc, though.
It isn't, except for the fact that most people who can code low level programs know it. But what you don't want into consideration is pretty much the important part of shipping a software you want to proliferate easily.
Micro also has zero drpendencies after it's compiled. And Go makes cross compiling easy as childsplay: just set two env vars, type go build and you're done.
I'd love a working replacement for Sublime Text written in Go rather than all of these Electron based editors. Lime Text is kind of alpha quality.
Fun fact: on Linux, mac OS and BSDs, it does that by invoking syscalls directly. Syscalls are not considered a stable API on those systems by their respective developers. This means that your precompiled zero-dependency binary will just stop working next time Apple changes or removes a syscall: https://github.com/golang/go/issues/16570.
Coincidentally, code written in C doesn't have that problem.
Linux does, yes. MacOS and BSDs do not. (Neither does Windows - but so far as I can see, Go doesn't try to invoke the NT APIs directly there.)
Stability is guaranteed on userspace API level - e.g. libc. So well-behaving apps are supposed to just use that, and let it handle syscalls. But Go doesn't.
I am not all that familiar with kernel/low level programming, but wouldn't the C API/library internally use syscalls as well? If a C program is written with a dependency on a syscall, and this syscall is changed. Does the code still work after, or does it need to be recompiled with an updated compiler?
The compiler doesn't really play a role in this. If a syscall changes, then you'll need to change the arguments in the C code that invokes it.
The system libraries like libc themselves use syscalls internally, yes. But on those platforms I'm talking about, they're maintained by the same people who maintain the kernel, and both components are versioned together. So they can go and change a syscall, and then also make the corresponding change to libc (without changing the latter's public ABI), and ship the updated versions together as the new OS release. Well-behaved apps dynamically link against libc, so the change is completely transparent to them.
On Linux, different people maintain the kernel and libc (and, in fact, there's no single officially blessed libc - this is one case where the old adage that "Linux is just a kernel" is in full force). Consequently, the interface between the two has to be treated as a public API, with stability guarantees.
The system's C library would use the syscalls directly and the application would use the C library routines. So if/when the OS updates the syscall ABI, it would also update the system's C library to use the new syscalls, and the application would continue to use the stable C library API and get the new syscalls under the covers automatically.
I would rather say, it's a matter of having libc and kernel developed as a single package ("base system") by the same people, and versioned together, versus having the kernel and the userland separate.
Because you want to run it on your favorite platform, which might not be x86 and thus need compiler support? I wrote my own editor for exactly this reason: to always be able to have it on any platform.
