Nim was a false start. I needed to run the code in a separate process group than the signal-wrapper so when the process group gets the signal. You can do this “by hand” if you go through the fork/exec process by hand, and call setpgid.
The bigger problem was signal handler safety. Signal handler safety is not well defined in Nim, and there is an open Github issue for it. It seems like the runtime wants to own signal processing.
In general, it looks like a neat language, and I really hope it goes somewhere. There was also awkwardness around the way that sum types are specified. My favourite part of the language is that it could compile to multiple backends, and you could explore the intermediate state."
https://medium.com/@sargun/systems-languages-an-experience-report-d008b2b12628
For what it's worth, but I wrote a response to the dude asking for more information on his decision, and some opinions of my own.
He never responded. :-/
https://medium.com/@rayman22201/nim-fan-here-interesting-assessment-a-good-read-thanks-421600fb34c4
Nim is so beautifully expressive and powerful, so it pains me to see people turn it down only because they can't find the information revealing its possibilities.
I'd be happy to help with documentation. My main worry is that since I am not a core contributor, I might misunderstand something and confuse people. I probably should start by writing stdlib examples, because I understand many of the undocumented parts :)
@twetzel59 Do it! The Nim core devs are very snarky, but also very welcoming.
They accepted a small random PR from me for documentation changes and I am literally a random lurker who hangs around the community and only occasionally posts things. lol.
I wish I could contribute more, but my job and personal life have prevented me from having the time. I have to make due with throwing money at the core devs instead.
Has there been any effort in the Signal handler / safety?