О, как тебя бомбануло, девочка.

А теперь, закрываем педивикию, идём с читательским билетом в местную библиотечку и берём книжку по сям.

Открываем самое начало и читаем: Язык Си считается языком системного программирования, хотя он удобен и для написания прикладных программ. Среди преимуществ языка Си следует отметить переносимость программ на компьютеры различной архитектуры и из одной операционной системы в другую, лаконичность записи алгоритмов, логическую стройность программ, а также возможность получить программный код, сравнимый по скорости выполнения с программами, написанными на языке ассемблера.

Теперь останавливаемся. Вдыхаем. Выдыхаем. Думаем над прочитанным.

Из него следует, что Си используется как «более лучшая» замена языка ассемблера. Который является языком системного программирования.

Потом закрываем книгу, сдаём ее и идём в курилку к компашке друганов-кулхацкеров. Они сейчас обсуждают премьеру фильма Хакеры по НТВ. И начинаем красоваться по поводу того, что ты смог за неделю на свх запрограммировать то, что за целый семестр не смогли сделать на спец курсе по базам данных на Access. А именно приложение Борей.

Твоя шутка будет оценена.

Хммм...

О, как тебя бомбануло, девочка.

Чёт Вы в показаниях путаетесь… То я Вам «мальчик», то я Вам «девочка»… В библиотеку вот посылаете… Вы бы определились бы штоль как-нибудь? =)))

Т.е., в ответ на приведённые Вам ссылки, Вы предлагаете мне пойти в библиотеку (ещё бы знать где тут ближайшая) и чего-то там прочитать?

Язык Си считается языком системного программирования, хотя он удобен и для написания прикладных программ.

Ну, то есть, очередной долб… эээ… Ваш «колека» («коллегой» я это назвать не могу) написал очередную лажу и Вы предлагаете мне использовать эту самую лажу как руководство к действию? Это после того, как я носом макнул Вас в дерь… прямые и явные исходники?

Чё, серьёзно? =))) Понимаете, в том-то и проблема «СНГовского программирования» что одни долб… типа «преподаватели» генерируют таких же долб… как и они сами, но на более хреновом уровне. С одной стороны да, их конечно, пожалеть можно. Но то, что они делают, то как уродуют своими «продуктами интеллектуальной жизнедеятельности» мозги неокрепшие, это требует уголовного преследования.

Самое страшное – вот такие советчики прогуляться в библиотеку и прочесть то, что на любом заборе в инетрнетах этих ваших написано, не учат технологиям. Они выспренне рассуждают, точнее, переносят какую-то херню из собственных небогатых запасов в головы более молодых коллег и в результате плодят таких же как и сами бесперспективных и бестолковых уродцев.

В результате вся схема выглядит так. Раздаётся вопль «все на laravel!!!11» и толпа понеслась на laravel. Спустя некоторое время опять вопль «все на nodejs!!!11» и толпа опять понеслась, но уже на node.js. Вот так и носятся. Вместо того, чтобы понять что в принципе, код лучше бы писать максимально экономичным, а это уже не нода и не ларавел и, тем более, не java (лично я не видел проектов на java, которые не тормозили бы жесточайшем образом и на ровном месте). А не обмазываться «серьёзнейшими фреймворками», которых раз в полгода по десять штук придумывают такие же точно бестолочи.

Отдельно я замечу что Вы успешно умудрились сгенерировать метановый пузырь в луже, просто внезапно уточнив, что и для ситсемного и для прикладного программирования С, как оказалось, вполне себе годен! Да Вы что?!? Открытие дня просто! =)))

По ссылкам, значит, претензий как я правильно понимаю, нет. Ну то, что не нравится Вам «расчёт» TIOBE, я и не сомневался. Кому же он понравится, если «небезопасный» С там в лидерах на первом месте. Тут я даже удивляться не буду, могу только пособолезновать всяким туповатым престарелым кисо. =)))

Ладно. Скажите честно – сами заткнётесь или Вам имеет смысл пожелать счастливого пути?

/* Сомневаюсь я правда, что у Вас хватит мозгов заткнуть свой «фонтан», но шанс я предоставить просто обязан из чисто гуманитарных соображений. */

Языку С совершенно похрен что на нём пишется – операционная система или модули ядра для неё, используется ли язык для доступа к СУБД (любая уважающая себя СУБД имеет библиотеки для С), бэкэнд для веба, сам веб- или иной сервер, да тот же GTK+/Gnome в основе своей написан на С, endpoint для RESTful API, да что угодно.

Языку может и пофиг. А вот программистам - нет. И менеджменту тоже не пофиг.

Наличие библиотек прикладного уровня для Си, которые уже давно существуют для тырпрайс языков создаются больше для рекламы самого языка, а не для решения этих самых задач.

Чтобы студенты сразу после си не бежали на джаву.

Ведь на свх можно сделать тоже самое, что и на корпоративной Java.Безо всякого маркетингового буллшита

Угу...

Не пофиг. Менеджменту.

И менеджменту тоже не пофиг.

Им вот точно не пофиг после того, как они вынуждены покупать парочку HP DL980 (да, тех самых, с парой терабайт RAM) и потом оценивать ТОС (total cost of ownership) и смотреть где же ещё денег подэкономить чтобы софт работал в пределах указанных в Т.З. таймингов и чтоб не покупать ещё парочку таких же агрегатов. Не, пару-тройку лямов заказчики найдут, конечно, но с некоторой такой неохотой. И это, подскажу сразу, не банк, где пофиг – пять секунд, десять секунд… Вроде, как бы работает. В банках деньги тоже пофиг, кстати. В принципе. Там и java пойдёт.

P.S.

Наличие библиотек прикладного уровня для Си, которые уже давно существуют для тырпрайс языков создаются больше для рекламы самого языка, а не для решения этих самых задач.

Вы сделали моё утро! 146%! =)))

Ну что, определился? Нам интересен твой вывод! Давай итоги!

Представил себе HP Proliant, под завязку набитый самописными nginx модулями на си..

Нет, пока на чём писал - на том и пишу…

Это фильм ужасов или фильм катастрофа?

Ага.

Представил себе HP Proliant, под завязку набитый самописными nginx модулями на си..

980-й или SL 4540, который суть хранилище это конечно крутовато, там надо надёжно хранить и быстро (очень быстро) обрабатывать данные. А вот с десяток-другой 160 вполне-вполне, чё бы нет?

Такое решение избавляет от грустной участи писать «две стороны» – и серверную и клиентскую. В качестве клиента простой браузер вполне годен.

Просто, мы должны понимать что если контора идёт на такие затраты на оборудование, то вовсе не для того, чтобы менеджмент данной конторы выслушивал ответы «Вы знаете, у нас тут чёта всё затормозило, всё повисло на фиг, но Вы не волнуйтесь, так бывает, само отвиснет, ща полчаса пройдёт, сервак просрётся и ему полегчает».

Безотносительно к запросу ТС на помощь. Не было бы возможностей – не предоставлялся бы API соответствующий, при чём самим nginx.

И да. Практически любая установка nginx точно так же более чем на половину забита такими «самописными модулями». Их же кто-то написал, верно? Их же не с Марса импортировали? Так что, всё в пределах правил. Я ещё больше насмешу – в принципе, эксперименты показывают что самописный модуль вполне некисло живёт даже на Raspberry Pi (начиная со 2-й пробовали). И в исходниках нет ни какой разницы ARM там или x86_64. Просто компилите под нужную архитектуру, да ставьте. С он С и есть, чё там… Балансировку только осилить придётся, но это уже вопрос к девляпсам.

Практически любая установка nginx точно так же более чем на половину забита такими «самописными модулями»

Да, но одно дело написать модуль для Nginx под конкретную задачу и совсем другое - писать бэкенд на C в виде модулей для Nginx. Это колоссальная разница.

Я с Вами абсолютно согласен.

Да, но одно дело написать модуль для Nginx под конкретную задачу и совсем другое - писать бэкенд на C в виде модулей для Nginx. Это колоссальная разница.

Даже спорить не буду. Просто, надо понимать что за бесплатно заказуху такого рода не пишут. И это один из возможных вариантов решения проблем заказчика. Но тут уже вопрос к чему (к какому варианту) Вы сами будете готовы.

Думаете, я не знаком с php? Или node.js? Знаком. Просто, я лично (поверьте, ни какого негатива ни к Вам, ни к кому ещё в треде я не испытываю) всегда думаю о том, где мои руки будут связаны конкретными технологиями. В некотрых выше головы не прыгнешь. С Сями проблема в другом – это уже самый нижний уровень абстракций и тут… падать ниже уже некуда.

Если хотите, я чисто для примера могу в принципе показать «фитюльки» на С с fastcgi под nginx. Это именно не модули nginx, а persistent web applications, чисто эксперимента ради. Насколько просто или сложно оцените уже сами.

И я ни в коем разе не отговариваю Вас и не принуждаю Вас к следованию именно этим путём.

Спасибо, но не стоит - не заморачивайтесь, я Вам верю, что это можно сделать. Возможно, подобное, кстати, можно найти на Github.

Вообще, думаю, сложность «фитюлек» заключается не столько в написании программ на C как таковых, а во всякой обвязке типа написания тестов с мокингом вызовов некоторых функций, работа с миграциями, использование квери-билдеров (ну или вообще ORM), генерация OpenAPI-документации - всё это в C едва ли найдётся, потому что «это уже самый нижний уровень абстракций». А если этого нет, то что там остаётся для веба? Если всё это нужно писать с нуля самому, то это слишком уж трудоёмко получается. Поэтому тут бы Go, мне кажется, больше подошёл.

Для прикладных задач под nginx, Сысоев лично для вас сделал nginx unit. И угадайте поддержки какого языка там нет? (раста, правда, тоже нет)

Хоар в 2008 попросил прощения за null-абельные указатели, изобретенные им в 1965. В 2009 выходит первый релиз go.. с null указателями. Будто насмешка какая-то. Как сие чудо стало популярным, диву даешься. Большинство никогда не перестанет потреблять дерьмо. Даже высокоэрудированное IT большинство

Ну предложи что-то другое для веба) Не скриптуху и при этом не монстров в лице джавы и шарпа. Альтернатив так-то и нет особо.

Будь я стартапером дизраптером, выбрал бы сейчас grpc-web в качесьве транспорта и tonic на сервере (у него как раз grpc-web скоро появится нативно). Сервисы и типы предметной области автогенерить из proto для тайпскрипта и раста. В таком случае никакого отдельного веба просто нет - GRPC и на клиенте и между сервисами. Все чистенько, типизированно. Никакого тебе rest или json

Для бд очевидный постгрес на Diesel-e

Т.е. ты предлагаешь по сути вместо Go юзать Раст? Ну такое себе - шило на мыло.

Есть генерики. Нет нуль поинтер экзепшн. Так что не совсем мыло :) Раст не главное. Я просто озабочен null pointer exception и не понимаю почему остальные нет. Можно на котлин или свифт, если под них есть кодоген grpc и orm-ка

Ви таг гаварите каг будта си с крестами это что то более лудшее

Эм… что?

Я просто озабочен null pointer exception и не понимаю почему остальные нет.

В Java проблема частично отпала с выходом Java 8 в марте 2014г, в которой появился класс Optional<T>.

Для бд очевидный постгрес на Diesel-e

У Java есть универсальный интерфейс взаимодействия с базами данных - JDBC. У каждой уважающей себя СУБД есть JDBC-драйвер. Любое приложение на Java, таким образом, может работать с выбранной СУБД без переделки кода (возможно будут какие-то изменения в языке запросов SQL - всё ещё есть диалекты). На Java написаны собственно сами СУБД, которые могут работать в оперативной памяти (важно для быстрой отладки), так и с хранилищем на диске.

В c++, да даже в питоне, добавили тип optional. Все проблемы решились в тот же миг, ага

Не хотите решать — пишите с null.

Компилятора джавы ответ. Ему тоже пофиг

Для бд очевидный постгрес на Diesel-e

Насколько Diesel зрелый как проект? Используют ли его крупные компании? Легко ли он осваивается в сравнении с другими ORM? Есть ли внятная и подробная документация? Какие подводные камни имеются?

Вполне зрелый. В расте единственный (впрочем, почти в каждом языке по одному орм на слуху). На сайте есть гайды и референс в стандартном для раста стиле. Из подводных булыжников, самый большой это отсутствие async

Используют ли его крупные компании?

Be first

Java изображает сложность. Там формализовано много того, на что можно было бы забить и писать попроще без каких-либо рисков и проблем. Но должно выглядеть дорого

Превосходнейше описал это вонючее дерьмо! 👍

Васян расправил плечи

Я просто озабочен null pointer exception и не понимаю почему остальные нет.

Надуманная проблема.

Разве Optional не бесполезен чуть менее чем полностью? Сериализация и все что около с ним не работает. Best practices - использование в качестве возвращаемого типа, и нигде больше

Optional используется в качестве обёрточного при работе со Stream API, когда не желательно загромождать код проверками на null объектов в кортежах. Код становится лаконичнее и более понимаемым.

.NET5 это извращение. Куча чисто виндовых фекалий. Microsoft в своём стиле, кинул затравку коей был .net 3, а потом раз 5.

Можешь начать изучать фреймворк JPA

Говно собачье. Если уж зашла речь про базы, то изучать надо LINQ – если оно есть на Net Core или как его там, в общем если оно есть под линуксом.

Я вообще не понял профита от настолько абстрактного уровня (как в JPA) работы с БД.

Дело не в профите. Гугли:

1. «anemic vs rich domain model» – попадёшь на статью Фаулера; её не читай! Он известный адепт rich, в чём сам открытым текстом признавался. А читай стародавние срачи на RSDN, особо обращая внимание на посты IT, Sinclair и другие с ненулевыми оценками. Причём там была традиционная забава: в каждом из этих срачей обязательно выносили Фаулера вперёд ногами. :)

2. «heavy vs lightweight ORMs» – в принципе, идёт паровозом к предыдущему: в теории эти вещи ортогональны, но на практике они строго коррелируют: heavy ORM используют c rich domain model, lightweight ORM – с anemic. Тяжёлые ORM – это как раз JPA; лёгкие – LINQ.

3. Ну и может про «JPA vs LINQ» чего полезного нагуглится. По крайней мере, насколько я могу судить, именно LINQ выпустил лёгкие ORM в массы; и жаверы с тех самых пор и страдают, что у них такого нет. Для scala есть несколько решений; из них SLICK от авторов самой скалы – говно.

// Корректности ради: LINQ – более универсальная вещь, применимая не только к базам.

Фух. думал, стошнит пока допишу: дюже много вдруг вспомнилось и из тех срачей, и из собственных экспериментов на тему «когда heavy ORM всё-таки полезны». Обсуждать подробности и тем более спорить желания не имею.

UPD: Впрочем, одну вещь таки-напишу: причина, по которой heavy ORM (hibernate, и основанный на нём стандарт JPA) столь сложны, что у многих вызывают законную ненависть, очень проста и С ГОРДОСТЬЮ описана в библии по хиберу: это «paradigm mismatch bridge». Т.е. мост между разными парадигмами представления данных: реляционной и сетью объектов. Для меня это вообще матерное словосочетание, потому как это целый класс идеальных в своей переусложнённости примеров «дырявой абстракции». К этому же классу, например, принадлежат ещё stateful web frameworks.

Отсюда я вывел простое правило: нужно работать как можно ближе к базовым используемым технологиям (relative database, stateless web), и не увлекаться нагромождением промежуточных слоёв, чья задача сводится лишь к тому, чтобы переливать из пустого в порожнее переформулировать базовые API в других терминах.

Для всего идеально подходит JavaScript

и жаверы с тех самых пор и страдают, что у них такого нет.

Всё уже есть в Java EE 7.

Отсюда я вывел простое правило: нужно работать как можно ближе к базовым используемым технологиям (relative database, stateless web), и не увлекаться нагромождением промежуточных слоёв

Это как в Delphi - технология DataSnap, а в Java - JDBC/DataSource. В первом случае есть все необходимые компоненты, которые достаточно связать между собой мышкой в правильном порядке и написать немного кода. Во втором случае нужно проделать огромную работу по увязыванию данных.

Я вообще не понял профита от настолько абстрактного уровня (как в JPA) работы с БД.

Понимай: https://ru.wikipedia.org/wiki/Java_Persistence_Query_Language

Ты что ты это какой оптионал, ни в коем случае, только исключения и налы. Проблема не отпала, по факту ввели дополнительный слой враппер штукатурки, но никто не побежал переписывать кодовые базы на использование сабжа.

Все логично, технология отражение нужд гетерогенного Энтерпрайза. На самом деле она удобна, но цену все знают.

Так в Doctrine пхпшном то же самое. Юзал долго и восхвалял. Но все это веселье с Entity-слоем разбивается о два аргумента:

• Запрос не обязательно возвращает все столбцы из таблицы - Entity будут полупустыми. Все столбцы возвращать не выгодно из-за того, что нет никакого смысла читать с диска лишние данные.

• Есть различные вычислимые поля, которых в Entity просто нет, потому что это не поля таблиц

Зато у джавистов есть Jooq - тоже штука хорошая, вроде как

Что такое стек Java EE/Jakarta EE? на словах.

JakartaEE норм тема. Microprofile конфетка.

ЗЫ Что в том ролике, а то смотреть 12 минут 44 секунды долго?)

Спринги бегут впереди паровоза с выпученными глазами и порчей воздуха. Паровоз же неспеша разводит пары и уверенно догоняет Спринг.

но регулярно слышу и читаю где попало о том, что это «не серьёзные инструменты»

«Несерьёзность» PHP/Go/Python и им подобным заключается в том, что писать сколько нибудь крупные проекты на них почти невозможно по ряду причин:

• Постоянные breaking changes в языке и базовых библиотеках, поломанный backward compatibility, итп. Сколько там лет мигрировали с Python 2 на 3? Если ты пилишь проект 20+ лет, то разгребать все эти проблемы слишком дорого, и, главное, просто бессмысленно. Ты должен тратить деньги на свой проект, а не на бардак в головах разрабов PHP/Go/Python.
• Из-за отсутствия функционала в стандартной библиотеке, возникает необходимость подключать десятки, иногда сотни сторонних библиотек, написанных васянами. Иногда васяны маскируются под красивыми сайтами и обещаниями об active, vibrant and diverse open source community с сотнями разработчиков со всего света, которые выступают на сотнях конференций расхваливая свои поделки как только возможно. Но весь этот фарс не устраняет основную проблему - васяны даже не слышали про такие понятия как обратная совместимость, стабильный API и безопасность. Более того, активных разработчиков в итоге наберётся от силы штуки 3, компетентным из них окажется 1, да и тот через 5 лет потеряет интерес к проекту. А всё остальное коммьюнити будет продолжать выступать на конференциях и присылать патчи с исправлением опечаток. А это значит что ты будешь разгребать всю эту помойку за свои деньги.
• Отсутствие человеческого static typing. Когда твой софт содержит десятки/сотни миллионов строк кода, и тебе нужно внести значительные изменения в логику - удачи тебе с dynamic typing, она тебе понадобится. Но можешь попытаться покрыть код юнит-тестами, как советуют смузихлёбы, лол.
• Как языки они в лучшем случае ничем не выделяются. В худшем случае ты получаешь PHP. Если «повезёт», то Python. Если не очень, то какой нибудь Go без дженериков, который целенаправленно проектировался Гуглом как язык для альтернативно одарённых.

Java/.NET не решают этих проблем полностью, но они значительно их сокращают. У Java больше доступных библиотек и построенной вокруг неё инфраструктуры, но её текущий владелец не вызывает особого доверия, плюс в ней накопилось больше legacy проблем из-за возраста, по сравнению с .NET/C#. Для .NET, соответственно, наоборот.

насколько удобно вообще разрабатывать на нём под Linux

Можно, но на данный момент хороших инструментов под Windows больше.

Если ты пилишь проект 20+ лет, то разгребать все эти проблемы слишком дорого, и, главное, просто бессмысленно.

В большинстве случаев проект за 20 лет существования так и так будет переписан, считай, с нуля раз 3-5 (если его не просто забросили, конечно). Вне зависимости от языка, на котором он написан.

что писать сколько нибудь крупные проекты на них почти невозможно

Так и не надо, ведь от монолитов сейчас уходят. Если не к микросервисам, то хотя бы к сервисам - то есть делят приложение на более мелкие приложения.

Когда твой софт содержит десятки/сотни миллионов строк кода

То пора задуматься, точно ли то ты делаешь вообще, и не пора ли часть логики вынести в отдельный сервис. Иначе укрощать этого монстра будет невозможно. Или это количество строк кода в проекте с учётом зависимостей? Если так, то это не проблема.

Отсутствие человеческого static typing… Но можешь попытаться покрыть код юнит-тестами, как советуют смузихлёбы, лол.

Как будто юниты не пишут в языках со static typing, ага. Юниты - это вообще не про типизацию, если что.

Можно, но на данный момент хороших инструментов под Windows больше.

Это плохо) Потому что по сути остаётся только джава.

Прошу прощения...

Я думал что где-то с месяц буду вплотную занят, а оно вон как обернулось-то… Думал, смогу раньше в публичное пространство вернуться, а не вышло.

Спасибо, но не стоит - не заморачивайтесь, я Вам верю, что это можно сделать. Возможно, подобное, кстати, можно найти на Github.

Я морочиться и не собирался. =) И да, на гитхабе можно найти такое. Ну, почти такое и почти на гитхабе.

Оговорюсь сразу – у меня есть аналогичный проект, тоже «форумок» для своих задач. Нет, не публичный и доступ туда ограничен весьма узким кругом лиц. Но сейчас речь не обо мне.

Вот проект – https://board.asm32.info/ Когда поймёте на чём он писан, то сделайте милость – поднимите свою челюсть с пола. =))) Да, на ассемблере. Вот некоторая «статистика» от автора – https://habr.com/ru/post/319028/ В частности на реализацию кеширования постингов HTML у автора ушло 78 минут.

Насчет п.4 надо сказать, что я решил сделать эту функцию, измеряя время реализации, как доказательство того что код на ассемблере намного легче поддерживать, чем это принято считать.

Время реализации – ровно 78 минут. Наверное это несколько больше чем на ЯВУ, но все же вполне нормальный результат.

Т.е., задачи, пусть и весьма относительно сложные, но решаются и на достаточно «низкоуровневых» языках. Собственно, от языка это всё не зависит. От языка зависит сколько ресурсов надо будет выделить потом на запуск и организацию работы всего этого хлама.

Просто сей раб Божий понимает что такое «технологии» и как их стоит использовать.

В остальном мой проект почти похож на его. За исключением того, что:

• Да, я точно так же использую fastcgi. Я не хочу возиться с парсингом http(s), эту работу за меня отлично выполняет сам по себе nginx, у которого, кстати, ещё море задач. Мой «форумок» это одна из задач. Всего-навсего.

• Нет, я не использую SQLite, я использую Berkeley DB, aka Oracle Embedded. SQL язык хороший, но тратить время машины на его парсинг я смысла не вижу, No SQL здесь в виде встраиваемой СУБД вполне хорош. Надеюсь, ни кто не думает что сама по себе идея No SQL появилась сравнительно недавно и до того ни как не существовала? Существовали технологические решения и раньше. Знают о них? Хорошо. Не знают? Да и хрен бы с ним.

• Нет, я не использую assembler в своём случае. Ни nasm, ни gas, ни тем более fasm. Мой проект вполне неплохо себя чувствует что на х86_64, что на Raspberry Pi 2/3 и сейчас 4. На последней он вообще «летает». 8Gb RAM как ни как.

Вообще, думаю, сложность «фитюлек» заключается не столько в написании программ на C как таковых, а во всякой обвязке типа написания тестов с мокингом вызовов некоторых функций, работа с миграциями, использование квери-билдеров (ну или вообще ORM), генерация OpenAPI-документации - всё это в C едва ли найдётся, потому что «это уже самый нижний уровень абстракций». А если этого нет, то что там остаётся для веба? Если всё это нужно писать с нуля самому, то это слишком уж трудоёмко получается. Поэтому тут бы Go, мне кажется, больше подошёл.

А зачем всё искать в С? В пределах одного языка? Правда, сама по себе идея TDD (test-driven development) пришла из С и embedded programming, но кто бы об этом вспоминал? Тестовые фреймворки есть и ими активно пользуются. Опять же – те, кто о них знает. Миграции это вообще не свойство языка. По крайней мере, не должно таковым быть. Что делать если мне нужно смигрировать на удалённый хост, а там нет нужного языка и всей его инфраструктуры и ставить его туда ни кто и не собирался? Генерация OpenAPI документации это так же не свойство языка. Если уж Вы сообразите как RESTful API реализовать на С, то как сгенерировать документацию на него будет Вашей наименьшей проблемой. Поверьте. =)

В общем, что по теме сказать хотел, я сказал, а дальше уже дело Ваше. =)

Пффф...

Для прикладных задач под nginx, Сысоев лично для вас сделал nginx unit. И угадайте поддержки какого языка там нет? (раста, правда, тоже нет)

У меня есть С. У меня есть два варианта (если мы об nginx, поддержки «чистых» CGI без костылей там нет, а так бы было три варианта).

Для nginx это fastcgi на С и модули. Так же на С. Для меня лично Сысоев лично для меня, да, выпустил описание модулей nginx, точнее API для них. Зачем мне в таком случае какие-то костыли для убогих?

Если Вы обратили внимание (я гентарь, да, я обратил), то сам по себе nginx реализует довольно аскетичное «ядро». А вот дальше функциональное наполнение реализуется именно за счёт модулей. Не понравился один модуль – замените его на другой или допишите свой, для реализации своих задач. Тогда на всех серверах (аппаратных), где нужен этот модуль он может быть собран и загружен в составе самого по себе nginx. «Горизонтальная масштабируемость», да это она. И решение, как правило, не жрёт ресурсы как свинья помои.

Зачем мне весь этот секс для инвалидов в виде каких-то «nginx unit»? Nginx и так на С, чего мне-то ещё придумывать? Прочесть документацию и потренироваться в сторонке, перед написанием кода для прода, это теперь так сложно?