Поэтому я уже давно с недоумением смотрю на людей, которые говорят, что PHP медленный. Когда-то это было так, но сейчас он обходит своих конкурентов по производительности.
Быстрый php по сравнению с другими интерпретируемыми языками, но он в разы(иногда на порядки) медленнее популярных компилируемых языков, в т.ч. упомянутой Java.
Ну и раз уж заговорили о скорости, можно упомянуть, что в PHP практически не подходит для разработки приложений работающих асинхронно(с неблокирующими потоками). В языке для этого есть полторы библиотеки, и они не совместимы со всей остальной экосистемой PHP, включая многие функции стандартной библиотеки, и даже тем же xdebug
Как бы программисты не рассуждали о том, что на определенном языке невозможно сделать хороший проект, а на другом можно, все же ключевой показатель – это Time-To-Market. И вот тут PHP – король!
Очень общее утверждение, которое ничем не подкреплено
либо сайты построенные на конструкторах (wix/shopify/bigcommerce/tilda и так далее). Кстати, все эти конструкторы написаны на PHP и оцениваются в миллиарды долларов. Неплохо так для синего слоника!
Как минимум Wix не написан на PHP, насколько я знаю. Раз уж упомянуто в статье, хотелось бы ссылок на источник информации. Ну и многие компании, которые "оцениваются в миллиарды долларов", обычно осознают, что на таких масштабах с PHP пора съезжать на что-то более быстрое/удобное.
Есть весь туллинг, который нужен современному разработчику
Базовый тулинг есть, я бы сказал. С поддержкой современными платформами всё похуже, как и с библиотеками для более современного тулинга(например, трейсинг, или мониторинг из Прометея какой)
Все внимание CORE PHP разработчиков и PHP-комьюнити сосредоточено на том, чтобы сделать PHP максимально удобным и эффективным инструментом написания бекенда. Именно поэтому современные PHP-фреймворки и библиотеки оказываются лучше
Для полной картины, очень не хватает информации о том, сколько активных core contributors у PHP, а сколько у Java / Kotlin / C# etc. :)
Именно поэтому современные PHP-фреймворки и библиотеки оказываются лучше, чем аналоги на других языках программирования.
Это тоже ничем не подкреплено. Экосистема библиотек в C# / kotlin / Java / JS значительно богаче таковой у PHP. Это быстро становится понятно сравнением популярных клиентов/фреймворков/интеграций etc.
Конечно, именно поэтому PHP нельзя назвать в полной мере языком общего назначения, ибо для других целей, кроме бека его редко используют. Но вы уже должны для себя решить: вам нужна призрачная универсальность или максимальная эффективность?
Максимальная эффективность по каким метрикам?
По поводу ситуации на рынке - согласен, что найти работу джуном на PHP сильно проще, и порог входа ниже(хотя и на эту точку зрения есть критические взгляды).
Со сложными проектами на PHP ситуация уже похуже чем с другими языками, имхо.
Иии? А что, кто-то считает как-то иначе? Как именно иначе?
Практически все, кто использует этот термин тут на Хабре, да и не только на Хабре.
Даже в комментариях под этой статьёй уже были люди, считающие что оригинальный REST имеет какое-то отношение к http-методам(get/post и пр.), хотя это не так.
Полно сервисов в интернете, которые называют свою апишку "REST"/"RESTful", но вместо реализации HATEOAS имеют спецификацию типов полей/ответов, под которую пишутся/генерируются клиенты.
Оригинальный REST по сути ближе всего к тому, как классический веб с его HTML-страничками, переходами и формами работает. Чтобы сделать сайт в простом случае, нам не нужно писать документацию/спецификацию API, вместо этого мы просто описываем наши страницы и переходы между ними через гипертекст и гиперссылки, а браузер выступает универсальным REST клиентом. И это называется HATEOAS.
p.s. Ну и да, REST Филдинга сейчас навряд ли актуален для изучения. Это просто термин который часто используют по назначению
Например для ELK — я ставлю FileBeats & MetricBeats, несколько строчек в конфиге — и всё.
А для Graylog надо было разбираться с их хитрыми протоколоми, которые я тогда не осилил.
Как простой вариант — засылать логи через filebeat, направив его на graylog с target=logstash, парочку лишних полей, которые требует logstash, можно почистить простеньким процессором в грейлоге, чтобы не мешались
Только пользы от предложенной метрики "зрелости" апи нету.
Во первых, то что там происходит в url не важно, во вторых введение "ресурсов" в текущем виде похоже на моделирование через CRUD, что хорошо далеко не всегда, а подаётся как обновление ради обновления.
И да, версионирование апи — вынужденная неприятность.
«Dynamic languages may not catch problems at compilation time but if they have a strong type system»
Звучит как-то странно, учитывая что динамическая типизация и строгость/слабость системы типов ортогональные характеристики.
Думал, ошибка перевода, но и в оригинале такая же фигня.
Был же более-менее хороший разбор habr.com/ru/post/161205
Зависит от терминологии. В определениях приведённой статьи — да, в определениях из, например, TAPL(книга), скорее нет, т.к. типы там определяются как статически гарантируемые свойства программы, а динамическая типизация — оксюморон.
Велосипед — это всё же psalm, а атрибуты — стандарт.
Во первых, аттрибуты ArrayShape, Immutable и пр.(кроме Deprecated), это никакой не стандарт, а выдумка и разработка JB.
Во вторых, psalm появился раньше и вовсю используется многими разработчиками.
В третьих, функционал psalm значительно шире чем предлагаемый упоминаемыми аттрибутами, так что называть его велосипедом тем более не корректно.
Архитектура, в которой код пишется в одной среде, строится в другой и работает в третьей — это не CI/CD, а среднее между лотереей и «русской рулеткой».
Окружение, в котором код пишется, и в котором он работает в продакшене и так всегда разное, и рантайм для контейнеров тут не причём(и уж тем более CI/CD тут не причём).
В своё время так и не нашел аналог в phpdoc. Плохо искал или может со временем добавили? Если кто-то знает, напишите пожалуйста ответ, спасибо!
В стандартах phpdoc нет, а так — давно всё есть в psalm, и со статической проверкой корректности передаваемых аргументов.
JB с кастомными атрибутами в этом плане немного изобрели велосипед, имхо.
В целом, полностью поддерживаю комментарий от gecube ниже, по этому поводу.
Мы, кстати, упоминали в разговоре, что CI/CD это не только деплой, но и всяческие проверки кода, в том числе и не только автоматикой. Очень интересно узнать Ваше мнение, каких пунктов не хватило в нашем обсуждении?
Ну, как то так — www.thoughtworks.com/continuous-integration
У CI вполне есть критерии — разработчики пушат в master/trunk как минимум каждый день, на каждый коммит прогоняются тесты и пр., сломанные билды быстро фиксятся, с CD это всё должно ещё и так же часто выкатываться на прод.
Все проблемы и вопросы, вобщем то, из этого и вытекают, основной и глобальный вопрос конечно в том, как поддерживать культуру разработки на таком уровне, чтобы можно было быстро вносить изменения, пушить в мастер таски которые ещё не готовы ничего не ломая(branch by abstraction, feature toggles и пр.), успевать делать ревью(или как его не делать, или делать после деплоя), как убеждаться что билд не положит прод, как иметь возможность быстро его откатить(вот где требования к инфраструктуре), как постоянно и быстро решать возникающие технические и процессуальные(сошлюсь снова на комментарий выше) проблемы и пр.
PHP8 — это уже и есть типизированный язык с JIT :)
Ассерты в рантайме(а именно ими тайпхинты и являются) — не типизация. Ну или не статическая типизация, если вам такая терминология по душе, хотя в контексте kphp очевидно что речь не о «динамической».
Ну и по скорости PHP 8 по прежнему на порядок отстаёт(и будет отставать) от мейнстримных и не очень компилируемых языков.
Вы сделали одно допущение, что в монолите есть «публичные контракты»!
Если для микросервисов это всегда так (by default).
Я не делал такого допущения, просто считаю что накладные расходы, сложность проектирования распределённой системы, и сложность правки контрактов перевешивают этот спорный плюс.
Спорный потому, что публичные контракты можно делать в монолите — вопрос желания, и потому, что я видел и микросервисы без
задокументированных публичных контрактов — чтобы глянуть api лезли в код. Так что, при желании можно и…
В микросервисной архитектуре они не гадят в одну кодовую базу годами.
А гадят в маленькие изолированные приложения.
Только в том случае если они изолированны, при плохой архитектуре это не так. А при хорошей и в монолите можно делать независимые модули. По поводу переписывания микросервисов по одному, выше уже писали про публичные контракты.
Чем больше связей, тем сложнее переписывать, и тем более переписывание по одному не поможет их исправить, нужно будет собирать общую картину из многих кодовых баз, и править всю цепочку, разбираясь во всех происходящих при этом событиях и эффектах.
Проблема монолитов в том, что если в нем потопталось 3-4 поколения программистов, то заложенная изначально в монолит декомпозиция бывает нарушена почти везде.
Вы исходите из предположения что микросервисы которых потопталось 3-4 поколения программистов лучше чем монолит в котором потопталось 3-4 поколения программистов, в чём я лично не уверен.
С одной стороны — да, границы чуть более явные, с другой — как я писал, нарушения границ сложнее фиксить + накладные расходы на построение распределённого приложения.
В этом плане «тупое» следование принципам микросервисной архитектуры, дает хоть какой-то барьер, для таких «изысков».
Думется, причина тут в том, что при проектировании микросервисной архитектуры(особенно после монолита), разработчики уже встречались с проблемами, частенько это уже не новый проект, и хоть каким-то принципам да следуют, а монолит часто делают тяп-ляп MVP быстрее, «потом перепишем».
P.S. А что до:
И мы имеем, когда из представления сразу обращаются к БД, минуя слой бизнес-логики.
Ну или размазанную бизнес логику между БД и приложением.
Я немного наслышан про некоторые конторы, и о том, чего они творят с микросервисами, тоже волосы дыбом встают. Десятки микросервисов на запрос, сотни микросервисов при условии что в компании всего с сотню разработчиков, отдельный микросервис который ходит в БД с которым общаются все-все сервисы и пр.
Суть проблемы в том что в системе слишком много связей, а не в том что она монолитная или микросервисная. И да, рефакторить паутину в монолите будет проще чем рефакторить паутину из микросервисов.
Ваше предложение из первого комментария верно, только слово «микросервисы» стоит заменить на модули, и грамотно декомпозировать приложение на независимые модули сложно.
Микросервисы лишь проводят чуть более жёсткие границы между модулями, но и нарушения таких границ фиксить сложнее.
А вот когда у вас есть грамотное декомпозированное приложение, и вам нужно масштабировать разработку, ещё меньше конфликтов в коде, добиваться CI/CD(нормального CI, а не «пайплайн настроить»), можно задуматься о микросервисах для большего контроля за границами модулей.
Время идёт, инфраструктура совершенствуется, конечно, но микросервисы по прежнему несут за собой значимые накладные расходы.
Если недостаточно — берёте async-pool и радуетесь жизни.
Я, воодушевлённый как-то статьёй «сложность простоты», взял. Заработало медленее чем я ожидал, и чем больше общее число асинхронных задач, тем больше деградирует производительность, предположительно из-за этого — github.com/jwiegley/async-pool/issues/20, запуск с профайлером из подозрительного говорит об огромном количестве аллокаций.
Видимо, для большого количества тасок, нужна какая-то другая библиотека.
И я ещё раз напоминаю о существовании бирюзовых организаций, почитайте. Например, кейс Valve — там бирюзовый принцип работает для всех, а не только для программистов, и они как-то справляются с ответами на ваши вопросы. Почитайте про внутреннее устройство таких компаний.
Особенно примечательный пример, в контексте возможных разногласий о которых пишет 0xd34df00d, учитывая что в итоге в «бирюзовой» valve внутри появились неявные иерархии, команды старичков, и проблемы с той самой оценкой сотрудников другими сотрудниками, а рейтинг компании от сотрудников на glassdoor упал уже до 3.3, с тезисами «Feels like a disorganized trap» и «Highly toxic work environment», «Advertising flat structure when there actually isn't».
Автор статьи за бенчмарк взял mandelbrot. https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/mandelbrot.html - разница в 6 раз. .
Быстрый php по сравнению с другими интерпретируемыми языками, но он в разы(иногда на порядки) медленнее популярных компилируемых языков, в т.ч. упомянутой Java.
Ну и раз уж заговорили о скорости, можно упомянуть, что в PHP практически не подходит для разработки приложений работающих асинхронно(с неблокирующими потоками). В языке для этого есть полторы библиотеки, и они не совместимы со всей остальной экосистемой PHP, включая многие функции стандартной библиотеки, и даже тем же xdebug
Очень общее утверждение, которое ничем не подкреплено
Как минимум Wix не написан на PHP, насколько я знаю. Раз уж упомянуто в статье, хотелось бы ссылок на источник информации. Ну и многие компании, которые "оцениваются в миллиарды долларов", обычно осознают, что на таких масштабах с PHP пора съезжать на что-то более быстрое/удобное.
Базовый тулинг есть, я бы сказал. С поддержкой современными платформами всё похуже, как и с библиотеками для более современного тулинга(например, трейсинг, или мониторинг из Прометея какой)
Для полной картины, очень не хватает информации о том, сколько активных core contributors у PHP, а сколько у Java / Kotlin / C# etc. :)
Это тоже ничем не подкреплено. Экосистема библиотек в C# / kotlin / Java / JS значительно богаче таковой у PHP. Это быстро становится понятно сравнением популярных клиентов/фреймворков/интеграций etc.
Максимальная эффективность по каким метрикам?
По поводу ситуации на рынке - согласен, что найти работу джуном на PHP сильно проще, и порог входа ниже(хотя и на эту точку зрения есть критические взгляды).
Со сложными проектами на PHP ситуация уже похуже чем с другими языками, имхо.
Практически все, кто использует этот термин тут на Хабре, да и не только на Хабре.
Даже в комментариях под этой статьёй уже были люди, считающие что оригинальный REST имеет какое-то отношение к http-методам(get/post и пр.), хотя это не так.
Полно сервисов в интернете, которые называют свою апишку "REST"/"RESTful", но вместо реализации HATEOAS имеют спецификацию типов полей/ответов, под которую пишутся/генерируются клиенты.
Оригинальный REST по сути ближе всего к тому, как классический веб с его HTML-страничками, переходами и формами работает. Чтобы сделать сайт в простом случае, нам не нужно писать документацию/спецификацию API, вместо этого мы просто описываем наши страницы и переходы между ними через гипертекст и гиперссылки, а браузер выступает универсальным REST клиентом. И это называется HATEOAS.
p.s. Ну и да, REST Филдинга сейчас навряд ли актуален для изучения. Это просто термин который часто используют по назначению
target=logstash, парочку лишних полей, которые требует logstash, можно почистить простеньким процессором в грейлоге, чтобы не мешалисьТолько пользы от предложенной метрики "зрелости" апи нету.
Во первых, то что там происходит в url не важно, во вторых введение "ресурсов" в текущем виде похоже на моделирование через CRUD, что хорошо далеко не всегда, а подаётся как обновление ради обновления.
И да, версионирование апи — вынужденная неприятность.
Во вторых, psalm появился раньше и вовсю используется многими разработчиками.
В третьих, функционал psalm значительно шире чем предлагаемый упоминаемыми аттрибутами, так что называть его велосипедом тем более не корректно.
JB с кастомными атрибутами в этом плане немного изобрели велосипед, имхо.
Ну, как то так — www.thoughtworks.com/continuous-integration
У CI вполне есть критерии — разработчики пушат в master/trunk как минимум каждый день, на каждый коммит прогоняются тесты и пр., сломанные билды быстро фиксятся, с CD это всё должно ещё и так же часто выкатываться на прод.
Все проблемы и вопросы, вобщем то, из этого и вытекают, основной и глобальный вопрос конечно в том, как поддерживать культуру разработки на таком уровне, чтобы можно было быстро вносить изменения, пушить в мастер таски которые ещё не готовы ничего не ломая(branch by abstraction, feature toggles и пр.), успевать делать ревью(или как его не делать, или делать после деплоя), как убеждаться что билд не положит прод, как иметь возможность быстро его откатить(вот где требования к инфраструктуре), как постоянно и быстро решать возникающие технические и процессуальные(сошлюсь снова на комментарий выше) проблемы и пр.
Ассерты в рантайме(а именно ими тайпхинты и являются) — не типизация. Ну или не статическая типизация, если вам такая терминология по душе, хотя в контексте kphp очевидно что речь не о «динамической».
Ну и по скорости PHP 8 по прежнему на порядок отстаёт(и будет отставать) от мейнстримных и не очень компилируемых языков.
Спорный потому, что публичные контракты можно делать в монолите — вопрос желания, и потому, что я видел и микросервисы без
задокументированных публичных контрактов — чтобы глянуть api лезли в код. Так что, при желании можно и…
Чем больше связей, тем сложнее переписывать, и тем более переписывание по одному не поможет их исправить, нужно будет собирать общую картину из многих кодовых баз, и править всю цепочку, разбираясь во всех происходящих при этом событиях и эффектах.
С одной стороны — да, границы чуть более явные, с другой — как я писал, нарушения границ сложнее фиксить + накладные расходы на построение распределённого приложения.
Думется, причина тут в том, что при проектировании микросервисной архитектуры(особенно после монолита), разработчики уже встречались с проблемами, частенько это уже не новый проект, и хоть каким-то принципам да следуют, а монолит часто делают тяп-ляп MVP быстрее, «потом перепишем».
P.S. А что до:Я немного наслышан про некоторые конторы, и о том, чего они творят с микросервисами, тоже волосы дыбом встают. Десятки микросервисов на запрос, сотни микросервисов при условии что в компании всего с сотню разработчиков, отдельный микросервис который ходит в БД с которым общаются все-все сервисы и пр.
Ваше предложение из первого комментария верно, только слово «микросервисы» стоит заменить на модули, и грамотно декомпозировать приложение на независимые модули сложно.
Микросервисы лишь проводят чуть более жёсткие границы между модулями, но и нарушения таких границ фиксить сложнее.
А вот когда у вас есть грамотное декомпозированное приложение, и вам нужно масштабировать разработку, ещё меньше конфликтов в коде, добиваться CI/CD(нормального CI, а не «пайплайн настроить»), можно задуматься о микросервисах для большего контроля за границами модулей.
Время идёт, инфраструктура совершенствуется, конечно, но микросервисы по прежнему несут за собой значимые накладные расходы.
Видимо, для большого количества тасок, нужна какая-то другая библиотека.
Без подвоха вопрос, правда интересно, где иначе.