Zephir

AmdY
ну всё-таки если смотреть на список cDLEON'а, то просто давать ссылки на поиск packagist'а несколько не корректно, найдётся то куча всего, но в 99.9% это будут пакеты и близко не стоящие с приведёнными решениями на питоне.
про доктрину и композер писать не буду, как по мне, хорошие решения

что касается:
есть http://php.net/pthreads, новый экстеншн, да, зато без gil

имхо, тут питон конечно впереди, phpDaemon, http://reactphp.org/ (и на его базе http://socketo.me) кажутся менее production ready решениями при высоких нагрузках (ещё раз говорю что имхо)

(Деплой) Null < -- > fabric
не знаю что такое fabric, знаю что такое capistrano для рельс.
вот у php с этим реально непонятно, вроде и находятся какие-то решения для деплоя из коробки (grunt, deployer и прочие обвязки над ssh/rsync, где нужно самому писать базовые таски не всчёт):
https://github.com/andres-montanez/Magallanes
http://ripeworks.com/pomander/getting-started.html
https://github.com/CodeMeme/Phingistrano (очень старое)
https://github.com/Anahkiasen/rocketeer (Laravel framework only ?)

но нет какого-то более-менее известного и который у всех на слуху, если что посоветуйте.

p.s. кому-то слеш в неймспесах у php не нравится, а мне в питоне от __{method}__ в глазах рябит, но реально это мелочи и ко всему быстро привыкаешь.
 
AmdY
Сам то свои ссылки смотрел ? :))))
Я сейчас не письками меряюсь, а пытаюсь доказать, что в других языках ТОЖЕ есть необходимые инструменты. Которые не хуже (а по моему скромному мнению - лучше) позволяют решать повседневные задачи для ВЕБа.
И вправду - стоит заканчивать спор глухого с немым :)
Не уверен что портянка из import в каждом файле лучше глобальной области видимости в php
А зачем нужна эта ваша глобальная область видимости в нэймспейсах ? :) И да - я люблю питонячьи импорты :) Их можно настраивать. Пакет может отдавать только нужные классы (при этом есть возможность дотянуться до всего остального). В ПХП же - придётся смотреть всю реализации в автокомплите.
там предоставлены алгоритмы, если увидешь где забыли турбо поставить, можно поправить.
И, всё таки, перечитай комментарии по той ссылке :)) Я не собираюсь ни чего оптимизировать. Ибо не хочу мерить то, что не возможно померить.
p.s. кому-то слеш в неймспесах у php не нравится, а мне в питоне от __{method}__ в глазах рябит, но реально это мелочи и ко всему быстро привыкаешь.
Ну в ПХП ж, ведь, тоже есть __{method}, но в Python этого больше, согласен :)
 
пытаюсь доказать, что в других языках ТОЖЕ есть необходимые инструменты

Так с этим никто и не спорит, как раз наоборот, обычно php догоняющий.
Но вот взять php,ruby,python - на всех из них есть необходимая web-инфраструктура, что-то лучше, что-то хуже, но есть.
И что должно заставить перейти человека с 3+ годами опыта, который хорошо знает свой язык, фреймворк, имеет наработки, ориентируется в экосистеме языка на другой, почти такой-же.
Как по мне, так киллер-фич не один из них не имеет друг по сравнению с другом.
Я понимаю если php надоел или для развития кругозора делать проекты и там и сям, или хотя бы в зарплате будет профит +50% или скорость работы возрастёт в 2-3 раза.
Так вроде нет этого, шило на мыло.
Понимаю там переключиться на Java, .Net, Erlang, Go и т.д., тут другое дело, совсем другие задачи и подходы.

Если стоит выбор первого своего языка, я пожалуй соглашусь, что php не лучший вариант.
 
Gas
И таки если вернуться к начальной теме - с зефиром возможно подрастет скорость работы php-приложений, потому что возможно появится большее кол-во написанных на си расширений. Посмотрите на скорость работы пхалконовских приложений, ведь это замечательно писать на скриптовом языке, используя фреймворк на си)
 
hell0w0rd
сколько пекловских расширений ты СЕЙЧАС используешь в своём проекте? и предугадывая ответ, следующий вопрос - почему не используешь?
 
AmdY
redis, phalcon, раньше apc... Но дело же не в том. Сейчас в основном большинство расширений - обертки вокруг кешеров/баз данных и тд.
Вещей которые обычно пишутся на php, типо роутера, orm, шаблонизатора - нет, кроме исключения(ий) типа phalcon, а вот когда они начнут появляться - возможно все изменится.
Посмотри на тот же npm. Ты пишешь npm i *** и не задумываешься, что там возможно на c++ написан модуль, просто ставишь и пользуешься. Вот эта легкость и есть то, чего не хватает сейчас) Например возможно такое реализует команда composer.
 
AmdY
некоторые Extension на столько вжились, что уже и не знаешь pecl это или php
apc, memcache, imagick, sphinx, gearman, pdflib, DateTime, id3
 
hell0w0rd
WMix
в этом всё дело, из пёкла мы пользуемся в основном обёртками над стораджем, там важна скорость и никакого зефира не будет.
второй вид расширений типа того же PDO, DateTime начинаем использовать только после включения в ядро, когда есть уверенность в его поддержке. С тем же imagick под виндой приходится плясать с бубном.

hell0w0rd
поделись опытом писания на phalcon, мои знакомые месяц не продержались и переписали проект на zf, бросили из-за багов фалькона, среди них один сишник был и то, не помогло. Меня пугает что у них куча багов в issue, а они взялись писать зефир и вторую версию на этом же сыром зефире.
 
с зефиром возможно подрастет скорость работы php-приложений
я ж только за, с интересом поглядываю на HHVM, посмотрим смогут ли допилять чтоб поддерживал все фичи и основные экстеншены.
 
AmdY
Я так понимаю что ради поддержки phalcon они и взялись писать зефир. Допустим ты видишь баг в симфони, если он тебе критичен - ты берешь и фиксишь, шлешь pr и все ок.
зефир по синтаксису очень похож на php, в отличии от си, где надо знать не только сам си, но и понимать как устроено zend engine.
https://github.com/phalcon/cphalcon/issues?labels=&page=1&state=open - вроде всего 2 ишуе помечаны багами, остальные NFR
 
Я сейчас не письками меряюсь, а пытаюсь доказать, что в других языках ТОЖЕ есть необходимые инструменты. Которые не хуже (а по моему скромному мнению - лучше) позволяют решать повседневные задачи для ВЕБа.
уж доказал так доказал
 
Gas
Как по мне, так киллер-фич не один из них не имеет друг по сравнению с другом.
Я понимаю если php надоел или для развития кругозора делать проекты и там и сям, или хотя бы в зарплате будет профит +50% или скорость работы возрастёт в 2-3 раза.
Ну как сказать. Изначально мне нужны были только вебсокеты. Т.е. те же реалтаймовые подключения для меня стали главной фичей :)
уж доказал так доказал
Старался :)
 
hell0w0rd
сколько пекловских расширений ты СЕЙЧАС используешь в своём проекте? и предугадывая ответ, следующий вопрос - почему не используешь?

Причины две:
1) не нужны, либо не знаю о нужных.
2) Стабильность. Обычно она хуже, а последствия сбоя плачевные.

Судя по багам, которые я поймал в симфони, проект такого уровня (я намекаю на фалкон) не может быть без ошибок.
 
cDLEON
phpDaemon < -- > Tornado, Twisted, etc
Если говорить об fsm event-based servers - возьми один из специально для concurrent programming предназначенных языков (go, rust, erlang) и забудь о перечисленных nodejs-подобных костыликах как о страшном сне.
Касаемо инструментария, "сила ночи - сила дня...": глубокое знание конкретным разработчиком конкретного тулчейна значительно перевешивает мелкие различия.

По сабжу. Написание классического веб-фреймворка в виде php extension, напрямую или через промежуточные компиляторы - совершенно непрактичная задача, и phalcon тот же явно разрабатывается Because We Can и For Lulz. Но узкое применение, несомненно, есть. В extension-ы разумно выносить два класса задач: врапперы сишных библиотек (что очевидно) и cpu bound задачи. Вот для второго он вполне уместен - скажем, какой-нибудь php_templates/blitz templates на этом самом zephir-е было бы весьма удобно писать.
 
Последнее редактирование:
Если говорить об fsm event-based servers - возьми один из специально для concurrent programming предназначенных языков (go, rust, erlang) и забудь о перечисленных nodejs-подобных костыликах как о страшном сне.
Ну, может быть, nodejs и костылик. Но тот же tornado я бы им не назвал(а уж тем более node-подобным). Т.к. там нет такого хаоса с калбеками, как в nodejs. Взял бы, да сам попробовал. Прежде чем костыликами кидаться.
 
cDLEON
да те же костыли, просто замаскированные через yield. Насчет пробовать - а ты go попробуй ;)
 
hell0w0rd ты на node.js писал? Не заметил, что приходится писать говнокод с обилием колбеков?
 
fixxxer
Ну ок. Не устраивают генераторы - Welcome to greenlets Хотя мне генераторы больше нравятся. Для веб-сервера они больше подходят. А для всего синхронного и тяжелого у меня есть небольшой модуль, основанный на мультипроцессинге. Получается и асинхронно и довольно гибко. Для каждой задачи я могу выделить нужное количество воркеров.
 
hell0w0rd ты на node.js писал? Не заметил, что приходится писать говнокод с обилием колбеков?
Ну не могу сказать, что серьезно прям писал, баловался скорее.
А в чем гавнокод-то? В экспрессе есть прекрасная штука - middleware. Берешь за правило - один middleware - одна задача, если он ее не решает, отправляешь дальше. Не надо все описывать в одном колбеке вот и все
 
Сверху