Из последнего, такая "троица":
* агент — демон на "голом" C (вообще-то "на голом" разве что ядра, реально в роли "фреймворков" glibc, libpthread, zlib и т.д.) — ≈2c CPU за сутки, 1.5 недели на написание/отладку. От 200к до 2М RSS (x86), в зависимости от багов glibc (внезапно, там кое-что может вообще никогда не вычищаться и это мало кого парит т.к. "не течёт же дальше"). Бинарник 28к (т.к. динамическая линковка). На самом деле, 28к для такой финтифлюшки — тоже безобразно много, но тут и 64бит и более-менее свежий GCC 7.4.1 — против компактности.* Сервер-коллектор на golang (раньше вполне мог оказаться на python, но теперь всё убивает вопрос "какой версии"). ≈20с CPU за сутки (из них половина — GC), пара дней на написание/отладку. 4…8МБ RSS (т.к. GC). Бинарник 3МБ (всё статикой, "-ldflags "-s -w" --tags static_all").
На С такое даже пытаться бы не стал, т.к. не имею бесконечного времени. А так — почти честный демон (один форк со сбросом привилегий, но без второго с отвязкой от всяких консолей/fd).
* "Экспертная система" — псевдо-демон на баше. День на расписывание выходов "автомата", ещё день на зачистку багов (примерно в каждой строке). Главный баг (писать на баше) при этом сохраняется на неопределённое время. Вызываемые в процессе find/grep/etc. едят в среднем 3МБ RSS, но CPU за сутки набегает до 300с (и в дальнейшем ещё добавится некий logN от числа обрабатываемых отчётов).
Аналогичная функциональность сразу на каком-нибудь go заняла бы около недели времени т.к. изначально не было готовой концепции "как правильно". Или вот так как я сделал (из г&п) и затем переписать (опять таки +время, но можно разбить на более короткие/предсказуемые фазы и вообще переписку отдать пофессиональному кодеру).
Это я всё к тому, что не "игрушечный вариант С", а каждому свои задачи. Go свою нишу нашёл, а вот от "взятия на вооружение" rust пока отпугивает текущий состав комьюнити. (Во как я политкорректно выдал). И вообще есть риск что rust повторит судьбу haskel "прикольно но".
