Earlier quoted context omitted.
Some things are just more convenient/efficient to do in C. As an example the mark handling[1] used to represent cursors/selection relies on pointer arithmetic. Other things like the syntax highlighting are implemented in Lua which is high level but still has low resource usage. And yes part of the choice is also philosophical. I consider an editor a core system tool which should have minimal dependencies. [1] https:/…
A mark could just be an offset inside the Text buffer instead of a direct pointer. Yes, dereferencing a mark would be slower, but do you really think that matters? I mean even if you did that 1M times/sec there wouldn't be a noticeable difference to the user. On the other hand, look at array.c. Or buffer.c. Or map.c. Or all the manual linked list management stuff. Or all the other logic that would be so much simpler…
Anyway this was just an example. I agree that higher level languages (including functional ones) have their own merit. If I would start again today I might consider Rust. But again the LLVM dependency seems kind of scary.
Again for me an ideal base system is built upon a kernel, libc (musl), C compiler (cparser/libfirm), coreutils (sbase/ubase, toybox, busybox), editor (vis) etc. Writing a C compiler is non-trivial, but doable. Creating a C++ compiler on the other hand ...
A self contained (including terminfo entries etc), statically linked vis binary weights in at around ~800K. This allows usage in resource constrained sytems, I don't think the same would be possible using e.g. Haskell.