И вроде бы да, но беглый просмотр репозитория показывает, что на самом деле в модель пихается промпт побольше за счет добавления новых скиллов, объясняющих что можно делать. Какая-то странная экономия. И экономия ли? Надо мерять всё это.
Обладаю первым изданием и оно прям хорошо зашло, очень полезное. Вопрос в том теперь - чем второе отличается от первого? Что внесено? Насколько мне осмысленно купить второе хотя бы в электронном виде?
Позволю себе не согласиться. Профессиональные ("доменные") языки получаются из-за многословности и неоднозначности простого разговорного. То же зубодробильный канцелярит - это попытка свернуть в сторону именно однозначности, невозможности толкования "не так". И то - не выходит. Ну и далее - программирование - это описание того, что железка должна сделать. По шагам (императивное) или образ результата (декларативное). Но строго формальное, без возможности разночтений. А знаете как называется строго формальное описание? Код. Оно называется код. И да, оно тоже на понятном языке. ВЫБЕРИ все_поля ИЗ таблицы ГДЕ .... ПОРЯДОК ПО ... Ну честное слово, почти естественный язык же :)
К тому же грот-марсель это и есть "мачта + ярус" - фок (передняя мачта)-марсель(нижний ярус), грот-марсель, крюйс-марсель. А сложные названия могли бы у косых парсуов, которые между мачтами на разных ярусах висят. Стаксель висит между бушпритом и фок(передней) мачтой. И как тут :)
Когда у вас из 6ms времени выполнения запроса в 99.9 перцентиле у вас 5 ms кушает поход в Redis вы задумаетесь о том "а надо ли оно мне" :) Конечно можно сказать - эй, тут 6 ms, не надо ничего оптимизировать. Но если это один из самых нагруженных сервисов... Ну вы понимаете :) А проблемы когеренции кэшей решали задолго до микросервисной архитектуры - еще в мультипроцессорных средах. А память - ну тут классический трейд-офф.
Хранить в RAM можно, иногда даже очень полезно (снижение нагрузки на сеть, ускорение работы критических частей), но с этим надо уметь работать. Принимать ли на себя эти сложности или делегировать их готовому решению - зависит от контекста (с) :)
Как можно улучшить? Ну это зависит от контекста (с) :)
1. Первое что приходит в голову - вернуть все же Redis :)
2. Можно изменения в словарях собственно отправлять в брокер какой-то вроде Kafka, RabbitMQ etc и массив сервисов будет уже его слушать
3. Ну и если хочестся ручной привод: можно выделить роль листенера ограниченному подмножеству инстансов с последующим броадкастом на обновления всем остальным (NATS тот же завести под капот, он очень легковесный).
В ограничения еще стоит добавить, что коннект к PostgreSQL будет держать один из бэкендов БД. Соотвественно каждый экземпляр сервиса будет держать по коннекту. Чем больше инстансов, тем больше таких коннектов. На большом количестве балансирующих (микро)сервисов (речь о дестяках) это может вызвать слишком большую нагрузку на БД просто тем, что вы отобрали потоки (бэкенды), которые висят и ничего не делают. Поэтому на нагруженных сервисах стоит делать по другому.
Не спорю. И pthreads есть еще и много всего. Но ZTS и еще одно расширение. Но - главным образом - ZTS. Это я и назвал "танцы с бубном" :) Может быть я и не прав.
Редко что комментурю, но ваша итоговая таблица, прям просит это сделать.
Типизация - PHP, конечно, динамически типизированный, но статическую типизацию туда завозят очень давно. И, при некоторых условиях, она работает очень хорошо. Особенно в паре с линтерами.
Производительность - в PHP 8 завезли JIT. Внезапно. А у вас, простите, CPU-Bound задачи, чтобы указывать именно на производительность языка?
Масштабируемость - напилить микросервисов на Symfony конечно же нельзя, да? Не понимаю какое тут может быть архитектурное ограничение, кроме как в голове архитектора.
Поддержка многопоточности - тут не спорю, в PHP это либо форки, либо танцы с бубном. Пока движуха ограничилась файберами
Зрелость и стандарты - экосистема PHP - вполне зрелая. Набор PSR - это стандарты. Всё там нормально с этим.
Инстурменты и фреймворки - PHP-экосистема очень даже зрелая. А Symfony - по сути фреймворк Enterprise уровня. Может не стоило переходить в свое время на Laravel, а надо был смотреть в сторону более сложного фреймворка? Документация к Symfony отличная, да и по остальным важным инструментам - всё отлично.
Документация и best practices - ну я уже всё написал. На энтерпрайз решения - всё документировано. На поделки - ну тут как автор поделки захочет.
Безопасность - в PHP нет поддержки JWT? OAuth? Ну вы сейчас не серьезно же, да?
Обучение и комьнити - противопоставление странное. И там и там полно возможностей.
Экосистема и интеграции - покажите примеры, чего вам не хватало и пришлось писать руками? BigData? А что именно?
Сама таблица ограничений проекта на PHP : Монолитная MVC‑архитектура - ну так распилите :)
Устаревший фронтенд (AngularJS, jQuery) - причем тут PHP?
SQL‑поиск по базе данных - причем тут PHP?
Обмен через FTP и файлы - причем тут PHP?
Отсутствие DAM‑системы - причем тут PHP?
Ручная фоновая обработка (CLI) - причем тут PHP?
Нет многопоточности и асинхронности - если с многопточностью я еще худо-бедно соглашусь, она не тривиальна, то асинхронность - ну вы просто не умеете ее готовить в PHP, так и скажите.
Зависимость от нестабильных библиотек - используйте стабильные, такие как Symfony, например, и ее компоненты.
Итог: вы просто хотели переехать на java. Хотели бы поддержать решение на PHP - поддержали бы и всё отлично могло работать. Ну или можно было критические части системы сделать на более производительных технологиях, оставляя те, что IO-Bound на более дешевых.
P.S. Хотя сам на PHP уже не пишу, но приведенные аргументы прямо просят им оппонировать.
Именно так я и делал. А потом копипастил url пакета в go get. И именно этот процесс хотелось ускорить. Мнемонические альясы оказались достаточно удобны. Касательно лезть в конфиг - помощь по команде выдает полный конфиг, по которому можно поискать. Пример: gost mod --help | grep mongo
Видимо весьма зря я статью начал с использования именно для старта нового проекта. Вобщем-то основная проблема была в другом. Вот мне посреди разработки проекта понадобился lru. Я помню, что у меня где-то используется его достойная реализация. Ок, поискав, я найду что это github.com/hashicorp/golang-lru
Но я совершенно не могу помнить как он пишется (или как пишется, например, github.com/valyala/fastjson). Мне нужен был инструмент - указал имя библиотеки -> она появилась в проекте (gost mod lru или go get github.com/hashicorp/golang-lru). Я сделал себе такой инструмент и, спустя время его использования, решил поделиться с сообществом. А запуск на основе его проекта - это уже побочный эффект, оно ничего не стоило.
И вроде бы да, но беглый просмотр репозитория показывает, что на самом деле в модель пихается промпт побольше за счет добавления новых скиллов, объясняющих что можно делать. Какая-то странная экономия. И экономия ли? Надо мерять всё это.
Код на JAVA рендерит JSON как конкатенацию строк.
Код на GO его честно маршаллит. Встроенной либой.
Этого достаточно, чтобы сделать выводы об объективности этого теста.
P.S. О других оптимизациях я уж и говорить не буду.
А, собственно, какого расширения-то?
Обладаю первым изданием и оно прям хорошо зашло, очень полезное. Вопрос в том теперь - чем второе отличается от первого? Что внесено? Насколько мне осмысленно купить второе хотя бы в электронном виде?
Ну вы же понимаете, что эти IDE дополняют контекст для запроса в модель содержимым ваших файлов? Понимаете же да? padme.jpg
Позволю себе не согласиться. Профессиональные ("доменные") языки получаются из-за многословности и неоднозначности простого разговорного. То же зубодробильный канцелярит - это попытка свернуть в сторону именно однозначности, невозможности толкования "не так". И то - не выходит.
Ну и далее - программирование - это описание того, что железка должна сделать. По шагам (императивное) или образ результата (декларативное). Но строго формальное, без возможности разночтений. А знаете как называется строго формальное описание? Код. Оно называется код. И да, оно тоже на понятном языке.
ВЫБЕРИ все_поля ИЗ таблицы ГДЕ .... ПОРЯДОК ПО ...
Ну честное слово, почти естественный язык же :)
К тому же грот-марсель это и есть "мачта + ярус" - фок (передняя мачта)-марсель(нижний ярус), грот-марсель, крюйс-марсель. А сложные названия могли бы у косых парсуов, которые между мачтами на разных ярусах висят. Стаксель висит между бушпритом и фок(передней) мачтой. И как тут :)
Когда у вас из 6ms времени выполнения запроса в 99.9 перцентиле у вас 5 ms кушает поход в Redis вы задумаетесь о том "а надо ли оно мне" :)
Конечно можно сказать - эй, тут 6 ms, не надо ничего оптимизировать. Но если это один из самых нагруженных сервисов... Ну вы понимаете :)
А проблемы когеренции кэшей решали задолго до микросервисной архитектуры - еще в мультипроцессорных средах.
А память - ну тут классический трейд-офф.
Хранить в RAM можно, иногда даже очень полезно (снижение нагрузки на сеть, ускорение работы критических частей), но с этим надо уметь работать. Принимать ли на себя эти сложности или делегировать их готовому решению - зависит от контекста (с) :)
Как можно улучшить? Ну это зависит от контекста (с) :)
1. Первое что приходит в голову - вернуть все же Redis :)
2. Можно изменения в словарях собственно отправлять в брокер какой-то вроде Kafka, RabbitMQ etc и массив сервисов будет уже его слушать
3. Ну и если хочестся ручной привод: можно выделить роль листенера ограниченному подмножеству инстансов с последующим броадкастом на обновления всем остальным (NATS тот же завести под капот, он очень легковесный).
В ограничения еще стоит добавить, что коннект к PostgreSQL будет держать один из бэкендов БД. Соотвественно каждый экземпляр сервиса будет держать по коннекту. Чем больше инстансов, тем больше таких коннектов. На большом количестве балансирующих (микро)сервисов (речь о дестяках) это может вызвать слишком большую нагрузку на БД просто тем, что вы отобрали потоки (бэкенды), которые висят и ничего не делают. Поэтому на нагруженных сервисах стоит делать по другому.
Не спорю. И pthreads есть еще и много всего. Но ZTS и еще одно расширение. Но - главным образом - ZTS. Это я и назвал "танцы с бубном" :) Может быть я и не прав.
Редко что комментурю, но ваша итоговая таблица, прям просит это сделать.
Типизация - PHP, конечно, динамически типизированный, но статическую типизацию туда завозят очень давно. И, при некоторых условиях, она работает очень хорошо. Особенно в паре с линтерами.
Производительность - в PHP 8 завезли JIT. Внезапно. А у вас, простите, CPU-Bound задачи, чтобы указывать именно на производительность языка?
Масштабируемость - напилить микросервисов на Symfony конечно же нельзя, да? Не понимаю какое тут может быть архитектурное ограничение, кроме как в голове архитектора.
Поддержка многопоточности - тут не спорю, в PHP это либо форки, либо танцы с бубном. Пока движуха ограничилась файберами
Зрелость и стандарты - экосистема PHP - вполне зрелая. Набор PSR - это стандарты. Всё там нормально с этим.
Инстурменты и фреймворки - PHP-экосистема очень даже зрелая. А Symfony - по сути фреймворк Enterprise уровня. Может не стоило переходить в свое время на Laravel, а надо был смотреть в сторону более сложного фреймворка? Документация к Symfony отличная, да и по остальным важным инструментам - всё отлично.
Документация и best practices - ну я уже всё написал. На энтерпрайз решения - всё документировано. На поделки - ну тут как автор поделки захочет.
Безопасность - в PHP нет поддержки JWT? OAuth? Ну вы сейчас не серьезно же, да?
Обучение и комьнити - противопоставление странное. И там и там полно возможностей.
Экосистема и интеграции - покажите примеры, чего вам не хватало и пришлось писать руками? BigData? А что именно?
Сама таблица ограничений проекта на PHP :
Монолитная MVC‑архитектура - ну так распилите :)
Устаревший фронтенд (AngularJS, jQuery) - причем тут PHP?
SQL‑поиск по базе данных - причем тут PHP?
Обмен через FTP и файлы - причем тут PHP?
Отсутствие DAM‑системы - причем тут PHP?
Ручная фоновая обработка (CLI) - причем тут PHP?
Нет многопоточности и асинхронности - если с многопточностью я еще худо-бедно соглашусь, она не тривиальна, то асинхронность - ну вы просто не умеете ее готовить в PHP, так и скажите.
Динамическая типизация PHP - делайте статическую + линтеры
Зависимость от нестабильных библиотек - используйте стабильные, такие как Symfony, например, и ее компоненты.
Итог: вы просто хотели переехать на java. Хотели бы поддержать решение на PHP - поддержали бы и всё отлично могло работать. Ну или можно было критические части системы сделать на более производительных технологиях, оставляя те, что IO-Bound на более дешевых.
P.S. Хотя сам на PHP уже не пишу, но приведенные аргументы прямо просят им оппонировать.
Эк сразу. Начинать надо с машины Тьюринга :-)
Возможно стоило бы еще использовать DS\Map - это тоже может дать буст производительности. Особенно если сначала выделить всю нужную память.
Именно так я и делал. А потом копипастил url пакета в go get. И именно этот процесс хотелось ускорить. Мнемонические альясы оказались достаточно удобны. Касательно лезть в конфиг - помощь по команде выдает полный конфиг, по которому можно поискать. Пример:
gost mod --help | grep mongoВидимо весьма зря я статью начал с использования именно для старта нового проекта. Вобщем-то основная проблема была в другом. Вот мне посреди разработки проекта понадобился lru. Я помню, что у меня где-то используется его достойная реализация. Ок, поискав, я найду что это github.com/hashicorp/golang-lru
Но я совершенно не могу помнить как он пишется (или как пишется, например, github.com/valyala/fastjson). Мне нужен был инструмент - указал имя библиотеки -> она появилась в проекте (gost mod lru или go get github.com/hashicorp/golang-lru). Я сделал себе такой инструмент и, спустя время его использования, решил поделиться с сообществом.
А запуск на основе его проекта - это уже побочный эффект, оно ничего не стоило.