Because it intersects with most of what you're doing. Why is that process supervisor I'm using crashing? Oh, it's still using select(2) instead of a modern I/O multiplexing mechanism, and exceeding its FD_SETSIZE limit. What do all these calls mean in my tracing output?
All the infrastructure you're using goes through C/POSIX in one way or another. When things go haywire, you can only get by fixing it on the higher levels or just blindly restarting for so long.
Have used Fortran. It's pretty nice, actually. I mean, it does have unstructured programming, but its structured alternatives feel pretty natural. Fortran code, like C code, feels a bit fragile but unlike C, Fortran doesn't seem to be actively malevolent. I only know Ada by its (excellent) reputation.
EDIT: Only true if you use the implicit-none flag when compiling Fortran.
Performance is of course lower. But it's impossible to put a number on it. Certainly native calls (printf, scanf, fopen, fread) add a lot of overhead. Also whenever the C memory layout has to be used, performance suffers (e.g. complex pointer arithmetic).
But the approach is to get the correct translation first, and then - if needed - bottlenecks can be removed manually. This should lead to a better migration/upgrading experience.
Most universities still teach a mandatory OS course where students build their own shell in C. Just because we start people off in block-based languages and python doesn't mean that Computer Scientists don't get the full tour of languages.
Who said they don't? This project is about porting existing stuff, for interoperability, etc. Not as a way to "avoid learning C".
>Don't you want to be closer to the underlying OS?
No, why would I want to do that unless I have a specific need for that?