17 years on linux 20+ in *nix. systemd is ! init. There are other ways to introduce an init analog systems bus for functionality without replacing init. Wrongheaded and developed for the wrong reasons in the wrong way.
These have packaged the process and tools but no one can tell you how to do it for yourself. Because at up to an expert level it is still a set of tools you use.
A lot of the advice/terminology: 'fast smoke tests', 'google ops stack', 'host your status page elsewhere', choice of load balancers, etc.. is stupid-hoc.
Do yourself a favor if you are going to do devops practice.
1. Write it from scratch.
2. Make it work no matter what happens before and after calamity.
3. Write the docs.
4. Leave it to beaver.
This is sadly amusing. Are you making the world in your googly feely image? It's just despotism of another stripe in case you haven't figured it out yet.
This is common nonsense.
Those people who have stake in new language push
and disparage and those that have stake in the old
contrast. It's the old 'not broken' argument but your
emphasis are particularly egregious in association and
I don't believe you have done any real work other than
posting.
Rust and Go advocates will have you think that they have conquered security via the memory mgmt and API front but there is still the off chance they haven't..or that the SA (what is left of that maligned profession outside playbooks and the devops marketing you read here and online) has allowed you a chance for glory.
There are basically two rules to a well written C program (if I am now allowed to speak despite the public outcry).
1. Do not trust user input. This is a cardinal rule in whatever source. If the rule were followed vigorously in
every case there would be 90% less exposure. When you take user input, filter.
2. Learn the standard and stick to it.
Finally #3 (unix) Write an application to do a certain thing well.
If you have work to do in the thread do these in the
thread. If you must fork() then exec.
Signal safety in pthreads can be handled generally via the pthread_sigmask|queue family. The corresponding facility in processes is similarly known. Yes, the conditions you posit exist but they are the product of bad development imho.
You have provided badly designed examples and worst case scenarios while noting that you dislike the unix model for process inception. Great. Now go away. You know enough to be dangerous.
Better C++ than Go or Rust. Antecedents and track record counts. Young people like the new thing. Go and Rust are capitalizing on that. Learn C. Take the time..it takes a
couple years and some pain to learn it and then you will be amply rewarded. These languages (go|rust) are reactive and suffice for some purposes but they really kind of suck in every other possible way.
* Coercion: large down vote/propaganda community against any negative rust idea..evidenced here.
* IP Holders, well this is speculative. I can't understand anyone who would compare Rust against C in a positive way without possibly profiting from it. Rust is painful to write, painful to learn and makes you ask yourself: Can I not write a well designed and correct program in C? Of course I can. Why Am I Learning Rust? The answer seems to be peer pressure and propaganda.
* Write the same thing in C/Rust and read it in C/Rust and tell me who isn't making sense.
*...it's a total mess...theoretically it's possible....speculation on standard behavior based
on platform behavior...namespace(x)<-threads->chosen implementation detail...functional language reference...
-- Translation: Design is broken
No. You can call fork pretty cleanly in a pthread based program. This post is not informed criticism. There is some prep for ugly contingencies(pthread_atfork) but it usually just works.
Namespace based code while doing the same is like setting your hair on fire while running through the gasoline forest..but caveat emptor is usually spelled out pretty critically in the API and docs.
Oh, btw: Fuck RUST. For once and for all fuck this tyranny of coercion by potential IP holders. It is a shit language.