Спустя пять лет с момента формирования ветки 3.0 компания Facebook представила (https://hhvm.com/blog/2019/02/11/hhvm-4.0.0.html) выпуск виртуальной машины HHVM 4.0 (https://hhvm.com/) (HipHop Virtual Machine), поддерживающей выполнение программ на языке Hack (https://www.opennet.ru/opennews/art.shtml?num=39368) (вариант PHP со статической типизацией). С оговорками поддерживается синтаксис PHP 5 и большинство возможностей (http://hhvm.com/blog/10859/php-7-support) PHP 7. Код проекта написан на C++ и распространяется (https://github.com/facebook/hhvm) под открытыми лицензиями PHP и Zend.
Отличительной чертой HHVM является применение JIT-компиляции и динамических оптимизаций, учитывающих особенности выполнения скрипта. В процессе выполнения кода производится определение типов данных и генерация на лету эффективных наборов машинных инструкций, оптимизированных специально для используемых типов. Перед выполнением PHP-скрипты преобразуются в специальное промежуточное абстрактное представление AST (Abstract Syntax Tree), которое затем транслируется в байткод HHBC (HipHop bytecode), который выполняется внутри высокоуровневой виртуальной машины.
Проект активно используется в инфраструктуре Facebook. Ранее HHVM использовался проектами WordPress (https://make.wordpress.org/core/2017/05/25/hhvm-no-longer-pa.../) и Wikipedia (https://www.mediawiki.org/wiki/HHVM). После намерений Facebook отказаться от полной поддержки PHP данные проекты перешли на ветку PHP 7, которая начиная с PHP 7.2 в некоторые тестах опережает (https://kinsta.com/blog/hhvm-wordpress/) по производительности (https://kinsta.com/blog/php-benchmarks/) HHVM.
Ключевые изменения:
- HHVM отныне не нацелен на обеспечение полной совместимости с PHP. Начиная с HHVM 4.0 прекращена поддержка некоторых специфичных для PHP особенностей, без которых будет нарушена совместимость с большинством PHP-проектов. Например, больше не поддерживаются особенности обработки массивов, не свойственные массивам и коллекциям языка Hack, прекращена поддержка ссылок (http://php.net/manual/ru/language.references.php) на переменные, удалены функции, требующие доступа к памяти вызывающего, такие как compact(), extract(), get_declared_variables(), func_get_args() и parse_str() с одним аргументом. Прекращена поддержка менеджер зависимостей Composer (https://www.opennet.ru/opennews/art.shtml?num=44214). В следующем выпуске планируется прекратить поддержку тега "‹?php";- Добавлена поддержка файлов с расширением ".hack" для скриптов а языке Hack. В отличие от расширения ".hh" скрипты в файлах ".hack" автоматически запускаются в режиме "strict (https://docs.hhvm.com/hack/typechecker/modes#strict-mode)" (жёсткая проверка типов) и не требуют обрамления в тег "‹?" (как в скриптах на других языках теперь используется заголовок "#!/usr/bin/env hhvm");
- Стабилизирована библиотека HH\lib\Regex, входящая в состав HSL (Hack Standard Library (https://github.com/hhvm/hsl/)) и предоставляющая поддержку регулярных выражений, определяемых при помощи префиксов (например,
$pattern = re"/foo(bar)?/").
URL: https://hhvm.com/blog/2019/02/11/hhvm-4.0.0.html
Новость: https://www.opennet.ru/opennews/art.shtml?num=50133
Зачем еще один PHP?
А зачем так много разных марок легковесных авто?
Спроси у немцев и других французев. У нас в стране одна марка.
> Интересно, что сцукерберги являясь богатой технологической компанией,это сцукенберг богатый технолог - а компания бедная, он (судя по просачивающейся информации) на конкурсе паталогической жадности победил бы даже Безоса.
поэтому и неасилили - умные и грамотные оттуда сбегают при первой возможности, остаются пехепе кодеры.
заметь, случаев человеков добровольно и без принуждения сбежавших из sun или даже ужасного microsoft мне совершенно не известно.> Лучше бы карму починил себе, скоро как у Биллигейца станет.
это ему поперерождаться неприкасаемым раз этак с триста, чтоб как у блингейца стала, придется. Тот иностранным шпионам личную информацию своих пользователей как-то ни разу вроде не слил.
Чтоб потребитель мог выбрать нравящийся ему шильдик.
Уперлись они в его производительность/сопровождаемость. Сначала компиляли в С++ (проект назывался hiphop), а теперь свою vm написали: скорость выполнения подняли, типов добавили в язык (привет любителям динамической типизации). Когда дофига написанного кода - так проще.
Видимо, им проще и дешевле чинить PHP, чем переходить на нормальный язык.
Ну и какой язык в манямирке сегодня нормальный? В реальности же - PHP и есть самый нормальный язык для своих задач. Как по статистике, так и по факту. Просто не стоит забывать, что каждый инструмент имеет своё назначение.
Раскройте секрет для каких задач pho
Для мейнстримных. Мейнстрим тоже приносит бабло (люди покупают машины - компании имеют деньги). А пхп мейнстримный - его просто понять, есть в любой дыре за копейки, шишки все набиты. Что еще нужно для "поднять сайт за вечер" или "поднять проект чувакам, которым нужна куча взаимозаменяемых разрабов"?
конечно дешевле - так я двух нормальных разработчиков нанял, они подпиливают это хевеэм, 24/7, сдохнут новых найму.
А саму мордокнигу пишут на этом дешевые макаки, в Хайдерабаде на рынке если в шесть утра зайти, то на рупь пучок продают.Причем, в отличие от этих первых умных, те слаще морковки не едали, и щасливы горбатиться на меня за три копейки, никуда не убегают.
Надеюсь, следом за Hack, PHP8 будет тоже двигаться в сторону статической типизации и выкинет несовместимые с этим особенности, функции и языковые конструкции.
Вы так говорите, как будто это что-то плохое.
Динамическая типизация?
На практике - вредная и ненужная вещь. Достаточно простых переводов в строку и обратно на уровне языка, и статика наведет порядок там, где сейчас его можно упустить просто по небрежности.
Пока РНР был языком тяп-ляп функций, как JS, динамика была критичной.
Сейчас, когда все всерьез и через ООП, она больше мешает.
Проблема не в том, что она не нужна, а в том, что это куда больше выразительной силы, чем обычно нужно пользователю, что создает дополнительную сложность и когнитивную нагрузку. Да тот же ООП в большинстве случаев предоставляет куда больше динамизма, чем нужно.
Использовать конструкции языка, предоставляющие минимально нужную выразительную силу — хорошая практика.
Проблема пыха не динамическая типизация, а легаси и слабая типизация.
Проблема еще и в том, что тем, кто продолжает писать это легаси, не подается 220В на клавиатуру.
Угу. Лепим ООП к месту и не к месту, получая на выходе одноразовый тормозной говнокод.Была тут ситуация - нужно было разобрать список телефонных префиксов в дерево, навесить на проходные узлы ветвей несколько параметров, и просчитывать потом параметры листьев по запросу.
Сначала сделал рабочий PoC "легаси" - на хэшах и просто массивах. Потом вспомнил, что сейчас модно ООП, сконвертил префиксы в объекты, объявил проперти параметров, геттеры-сеттеры, методы прохода к ветвям и расчёта, "всё как надо". Накладные расходы по памяти на формирование дерева оказались таковы, что пришлось всё это счастье выкинуть, и вернуться к ассоциативным массивам.
Мораль: забивать гвозди отвёрткой - вредно.
Внезапно, именно статическая типизация могла уменьшить потребление памяти в вашем случае.
Если, конечно, не дурить и не строить деревья из объектов без всякой на то необходимости.
Необходимость в деревьях там 100%, в процессе обработки нужно выхватывать произвольные субдеревья с наследованием параметров и перечислением индексов как наличествующих, так и отсутствующих листьев. Листьев - семь с половиной миллионов. Параметров в дереве не много, но они ближе к началу-середине, и реже - на листьях. Там вариантов банально нет.
Некропостнул.
А, геттеры-сеттеры это у нас ООП, понятно. Сдуру можно и буй сломать. Бегом читать Фаулера и Эванса, в частности про антипаттерн anemic model.
Дурак выхватил из рассказа два малозначительных слова, и на основании них начал делать свои далеко идущие выводы. Впрочем, на то он и дурак.
См. "правило тринадцатого удара". Если часы пробили 13 раз, то следует усомниться в верности каждого удара часов.Впрочем, я вас особо не виню: то, что сейчас популяризировано в качестве ООП, и то, что на самом деле им является - это две большие разницы. Критикуют обычно первое и вполне справедливо.
Надеюсь, что нет. Идите на хрен со своей типизацией "пока в вилларибо настраивают сборку, в виллабаджо уже сделали MVP"
... на Ноде, которой ничего такого - вроде статической типизации или широкого использования в серьезных проектах - не грозит.
Все серьезные проекты давно на TS
ну оооок, у меня, значит, несирьозный, понял-понял...
Серьезный или несерьезный, а типизация очень хорошо помогает не накосячить тупейшим образом. У меня есть что сравнивать: вот под рукой два проекта (оба одинаково серьезные), старый написан на чистом ES5, а новый на Typescript. Если с Typescript почти все ошибки вида "забыл обязательное поле или опечатался в имени ключа в цепочке map/filter/reduce" ловятся уже на этапе компиляции, то с чистым ES5 такая же ошибка приводит к получасу мучительной отладки.
> Если с Typescript почти все ошибки [...] на этапе компиляцииСколько раз вам нужно запустить компиляцию, чтобы исправить реально все обнаруженные ошибки? Сколько это по времени, помноженное на время компиляции?
Ничего не имею против строгой типизации, но вся это маята с компиляциями из одного языка в другой, потом ещё 10 раз, потом ещё интерпретатор с jit... не проще ли сразу взять нормальный язык типа c++? Компилироваться будет столько же, но хоть при выполнении не будет жрать как не в себя.
чтобы отлавливать ошибки не нужно запускать компиляцию, это делает IDE.
Компиляция tsс только для билда, а там не только типы, но и трансляция фич, не существующих в js.TypeScript еще хорош тем, что можно настроить строгость типизации как тебе угодно, хочешь быстро и без строгих типов - пожалуйста, вся гибкость js вместе со статической проверкой и автодополнением.
В общем он как js, только лучше.С++ не даст вам такой гибкости.
> Сколько раз вам нужно запустить компиляцию, чтобы исправить реально все обнаруженные ошибки?Вручную - 0 раз, все ошибки видно сразу в IDE.
А, ну то есть синтаксис верный - можно и в продакшн. Ферштейн.
Типичный аноним Опеннета не в состоянии удержать контекст обсуждения глубиной более одного комментария, да?Речь шла, внимание, об ошибках несовпадения типов, которые ловит компилятор. Надо приглашать Капитана Очевидность, который разъяснит, какие еще ошибки бывают?
> типизация очень хорошо помогает _криворучкам_ не накосячить тупейшим образомFixed
>> типизация очень хорошо помогает _криворучкам_ не накосячить тупейшим образом
> FixedА хорошим программистам позволяет форсировать так же и логическую корректность кода.
Дорогой друг. Я понимаю что ты ахринеть разработчик. Но у меня за плечами, 7 лет си, 5 лет php, 2 года js, 5 лет ruby и 3года golang. И если ты говоришь что тебе статическая типизация нужна что бы не косячить то ты даун. Твои проблемы от нестрогой типизация. А статическая типизация добавляет проблем при нереиспользовании кода. Конечно если ты веб макака пишущая круды на готовом фреймворке то тебе это мало о чем скажет.
Поддерживаю.
Дорогой друг! Во-первых, если уж меряться, то у меня за плечами опыта в 3 раза больше твоего. Во-вторых, если ты внимательно перечитаешь мой комментарий, я вообще нигде не упоминал конкретные категории типизации. Предлагаю самостоятельно выяснить, к какой категории относится типизация в Typescript как по параметру строгая/нестрогая, так и по параметру статическая/динамическая. (Вопрос с подвохом, между прочим).
На подмножестве PHP уже сейчас можно писать строго. Выкидывать там ничего не будут хотя бы потому, что тогда придется переписать примерно весь Wordpress, но самому себе никто не мешает запретить использовать "опасное" подмножество PHP. Есть линтеры, есть настройки анализатора кода в IDE, есть, в конце концов, code review.
> На подмножестве PHP уже сейчас можно писать строго.Строго - это когда ты определяешь в любом месте кода:
int a;
и теперь a можно присвоить только число в определённом диапазоне.
А когда ты можешь это указать только в параметрах ф-ий и м-ов - то это вообще ничто!> ...тогда придется переписать примерно весь Wordpress,
И чё!?
> А когда ты можешь это указать только в параметрах ф-ий и м-ов - то это вообще ничто!На самом деле, при должной декомпозиции (когда нет простыней по сто строк кода) на практике получается почти то же самое.
> И чё!?
То, что никто это делать не будет.
Вот сразу видно, когда "классики" лезут в язык с динамической сборкой. В итоге при попытке притащить свои паттерны и "декомпозицию" по 5 строчек кода на класс / функцию, размазанных по 100500 отдельным файлам, у них внезапно начинаются проблемы, потому что динамическая сборка не дружит с подходами кодэ-макак, неспособных удерживать в голове более трёх строк одновременно (оставшиеся две - название функции с агрументами и закрывающая скобка).
Это вы лихо всех авторов общепризнанных паттернов проектирования ПО в кодомакак записали. :-)Нет, кодомакаки это как раз писатели простынок с цикломатической сложностью over 100500 методом копипаста со stack overflow.
Проблем с декомпозицией нет никаких вообще, динамика ей не мешает никак, с чего бы?
С того бы, что PHP вынужден каждый раз всю эту портянку подгружать и парсить. На каждый, сцуко, запуск. Сейчас opcache слегка спасает, но и он не всесилен.А мозговой стэк оверфлоу при чтении кода - это как раз у горе-декомпостеров ради декомпоста, без цели и смысла.
В php времен 4/5 opcache из коробки не было по одной простой причине - чтобы Zend мог продавать свой коммерческий кэшер опкодов. Без той или иной реализации opcode cacher никто в здравом уме PHP не использовал.А начиная с семерки opcache в PHP из коробки.
В критичных случаях можно делать прогрев кэша после деплоя, но в 99% случаев этого не требуется.
Когда у кодомакак ломается паттерн - это хорошо. Потому, что учиться думать самостоятельно - хорошо безусловно.
https://github.com/lakwarus/wordpresshhvmНикогда не говори...
3 commits, 6 years ago. Сразу видно, проект живет и развивается!
Какой смысл в ПХП со статической типизацией если есть Java с отлаженным JIT, богатым выбором библиотек и отсутствием геммороя со сборкой расширений.
> Какой смысл в ПХП со статической типизацией если есть Java с отлаженным
> JIT, богатым выбором библиотек и отсутствием геммороя со сборкой расширений.Какой смысл в жабе с её виртуальной машиной, если есть C++ с отлаженной кросплатформенной компиляцией, богатым выбором библиотек и отсутствием геморроя с докупкой оперативной памяти?
Такой что требуется значительно больше времени тратить на разработку вместо того чтобы купить память.
Отсутствие ручного выделения памяти для вас уже недостаточно? Или вы по причине своей не компетентности не понимаете что для каждого яп свои задачи?
Поместил php8 с jit компилятором, на бенчмарках показывает 40% прирост производительности и 26% на реальном проекте, жаль в прод его пока рано.
Потестировал*
Это проект из разряда "допили сам". За 3 года так и не дошел до прода с поддержкой php.
Но работает и правда шустро. Не вижу кому он без пхп может понадобиться, кроме самого фейсбука?!
В чем смысл убрать <?php ?
В том, что это больше не PHP, а скорее самостоятельная поделка для внутренних нужд фейсбука.
> В том, что это больше не PHP, а скорее самостоятельная поделка для внутренних нужд фейсбука.Как Go для Гугла?
Ну не совсем, но типа того. За пределами оных они бессмысленны.
> Ну не совсем, но типа того. За пределами оных они бессмысленны.К Go это уже определённо не относится. А вот Hack/HVVM скорее всего так и останется языком одной фирмы, виртуальная машина которого одно время использовалась для ускорения PHP.
Логично, HHVM как альтернативный JIT для PHP с выходом семёрки уже как-то и не нужен (вот и Wikipedia.ORG в процессе перехода с HHVM на PHP 7.0). Поэтому фейсбуковцы и сконцентрировались на поддержке своего языка. Нужен ли такой брат-2 PHP — вопрос другой. На фоне того что PHP начал терять популярность — далеко не факт, очень сильно сомневаюсь, что за пределами FB кто-то станет переписывать большой проект с PHP на Hack (хотя это, наверняка и проще, чем на что бы то ни было другое).
А между тем язык Hack в TIOBE вытеснил с 50-го места TypeScript. Наверняка в связи с этим самым новым HHVM, но мало ли, чем чёрт не шутит, ввдруг кому-то вне FB да пригодится.