Как стать автором
Обновить

Комментарии 46

А что на счёт PHP 7.1? Ваш KPHP насколько быстрее? И ещё, вы не используете .htaccess?

Зачем им ПХП 7.1, если они вообще не пишут ООП-код?

при чем тут ооп ?!?! теже массивы переработали полностью начиная с 7.0

Какие массивы ?!?! Они транслируют в С и компилируют. Они могут и на хаскеле писать так же.

Да, PHP реально прелесть! Заметно как серваку даже легче работать стало) Но самое главное — что переход оказался совершенно безболезненным. Дело в том, что давным давно мы переезжали с 5.3 на 5.4, при этом пришлось только поменять модификаторы /e на preg_replace_callback (). Или в какой там версии /e оказались депрекейтед? Уже даже не помню за давностью лет… Ну и банально split на preg_split () заменили. Все. Поэтому после этого переход на PHP 7 оказался настолько простым, что пришлось даже в phpinfo () версию проверять, настолько легко встал)
Зависит от специфики проекта, не везде всё так гладко
Соглашусь, но мне даже интересно какая может быть специфика еще помимо некоторого количества деперекейтед. Разве что с лямбдами и замыканиями могут быть сложности, но это все вообще-то изначально нужно писать правильно. Ибо вообще все изначально нужно писать правильно, это секрет, собссно)
На самом деле проблемы возникают в различных расширениях, которыми силен пхп.
Например, в 7й ветке имеет большие проблемы с стабильностью ext-gearman.

Хотя сам Gearman более чем стабилен.
P. S. Только сейчас обнаружил, что забыл поставить 7 в комменте. Речь шла о PHP 7, разумеется…
Многие до сих пор не простили им выпил mysql_*, который просто работал и есть не просил.
Ну я не спроста коснулся того, что секрет отсутствия проблем такого рода — писать правильно. Лично у меня для БД своя обвертка, поэтому переход с mysql_* на тот же mysqli_* — дело пары минут, для этого реально нужно было просто вручную поменять названия нужных методов, и все. То же самое нужно будет сделать и тогда, когда я захочу перейти с мускула на Постгре, например. А если лапшекод такой, что подключение к БД хардкодится путем mysql_connect () в каждом скрипте — то тут, знаете-ли с, все и правда грустно) Только по другой причине :/ Однако тут как в случае и со старым домом — его легче построить заново (опустим подробности с качеством материалов, их безопасности, хоть это тоже спорный вопрос, может ли слово «безопасность» быть применимо к старой гнили 100-летней давности). Если, конечно же, позволяют возможности. А у кого код из разряда «работает — не трогай», и который слетает даже из-за комментариев — они-то конееешно, до сих пор бурлят, как же) Я просто изначально свою CMS писал с нуля, не так много кто получил такое «благословение», однако я искренне сочувствую тем, кто получил в наследство индусский или даже китайский код, или вынужден клепать для себя какую-нибудь кустарную (да и не только) CMS.
Никто не говорит что надо коннект в каждом скрипте делать, это конечно жесть)
Но вот к примеру банальный вызов своей функции, которая лишь возвращает результат mysql_fetch_assoc, замедляет выполнение на 12%.
Может быть KPHP или HHVM умеют инлайнить такие функции, но вот сам php даёт оверхед.

Так что повторюсь, мне жаль, что php, как и многие другие современные open source продукты, не заботяться об обратной совместимости (которая в данном случае им бы вообще ничего не стоила).
О, конечно, я это утрировал (хотя, как говорится, «В каждой шутке...»), однако я встречал всякое, даже в известных CMS. Однако вы очень сильно сгущаете краски: я специально и начал с того, что лично для нас переезд с PHP 5.4 сразу на PHP 7 оказался настолько простым, что пришлось даже его версию проверять в phpinfo (), а Вы по сути придрались только к mysqli_* и уже приписали им ложные мотивы. Ни в чем Вас не осуждаю, просто констатирую факт. Да и если копать глубже — это ли ограничения? mysql_* морально устарели и были действительно небезопасны. Если компания, например, производит пластик, который может быть опасен для людей, то можно ли считать, что она не заботится об обратной совместимости, если она перешла на новые материалы, но субподрядчики оказались недовольны тем, что им из-за этого пришлось перестраивать свою линию производства, которая изначально была заточена под материалы 50-летней давности?
>>mysql_* морально устарели и были действительно небезопасны.
Опять двадцать пять. Это не модная одежда, которая морально устаревает. C код, написанный 30 лет назад, работает до сих пор.

Всё это настолько пустые отговорки, что диву даюсь. Могли бы хоть 10 новых mysql расширений разрабатывать, но старое проверенное и работающее оставить и не трогать.
mysqli_escape_string делает абсолютно то же самое что и mysql_real_escape_string, и этими функциями и там и там можно пользовать небезопасно. И там и там должна быть своя функция-обертка, которая для не-чисел обрамляет значение в одинарные кавычки (не двойные), и там и там нельзя использовать режим NO_BACKSLASH_ESCAPES. Не все желают пользоваться prepared statements, особенно из-за снижения производительности.

Вызов команды exec тоже может быть небезопасен. И даже echo, если им вывести xss уязвимость.
Извиняюсь, в конечном итоге просто забыло ответить… Соглашусь, расширение в любом случае имело право на жизнь, однако что бы там ни было, оно уже убрано и это свершившийся факт, поэтому рассуждать надо уже на основании нынешних реалий, уже без mysql_*. Извините, но я все-равно склоняюсь к мысли, что писать приложения нужно так, чтобы такие переходы были безболезненны, тогда и сетований не будет, ибо быть может что угодно, хоть пусть власти США вмешаются и скажут, что эти расширения соединяют с масонскими ложами, и поэтому должны быть удалены, поэтому всегда нужно оставлять возможности для безболезненного перехода, особенно когда обвертки с умом это позволяют более чем.

Приведу пример. Вот я недавно переписывал Sypex Dumper для поддержки PHP 7 (знаете, возможно, по сути стандарт де-факто для работы с дампами), ибо поддержки PHP 7 юзеры до сих пор не дождались. Ходят слухи, что разработчик погиб в украинской войне, а какая-то свинья до сих пор делает на юзерах деньги (ибо как еще можно объяснить, что c даты релиза PHP 7 прошло больше года, но разраб, создавший такое серьезное приложение, до сих пор не может выполнить замену mysql_ на mysqli_, имя на руках исходники (версия Pro имеет закрытый код для конечного юзера)? Дак вот его код надо видеть! Я уже говорил ранее, что можно и mysql_connect () захардкодить, было бы желание, мне так и сказали, типа ну это вообще жесть, я и говорю, типа это шутка, хотя и не без доли истины. Дак вот все запросы к БД выполняются там с помощью следующего кода:

mysql_query ("запрос") or die (mysql_error ());

Понятно, я выполнил поиск и замену, все работает, однако, думаю, нет нужды говорить о том, что такого рода лапшекод — это откровенный фейл, ибо одно дело, когда мы имеем один скрипт, который можно просмотреть даже в ручную, чтобы быть уверенным в том, что заменилось все верно и все аргументы в новых функциях стоят на своих местах, другое дело — когда имеется сложный проект, и один бог знает что там где захардкожено прямо в коде без всяких обверток. Можно создать переменную с публичной областью видимости, вызывая ее из экземпляра какого-либо класса, чтобы вставлять в тот же mysql_query (), однако это уже и есть зачатки обвертки, за которую я так ратую. Поэтому виноват-то тут не PHP, который якобы не заботится об обратной зависимости. Просто код надо писать уметь.

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

Говорю ни в коем случае не о Вас, а в общем.
Разрабатывать язык надо так, чтобы не думать о таких «безболезненных переходах». Совершенно неважно, надо лишь в одном месте изменить функцию или в тысячах мест, обновление никогда не должно ломать существующего кода, даже если он 10 лет работает без поддержки. Вносить новые возможности, ускорять выполнение, закрывать проблемы безопасности — вот что должны делать новые версии языка, который типа enterprise, но не ломать существующий код. Ну это как бы основа основ, которую непонять этим индусам, которые разрабатывают php (да и python видимо тоже).

Изменение даже одной строчки стоит денег, а также множество времени на изучение очередных несовместимостей при обновлении. Даже те же хостеры, рассадники уязвимостей и кривого кода, просто в очередной раз предложат пользователям выпадающией список с версией php, и весь код просто останется на старых версиях, без поддержки security fix. Что со временем приведёт к ещё более серьёзным проблемам с безопасностью.

Просто пример — я рад что массивы теперь можно объявлять как [] а не только через Array(); И ведь молодцы ведь, оставили старый способ для обратной совместимости! А то ведь тоже могли бы выпилить его к чертям по желанию левой пятки.
О, ну если с этой позиции рассматривать — то конечно. Я почему, собссно, и вспомнил, что забыл Вам ответить — как раз переписывал этот самый Сайпекс и понял, что если бы не удаление этих функций, то мне бы и вовсе не пришлось даже видеть этот лапшекод, а уж тем более тратить на него свое время.

Я очень люблю PHP (и не потому, что просто вынужден на нем писать, а потому-что изначально ознакомился с ним и после этого связал с ним всю свою последующую жизнь). В плане его динамической типизации я сравниваю его с автоматической коробкой передач, благодаря которой я могу наслаждаться самой поездкой, а не дергать рычаг переключения передач постоянно (особенно в пробках). Да, он позволяет из-за этого много, что другие языки просто не позволят, но это, как говорится, остается на совести программиста) Руки прямые иметь надо. Как и во всем, собссно.

Однако их политику такого рода я и сам не всегда понять не могу, честно признаюсь. Помимо mysql_* несколько странная ситуация возникла и вокруг mb_* для многобайтовых кодировок. Идеальным вариантом в этом случае была бы замена самих исходников этих функций для поддержки многобайтовых кодировок, ибо те же mb_* по сути могут работать и с однобайтовыми, и с многобайтовыми кодировками. И ничего бы при этом не развалилось бы вообще если при этом перевести все файлы проекта в другую кодировку, это совершенно безболезненно. Да и честно признаться, я уже лет 10 не видел файлов, сохраненных в какой-нибудь cp1251, а не utf-8. А так, лично у меня переезд на utf-8 был не из самых приятных, ибо тут нельзя просто было заменить substr на mb_substr (), ибо вторым аргументом в mb_* нужно всегда указывать нужную кодировку, поэтому я просто насоздавал своих функций на замену mb_*, в теле которых просто указал кодировку через константу. Однако эти функции требуются не везде. Не везде есть необходимость в дополнительной нагрузке (возможно), если данные передаются, например, на латинице.

P. S. Ничего себе Вас заминусовали :/
Всегда есть с чем-то несогласные, надо просто не обращать на них внимание. Это наверное те, кто готовы just for fun бесплатно перелопачивать старые проекты из-за прихоти разработчиков php.

Мне приходится поддерживать некоторые очень старые чужие проекты, которым по 10-15 лет, хорошо защищены от sql injection, проверены sqlmap, которые даже не хочется трогать, но которые должны работать. И конечно которые хотелось бы ускорить переходом на php7, но из-за нарушений обратной совместимости придётся потратить некоторое время, которое неоплачивается.
Да, есть wrapper типа https://github.com/e-sites/php-mysql-mysqli-wrapper/blob/master/mysql.php, при его использовании задумываешься, и зачем нужны были эти странные усилия команды php.
:DD Вот-вот, и не говорите) И начальство такое «Ну, будем переписывать крупный проект, который вообще-то работает, но его все-равно придется полностью переписать вручную, а что тут такого?».

P. S. Какая-то эта обвертка мутная, CamelCase вперемешку со snake_case, по-ходу автор еще в себе не разобрался… Надо бы уже определиться)
P. S. На mysqli_* они намного раньше перешли, реально давно, уже вроде как в 5.4 объявлялись устаревшими. Или Вы имеете ввиду PHP как таковой?
В январе 2016 я сравнивал текущие на тот момент kphp, php (7.0.2) и hhvm (3.11.1) на тесте циклов-массивов-математики со специальными усложениями кода, чтобы компилятор C++ не мог оптимизировать код, выдаваемый kphp транслятором (было бы не спортивно).

Там разница была в 2-15 раз в пользу kphp. Вывод типов и оптимизации C++ компилятора дают очень хорошее ускорение. Так что отказываться от него мы пока не собираемся)

У нас, по сути, сейчас нет apache, какой уж там .htaccess.
Речь была не про stat ли запросы на каждый запрос к серверу? :)
Вместо MySQL собственные движки, правильно понимаю?
На самом деле, это стало понятно еще тогда, когда они все эти движки заопенсорсили :)
В связи с глобализацией в сети, это информация мало кому пригодится. Монстры типа ФБ, ВК, Инстаграм захватили нишу основательно и надолго.
Кроме соцсетей существуют и совершенно другие высоконагруженные проекты. Возможно кто-то проектирует что-то / вынашивает идею, где было бы очень полезно заранее знать с чем примерно придется иметь дело, когда нагрузка будет очень большой. Статья интересная, но читать трудновато, конечно.
Судя по докладу в коде все очень-очень плохо… но работает на ура :)
Если не секрет, а что именно плохо-то? Локальный прокси с несколькими дефолтными политиками шардирования, специализированные движки, UDP вместо TCP, распределенный конфиг с защитой от устаревания, свой KPHP, компилящийся в C++. Что здесь плохо-то :)? Некоторые вещи могут показаться странными, если вы никогда не сталкивались с похожими проблемами (например, преимущества UDP становятся очевидны только при сочетании огромного числа php-воркеров и огромного числа мемкешей), но сказать, что все очень плохо, у меня язык не поворачивается.
если не затруднит, скиньте, пожалста, ссылочку как с помощью nginx и php обрабатывать UDP. будет очень познавательно

У вк же кастомный протокол и он работает поверх udp. Скорее всего это сделано отдельными расширениями

Там, где обычный php код, то да, просто php модуль.
Наверное я не очень понятно выразился. Читаю уже не первый доклад об архитектуре Вконакте. Мне кажется там в коде все очень «некрасиво» с точки зрения эстетики — нет ООП и наверняка монструозные конструкции для обхода проблем связанных с хайлоадом

Я думаю, что у всех представления об эстетике разные. Далеко не всем нравится ООП и java-стиль, и им наоборот, возможно, понравился бы процедурный стиль вк. И зачастую "монструозные конструкции для обхода проблем с хайлоадом" и представляют из себя очень изящные и красивые решения :). Просто эту красоту можно понять, лишь работая над другими хайлоад-проектами

НЛО прилетело и опубликовало эту надпись здесь

Вконтакте это как Visual Studio или какой-нибудь очень Long Term Support продукт. Код там в 100500 "// TODO" и "// FIXME". Главное, что укладывается в производительность и дедлайны. Иначе они ни одной фичи бы не смогли выкатить нормально.

Открою секрет. 90% продакшн-кода — это полный ужас с точки зрения эстета ООП и ниндзя SOLID архитектуры. Но у всего этого безобразия есть одна важная особенность — оно работает и приносит прибыль. Да, иногда «это» становится трудно поддерживать и модифицировать, да, иногда оно разваливается на глазах, но после alfa и beta-тестов в продакшн уходит относительно стабильно работающий продукт.
Любопытно, если всё равно выносится код в отдельные (насколько я понимаю, независимые) сервисы, то почему непосредственно новые сервисы не реализовывать на более удобных и подходящих для этого инструментах? Проводите ли вы периодически какие-то исследования на этот счёт: всё-таки и Rust уже есть, и Go, и функциональные языки всё чаще используются, причём как раз для похожих задач?
НЛО прилетело и опубликовало эту надпись здесь
«Если уже написали» — это одно. Если функционал делился\продолжает делиться и — это уж наверняка — растёт, то к чему толкать не очень удобные неподрессоренные телеги с оглоблями, если появились тачки с амортизаторами и удобными ручками? Если они, конечно, действительно появились, а не выдаются за таковые.
НЛО прилетело и опубликовало эту надпись здесь

Вам было бы удобно писать на Коболе, если бы для него сделали транслятор в С? А насчёт "неизвестно, что и как" как раз вопрос и был: изучается ли что-то и какие результаты изучения.


Но, на самом деле, я не хочу спорить на эту тему. Я надеялся услышать из первых рук что-то вроде "нет, не проводим, потому что..." или "да, проводим, и решили, что..."

Есть совсем отдельные вещи, которые работают почти как внешние движки/БД/сервисы, и они написаны на Go.
То же, что сильно завязано на уже имеющуюся кодовую базу, нет смысла выносить.

Такой ответ удовлетворяет? :)

Конечно, вполне :)

Вот статья вроде и интересная, но читается очень тяжело (и дело совсем не в технических деталях). Смысл некоторых абзацев формировался только со второго раза. Почему бы перед публикацией не давать прочитать черновик паре-тройке человек?

Возможно потому, что это транскрипт (расшифровка) живого выступления на конференции.

Расшифровка отличается от сказанного. Надеюсь, завтра-послезавтра текст в посте поменяется в лучшую сторону.
А как же «База данных, написанная победителем питерских олимпиад»? А на самом деле оказалось, что "… но MySQL у нас ещё есть". Пичаль(
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории