Нет. Сейчас ознакомился, я как понимаю проект более не развивается... Ахтунг! Лицензия GNU GPLv3 !!! Это означает, что использовать такое мы у себя уже не сможем, да и у многих клиентов.
sitev_ru: В конфиг файле роутинга можно будет указать ассоциацию между запрошенным путем и парой "контроллер"-"действие". Запрошенный путь можно будет регуляркой разобрать. Такое уже есть в одном фреймворке https://github.com/ChicagoBoss/ChicagoBoss/blob/ma... .
Что мы хотим еще добавить по сравнению с ChicagoBoss: перенести разбор методов (GET, POST, DELETE и т.д.) в конфиг, добавить поддержку модулей (у нас они есть), добавить возможность делать редирект прям в конфиге.
Одни из популярных решений сейчас это сайты на PHP, Ruby (RoR), Node.js, Python (Django), Java.
С первым завсегдатаем сравнивать нечего, совсем разные цели. Тут выигрыш сразу за нашем решением, т.к. в runtime PHP не умеет работать (не нужно мне показывать костыли типа phpDaemon )
Любимый руби... Хороший язык, легко подойдет для создания прототипов и не очень сильно нагруженных проектов. Из минусов у него: низкое быстродействие, кушает много памяти.
Node.js давно не следил за ним. Да все круто, NPM там, плюшки всякие, но выходить на высокие нагрузки с костылями, чтобы работало в несколько потоков (все ядра задействовать) - не серьезно. Ну и мне лично страшно писать на нем код, где неявное приведение типов с динамическими типами вытворяют фокусы из-за твоей не внимательности.
Python. К сожалению против сказать ничего не могу, не пользовался. Но вот оценить шаблоны в Django смог - мне понравились, правда не на всю мощь. Писали небольшой сервис на Erlang (ChicagoBoss) в свое время.
Java ну вот это достойный конкурент. Много Enterprise-решений сделано на нем. Холивары до сих пор идут кто круче. Но вот явный минус для высоконагруженных систем у Java это память.
Резюмируя, хочу сказать, что в сравнениях по памяти и вычислениям тут явно Си++ является одним из лучших в своем роде. Основным минусом у него конечно остается: высокий порог вхождения, скорость разработки небольшая, мало удобств ("синтаксический сахар")
Boost за борт (смысла нет тащить такую либу из-за пары заголовков) :) FastCGI пока останется, свой веб-сервер писать для автономности пока смысла нет - потеря времени. Давно "любимый язык" остается на компьютере в офисе, лишний раз с ним сталкиваться нет желания.
1. Данные предварительно можно подгружать в память при возникающей необходимости. После чистить. В этом и есть плюс runtime над интерпретацией. А семейство Си более выгодно смотрится над остальными языками по возможностям манипулирования с памятью.
2. Согласен, такое и мы делали, что уж скрывать... Честно? Поддерживать проект на нескольких языках сложнее.
3. Порог вхождения естественно у нас намного выше... Снижать? Смысла нет, многие дешевые программисты понятия не имеют о алгоритмах, анализах вычислительной сложности - с такими нам не по пути :)
4. Пользовались, чем-то особенным не впечатлил.
1.) Да согласен, что уродлив чем-то и стар уже, но он вполне годно работает. Первоначальный выбор обусловлен инфраструктурой у нас на продакшене, а именно балансировщиком и набором важных переменных окружения от него. Думаю из общего мнения, фича в виде standalone платформы будет неплоха и будет развиваться. Библиотека стандартная: www.fastcgi.com
2.) Вдохновил в свое время https://github.com/erlydtl/erlydtl - хотим также
3.) Да тоже передумали, после небольшого брейншторма, в пользу более настраиваемых правил роутинга
Ну у нас упор идет на модульность логики, объединяемые в конфигурации для распространения... (Привет 1C!)
