Наверняка, многие из вас слышали про Hack. Мне интересно узнать, как вы относитесь к этому языку? Есть ли люди, которые используют его в своей работе?
Причем здесь оптимизации? Мне, например, нравится строгая типизация в Hack. Мне не хватало этого в PHP. Добавлено спустя 48 секунд: Это вопрос времени
я пробовал, отсутствие внятной документации по HHVM порождает кучу шаманских статей в инете по её настройке. А прирост есть, но небольшой. я считаю, что это самое большое зло, которое только можно привнести в веб-разработку.
криворуким это никак не поможет. откуда вообще убеждение что строгость типизации влияет на качество кода?
во-первых это миф городской. до появляения скриптовых языков, криворуких прогеров меньше не было. просто папки были моложе. во-вторых, это усложняет прототипирование и снижает скорость последующей разработки. в-третьих, это лишает плюшек, когда от типа переменной зависит поведение скрипта. (false !== null !== 0 !== '') памяти до усраки у фейсбука нету другого выхода и они вынуждены идти на такие меры. что за хайлоад проекты у вас? =) что вы вынуждены
Хорошо, не так выразился. Строгая типизация делает код более безопасным. Добавлено спустя 1 минуту 41 секунду: У меня нет хайлоад проектов. Но если есть возможность ускорить работу сайта затратив меньше ресурсов, почему бы этим не воспользоваться?
да неужели? =) попробуй мою цмс Добавлено спустя 40 секунд: а ты думаешь, какое ускорение ты получишь? HHVM дала мне +25% производительности. и усё.
Строгая типизация в пыхе - палочка о двух концах. С одной стороны экономия памяти на "правильных переменных". С другой стороны - оверхеды на конвертацию типов, которая будет по-любому нужна. Ну нельзя числовую переменную вывести без конвертации на страницу. Это отдельная оптимизационная задача - компромисс времени и памяти. Рано или поздно, когда все гайки затянуты, и ни одно ни другое некуда сокращать, начинается торг, или-или. В пыхе сейчас этот баланс довольно хорош. Они расходуют лишнюю память, но экономят процессорное время. Смена типа переменной тут не означает изменение ее области хранения. Физически она не меняется, меняется ее контекст в выражении. Утрированно, лучше взять лишний метр на 0.01 секунды, чем всего 1кб, но на 10 секунд.
1) Безопасным делают код умственные способности программиста. Дебил же и в строгой типизации наделает дел. С безопасностью, скажем так, типизация вообще никоим образом не связана. О какой безопасности вообще идет речь? С говнокодом связана, да. 2) Никто не мешает кодить в пыхе как в сях. С единственной разницей, что не надо явно конвертировать типы там, где это нужно. Это на си нельзя кодить как на пыхе. А в обратную сторону - наздоровье. Если ты не говнокодер, то и тут не нагадишь.
Ну тогда это не строгая типизация, а ее имитация, которая никак не связана с точным выделением памяти
Согласен, но кто-то по ошибке может не проверить данные поступающие из формы. Речь идет не только о быдлокоде, но и ресурсах. Добавлено спустя 33 секунды: Вообщем, я понял ваше мнение =). Спасибо.
тут описание и прочее viewtopic.php?f=26&t=47212 тут живой проект viewtopic.php?f=26&t=47979 Добавлено спустя 1 минуту 18 секунд: неужели ты исчерпал все остальные методы (читай: докинь 300 рублей, возьми впс по-мощнее) чтобы так ударяться в аскетизм?
Проблема кривых рук и слабого тестирования. Пару раз удариться о грабли и норм. Я выше описал, почему в данном случае нестрогая типизация оправдана. В плане ресурсов. З.Ы. Касательно оптимизации и издержек - снижайте их за счет пересмотра алгоритмов и понимания работы пыха с теми же массивами в плане памяти. Вот когда упретесь в сам пых, тогда и думайте о HHVM и тд. Но и то, уже тогда, когда у вас будет количество серверов как у вконтакте или фейсбука, и когда вам будет дешевле запилить/имплементировать подобное решение, нежели докупать еще машины и оплачивать затраты электроэнергии. Был тут человек, у которого на запрос отъедалось почти 20 метров. Говорил, это нормально, это поведение пыха, мол оптимизировать некуда уже. Когда я его задолбал и он решился на рефакторинг, то мало-помалу, у него проект стал жрать 6 метров на вызов. Оказалось, было-таки куда оптимизить именно алгоритмы.