Это не то... Не нужен "ещё-один-anyevent" нужен anyevent на xs. такой, чтоб всё, что написано на AnyEvent работало, а если ты пишешь на XS и используешь EV, то у тебя доп профит
в варианте AE::XS было 3 варианта модулей: - Pure AnyEvent. работает как с AnyEvent - AnyEvent::XS. При использовании без EV работает как с AnyEvent - AnyEvent::XS + EV — работает как будто написано чисто на EV + XS
я ж собственно пришёл к тому, что перестал писать на AE и стали писать только на EV:: Тупо потому, что EV/XS на порядок производительнее
разные подходы. На чистом XS - это локальная микро-оптимизация. XS-Framework (и UniEvent и т.п. ) - это "архитектруная" оптимизация, когда почти всё пишется на C++ и до всего можно дотянуться из перла. В итоге там бомбическая сторость (вроде даже быстрей чем nginx; не выложено пока на СPAN). Если пропустил, то идея тут описана https://metacpan.org/pod/XS::Manifesto
И так оценочно если, сколько там строк кода на не-Perl приходится на одну строку Perl? Ну, не считая конечно код самого интерпретатора. Так просто оценочно если?
Ну я по этому критерию и сужу о том, что Perl - это клей. Да, очень важный, примерно как дирижёр в оркестре. Но что бы сделал дирижёр без своего оркестра?
Если считать, что Perl - это рантайм, но как бы не для кода на Си это рантайм, то как раз вопрос про соотношение строк кода интерпретатора и Core-пакетов мне кажется лёгкой шизофренией.
Это неверное суждение. Может вы просто не встречали задач, где-бы вы использовали перл не только как клей, но и для решения каких-то бизнас задач, которые сложнее перекладывания страничек в STDOUT например?..