36, начал довольно поздно, в 28 с php. Год назад(в 35) перешёл на Scala, полёт нормальный

Возможно были разные ревизии, но в моём hap ac (первый, не lite) тоже 16Mb flash-памяти

Мало того что все все переменные идут с префиксом $, теперь ко всем функциям надо будет добавлять префикс \, банально неудобно. Функции в неймспейсах по опыту используются крайне редко, чтобы это делать мейнстримом, а проблему производительности возможно получилось бы решить на уровне оптимизаций opcache — в момент компиляции проверять существует ли функция в текущем/импортированном неймспейсах и если нет, сразу писать опкоды для вызова root-функции.

В guzzle используется переопределение json_encode / json_decode, вечно всплывает в автокомплите.
Возможно сделают какую-то оптимизацию на уровне opcache — исключение поиска функции в текущем неймспейсе на этапе компиляции, если это возможно.

Помимо вышеупомянутых минусов есть еще проблема производительности. Событие будет вызываться при изменении/создании любой сущности, и для каждой вы будете делать instanceof.

Мы пришли к использованию своих событий через dispatcher, это даёт больше контроля и снимает привязку к доктрине.

Делать это на событиях доктрины — очень плохая практика. docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/events.html#implementing-event-listeners — здесь подробно описаны ограничения- что можно и чего нельзя делать в каждом конкретном событии, но даже после досконального изучения можно словить очень нетривиальные ошибки.

gc_collect_cycle бесполезен, подтверждаю. А вот вызов gc_mem_caches стоит делать — иначе php не отдаёт память системе — это может быть критично если размер заданий плавает и на некоторых потребление памяти сильно больше среднего.

Turbo Linux 6.0(вроде). Какой-то клон RedHat, причём диск куплен на развалах и копия была кривая — с него невозможно было загрузиться. Устанавливал какими-то адовыми танцами с помощью найденной на просторах загрузочной дискеты на ядре 0.9x(?), ядро которой не умело iso9660, поэтому содержимое диска скопировал на отдельный раздел HDD ext2 с помощью адово глючной утилиты под винду (в середине процесса она могла выдать ошибку и запороть весь раздел)… Как из всего этого получился установленный линукс — не могу сказать, сейчас бы такое наверно повторить не смог =)

Да. За последние два года посмотрел порядка 10 языков включая haskell, erlang, scala. Все языки в чем-то лучше php. Но в чём-то и хуже, идеального языка нет и как оказалось — php не так уж и плох. Если и не как сам язык, то в сочетании с инфраструктурой и библиотеками выигрывает у многих.

Насколько я помню — usr вызывал программу и возвращал в бейсик содержимое регистра BC, поэтому randomize usr был наиболее простым способом проигнорировать этот возврат

Проверил на 7.0, результаты:
time for foreach = 0.11075496673584.
time list each = 1.5992379188538.

Скорее всего foreach оптимизировали со временем, each же поддерживался по остаточному принципу

Плюс скорость. Конечно это было во времена 5.2, но не думаю что сильно что-то изменилось.
http://php.net/manual/ru/function.each.php#75692

Можете привести пример где её использовали? За 7+ лет ни разу не применял и даже не догадывался о её существовании.

Чего там enterprise я тоже не знаю. Модульность зачастую не нужна, факт, но возможность отключить всё лишнее — иногда полезно. В остальном она очень и очень гибкая. Доработать роутинг — пожалуйста, пишешь свой или декорируешь встроенный. Обработчики сессий, кэширование, почти всё можно заменить своим. Кода получается не так много. ORM для сложных sql запросов и не предназначен, он облегчает рутинные действия. Нужен мозголомный запрос — sql всегда лучше, результат по желанию можно привязать к entity и получить сразу объекты. Формы там шикарные — особенно когда нужна вложенность на несколько уровней и коллекции.
От enterprise там пожалуй обратная совместимость. Крупный проект без проблем переезжал c 2.3 на 2.7 и 2.8. Всё работает.

Понятно что универсального решения здесь не будет, поэтому и написал про возможность задать выполнение скрипта на какое-либо действие — возможно этот функционал уже есть, но я его не нашёл?

Возможно ли реализовать включение/выключение xdebug для web-окружения? Например прописать вызов определенного скрипта при включении/выключении «Listening for PHP debug connections»

Можете привести пример опасных вещей в миграции? Нами пока была замечена только некорректная генерация добавления колонок NOT NULL, но в остальном вроде всё в порядке. С чем еще можем столкнуться?

Основная проблема с миграциями — при добавлении к таблице новой колонки NOT NULL приходится переписывать сгенерированный запрос на два запроса вида ALTER xxx DEFAULT 0, ALTER xxx SET NOT NULL. Также в down постоянно попадает строчка создания схемы. В остальном всё работает хорошо.

Пару месяцев назад перенесли не самый маленький сайт с mysql на postgres. За счёт того, что сайт был на symfony/doctrine переезд был практически безболезненный, и занял около трёх дней, которые ушли в основном на переписывание запросов с группировкой.
Из плюсов такого перехода:
— Выросла скорость не некоторых сложных запросах в разы, в среднем запросы отрабатывают на 20-30 процентов быстрее
— За счёт более строгой валидации данных выловили несколько ошибок, когда данные не умещались в колонку
— Написание миграций стало нормальной работой за счёт транзакционности alter table
Из минусов:
— Иногда возникают неприятные баги из-за строгой валидации (например после перехода бывали падения на неверных utf-8 последовательнотей в user-agent, который пишется в базу)
— В целом качество поддержки софтом чуть ниже, чем для mysql (некритичные проблемы с doctrine / doctrine-migrations)