Why is C an advantage?

(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.

>>> C is itself a massive dependency

the C standard library?

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.

lots and lots of edge cases, I minimal compiler can be kbs

C compiler backend support is pretty broad.

Probably the biggest understatement I've ever seen on HN.

Supported on virtually every OS and embedded platform in existence.

Abstractly, very much yes.

In the context of nano and editors, you also have to contend with POSIX, tty I/O, etc.

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.

Statically linked C programs are the easiest to ship. Copy and run. No runtime required.

A feature of any AOT compiled language since compilers exist, nothing C specific.

Java and .NET would like a word with you.

When correcting someone on Internet be sure to know what you are talking about.

ExcelsiorJET, JamaicaVM, Aonix PERC, IBM Websphere Real Time, Xamarin on iOS, .NET Native, Bartok.

yes, good idea, let's make a modern console-based text editor that comes with IBM Websphere Real Time

You can embed their runtimes. I'm not saying that's desireable, just that it's possible.

Same with go

>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.

The advantage for whom? Surely not the user.

Having been stuck on a system where the only editor was Ed, I'd say nano availability can be a big win for the user.

When I was a lad, I had to port ed in order to have a console-based editor.

(True story - A5000 with RISCOS back in about 1993)

Can we start a !Zap vs !StrongEd argument here? :)

(Zap wins, of course!)

The advantage for anyone trying to find out-of-bound exploits in text buffer handling.

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 considers syscall API stable and there's a pretty hard rule of not breaking user space.

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.

FreeBSD also doesn’t break the ABI on major versions.

That's good to know, but it still means potential breakage every 2 years on average.

Historical accident, it is all a matter how libc of a specific compiler was implemented.

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.

As easy as childsplay as long as your target is supported. I cannot run Go code on my router which runs OpenWRT... Nano works there just fine.

Go was likely never intended to run on space constrained platforms like Broadcom MIPS, but point taken.

What?

Unless you'd want to contribute, why would you care what language it's written in? Why Go and not C++, Rust, D... ?

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.