Yep. Erlang/BEAM PIDs, processes, supervision trees, supervisor strategies, supervisors are underrated. They should be built into the OS. Honestly, every "program" should be a function, return structured data, and callable from anywhere. Logs also should be structured rather than deserialized lines. Lines requires parsing. Parsing is a waste of electricity and time because it discards boundaries between values. The current paradigm is unwise because it's slow and inefficient unless you actually need lines. Rarely do you need just lines. Look at how nasty bash, grep, awk, sed, cut, head, tail, tr scripts will become.
Also, debugging and profiling, I still can't believe many programming environments / IDEs lack the features and debugging integration that ancient Borland Pascal and MSVC had.
I'd settle for software that could reasonably save and restore its own state. Half the time when I close the laptop lid I have no idea what will happen when I open it again. More often than not some application and its state just disappears into the computational ether.
One of Alan Kay's slogans is "The computer revolution hasn't happened yet" and he's mostly right. What we have are glorified calculators and media players instead of programmable devices that can augment intelligence and it's because the main runtimes/operating systems on these devices are not dynamic enough. Great deal of effort is required to extend and modify them to fit personal use cases. If you're not a programmer then you might as well just give up because the technical barrier is too high. So it's not surprising that most people have a negative view of personal computers and would rather let Apple and friends manage things for them even if that means giving up a great deal of control and privacy to a 3rd party which is mostly interested in making as much money as possible.
The larger implications of all this is that a great deal of potentially innovative use cases are not feasible because the required effort is too high. Every innovative application has to essentially re-invent its own dynamic runtime and shoehorn it into the existing non-dynamic setup.
macOS AND iOS flavor these fairly well with the defaults systems and prefs, but software developers have to understand how to save and restore state properly, and not fight it.
Also, I think complete process state (secured by a kernel decryption key) should be able to be saved and restored. Open I/O file descriptors would probably drop if they represent remote resources, but code should be made resilient enough to reconnect and retry in the event of errors.
Logging is a good example of how the opposite to what you say tends to be true. Have you ever wondered why Windows logs are so useless? It’s not windows-specific; when you look at journald you’ll see plenty of structured junk; the actually useful parts are plaintext.
“Every program as a function” would be a disaster for reliability and security. There’s a reason no mature operating system does that, apart from tiny embedded ones.
OP is right. Functional programming is more secure and reliable than imperative programming. There are no buffer overflows when code is formally specified and verified. It's next to impossible to do this for imperative code but very easy to do for functional code [0].
Also, debugging and profiling, I still can't believe many programming environments / IDEs lack the features and debugging integration that ancient Borland Pascal and MSVC had.