Ну оно не перестаёт быть болью, даже будучи by design :-) И все эти попытки типизацию там изобразить говорят о том, что не мне одному без неё некомфортно.
Вот, без внешних подпорок сам язык не позволяет. И если мы делаем библиотеку для использования неограниченным кругом лиц, то вопрос об использовании коллекции начинает уже слегка выходить в моральную плоскость. Ну да, хоть про докблоки более-менее все договорились.
Для меня это, пожалуй, в первую очередь строгая типизация. Очень уж нравится, когда по сигнатуре сразу видно, что туда надо передавать, допустим, массив интов. Асинхронность и ко/горутины в общем-то и не каждый день нужны, но когда нужны — здорово, если они есть. Делал на Go одну штуку, куда клиенты приходят за неким расчётом, и если он первый в очереди и расчёт укладывается в таймаут, то клиент получает результат в рамках этого же запроса, иначе возвращается ответ «приходите позже». На Go эта логика в экрана полтора влезает, на PHP же как такое сделать, я даже и не представляю (может быть и можно, но надо крепко подумать).
С автором во многом согласен, но я сдался тоже… когда попробовал Go и обнаружил, что многие боли php там решены на уровне языка и об них можно просто забыть. Сдашься тут, когда столько лет учишься ходить в одном ботинке и вдруг обнаруживаешь, что можно надеть второй.
Скорость работы — это скорость разработки имеется в виду, надеюсь? Потому что в задачах сложнее «получить строчку из базы, заэскейпить, выдать в браузер» (где каждый шаг на самом деле не php, он тут за запятые) скорость исполнения не очень. Делал раз некую парсилку логов, скорость php показалась низковатой, переписал на C — в тридцать раз быстрее заработало. И это, насколько помню, я ещё explode'ом в php строчку разбирал, а когда из любопытства сделал как в сишном варианте побайтовый конечный автомат, всё замедлилось ещё раз в пять.
PHAR — это всё-таки ещё довольно далеко от статической линковки. Чуть-чуть не в тему, но вспомнилось, как у меня в проекте на php валились тесты, потому что не было установлено расширение mbstring. Но какая-то из зависимостей великодушно предоставила polyfill. Но polyfill оказался с отличиями от нативного mbstring :-) Хорошо, что тесты были, без них такое можно было бы довольно долго дебажить.
У вас на сервере стоит какой-то кривущий перекодировщик. В результате как минимум в Опере под Линуксом русские надписи не делаются. KOI8-R должен умереть.
Да, тут уже приводили такой вариант. Миленько, но не масштабируется — два массива так уже не описать, например.
Квадратики на картинке — это биты и есть.
Язык — это не компилятор и не интерпретатор, а набор правил, позволяющих отличить программу на языке от прочих наборов букв.
Ну оно не перестаёт быть болью, даже будучи by design :-)
И все эти попытки типизацию там изобразить говорят о том, что не мне одному без неё некомфортно.
Вот, без внешних подпорок сам язык не позволяет. И если мы делаем библиотеку для использования неограниченным кругом лиц, то вопрос об использовании коллекции начинает уже слегка выходить в моральную плоскость. Ну да, хоть про докблоки более-менее все договорились.
Про strict_types знаю, массив интов как описать? :-)
Для меня это, пожалуй, в первую очередь строгая типизация. Очень уж нравится, когда по сигнатуре сразу видно, что туда надо передавать, допустим, массив интов.
Асинхронность и ко/горутины в общем-то и не каждый день нужны, но когда нужны — здорово, если они есть. Делал на Go одну штуку, куда клиенты приходят за неким расчётом, и если он первый в очереди и расчёт укладывается в таймаут, то клиент получает результат в рамках этого же запроса, иначе возвращается ответ «приходите позже». На Go эта логика в экрана полтора влезает, на PHP же как такое сделать, я даже и не представляю (может быть и можно, но надо крепко подумать).
Нет, ещё на Go попробовал, там оказалось раза в три медленнее C.
С автором во многом согласен, но я сдался тоже… когда попробовал Go и обнаружил, что многие боли php там решены на уровне языка и об них можно просто забыть. Сдашься тут, когда столько лет учишься ходить в одном ботинке и вдруг обнаруживаешь, что можно надеть второй.
Скорость работы — это скорость разработки имеется в виду, надеюсь? Потому что в задачах сложнее «получить строчку из базы, заэскейпить, выдать в браузер» (где каждый шаг на самом деле не php, он тут за запятые) скорость исполнения не очень. Делал раз некую парсилку логов, скорость php показалась низковатой, переписал на C — в тридцать раз быстрее заработало. И это, насколько помню, я ещё explode'ом в php строчку разбирал, а когда из любопытства сделал как в сишном варианте побайтовый конечный автомат, всё замедлилось ещё раз в пять.
PHAR — это всё-таки ещё довольно далеко от статической линковки. Чуть-чуть не в тему, но вспомнилось, как у меня в проекте на php валились тесты, потому что не было установлено расширение mbstring. Но какая-то из зависимостей великодушно предоставила polyfill. Но polyfill оказался с отличиями от нативного mbstring :-) Хорошо, что тесты были, без них такое можно было бы довольно долго дебажить.
Это где сиськи выращивают?