Находится в бесконечном устаревании, поддерживается китайцами (оригинал построенный на hyperf как минимум), багтрекер завален иероглифами, найти актуальную документацию весьма непросто, доходило даже до абсурда - не работает HowTo быстрый старт инструкция с официального сайта. Это просто мрак. А ведь фреймворк на свуле действительно нужен, но делать его должны не дилетанты, а профи типа симфонийцев
Хз, сам занимаюсь наймом, откликов действительно много, жаль только сеньоров среди них ни одного, а именно их на рынке дефицит, и по моему он только усиливается. так что вкатиться это хорошо, но стать специалистом к сожалению удается далеко не каждому. Джунам соболезную, сеньорам - велкам.
Ждем, верим и недеемся когда в Go наконец не перестанут забрасывать проекты, начнут делать нормальную документацию и сделают хотя бы сколь-нибудь приближенную версию аналога Laravel. За последние 10 лет этого пока не произошло. За то есть бэкенды на go для Laravel и не только :)
работал с довольно большим количеством интересных и не очень проектов. По скорости разработки с пхп не сравнится ничто. ближайший аналог - нода, страдает от детских болячек и незрелого комьюнити джава скрипт программистов, функциональный подход откровенная слабость. тайп скрипт нелепая попытка подражать шарпам, хотя сам js меня вполне устраивает. пхп за последние годы вбирает в себя лучшие практики и при этом остаётся верен старшему брату, эталону - крестам. есть асинхронность, мультитрединг, параллелизм, корутины. я писал парсеры логов для хайлоад систем которые работали быстрее аналогов на Go и при этом были несравнимо проще. но вот с популярными cms в работе я никогда не сталкивался, возможно поэтому я свободен от негативных коннотаций. а вот с битриксом работать приходилось, и это зло, так даже японцы не издевались. и ещё кое что - за последнее десятилетие в разных языках и стеках конкретно на пхп я ниразу не столкнулся с проблемами с обратной совместимостью, разве что переход на PDO с mysql. задумайтесь над тем что вы делаете. возможно причина не там где вы её ищете.
Не хватает кармы что бы немного восстановить Вам, как мне кажется, не совсем оправданно заниженный рейтинг. Всех комментариев не читал, но предвижу толпы ущемившихся девопсов и питонистов. Грамотно спроектированный монолит действительно выигрывает у микросервисов по всем параметрам в мире идеального кода, в том числе и в цене за обслуживание кстати. Проблема в том что мы живём в мире неидеального. Для монолита нужны настоящие сеньоры, архитекторы и аналитики в одном лице, их на рынке не так много, поэтому для бизнеса логичнее диверсифицировать свои риски моделью микросервисов и чуть менее квалифицированным персоналом. Плюс играет роль технологический стэк который может быть разным под разные решаемые задачи. Это уже вопрос риторики - считать ли это разными проектами или "микросервисами" одного проекта. /thread
Как я понял ключевое отличие от NativePHP в том что тут нет электрона, а концепт позаимствован у Tauri. Почему бы тогда и остальные решение оттуда не перенять ? например AppImage для Linux. В принципе идея достойна жизни, спасибо китайцам которые статически слинковыеные бинари для пыхи сделали и автоматизировали сборку. Вот бы кто оптимизированный обфускатор для PHP фреймворков и vendor запилил (тайно намекаю людям с офигенно большим количеством свободного времени заняться полезным и нужным). Жаль только с асинхронщиной полная шляпа в плане кросплатформенности. Swoole есть только под nix, а Parallel уступает по многим параметрам.
А вот если касаться конкретной задачи из жизни, то тут я например для себя принимаю другое решение - у нас тут Boson даёт использовать GUI фреймворк на JS по сути, не вижу ничего зазорного притащить на бэкенд Node и делать всё что мне нужно в нём (в электроне вроде бы уже это всё из коробки присутствует), а там уже ни с асинхронщиной, ни с другими возможностями проблем нет, плюс экосистема единая 👀
отличная статья, сам не так давно реализовывал мудреный алгоритм с большим количеством вхождений по хэшам и с удивлением обнаружил для себя на сколько эти массивы в php эффективные, просто космос для интерпретируемого языка.
А какие ещё могут быть дженерики ? в первую очередь нужно думать о бенефитах которые это всё предоставляет, а исходя из прочтения оригинальных статей я их для себя так и не смог вывести. Возможно сообществу стоило сместить акцент именно на это, например тотальная типизация могла бы быть использована для кодогенерации в какой нибудь Си. Но пока что это выглядит как тотальное усложнение без видимых преимуществ (о чем критики и говорят упоминая стат анализаторы которые не дают импакта на производительность). Надо продолжать работать, например над библиотеками для ML о чем Пронский и переживает за уход разрабов из стэка в питонисты например. Только тогда комьюнити будет расти и набираться свежей крови.
Пока что я против, по крайней мере до момента когда не появится вменяемый роадмэп который наглядно объяснит где это можно использовать и принесёт преимущества
проще все делать в рамках той экосистемы которой автор в совершенстве владеет, тем более когда как мы видим - инструментарий вполне позволяет. не совсем понятно для чего погружаться в чужеродный стэк с большими перспективами забросить.
А ещё это ставит под вопрос самосознание высших приматов, чей мозг в полном своём объёме работает хуже чем у этого мужика. Разобраться в разуме стало очень непросто.
Находится в бесконечном устаревании, поддерживается китайцами (оригинал построенный на hyperf как минимум), багтрекер завален иероглифами, найти актуальную документацию весьма непросто, доходило даже до абсурда - не работает HowTo быстрый старт инструкция с официального сайта. Это просто мрак. А ведь фреймворк на свуле действительно нужен, но делать его должны не дилетанты, а профи типа симфонийцев
Хз, сам занимаюсь наймом, откликов действительно много, жаль только сеньоров среди них ни одного, а именно их на рынке дефицит, и по моему он только усиливается. так что вкатиться это хорошо, но стать специалистом к сожалению удается далеко не каждому. Джунам соболезную, сеньорам - велкам.
Ждем, верим и недеемся когда в Go наконец не перестанут забрасывать проекты, начнут делать нормальную документацию и сделают хотя бы сколь-нибудь приближенную версию аналога Laravel. За последние 10 лет этого пока не произошло. За то есть бэкенды на go для Laravel и не только :)
работал с довольно большим количеством интересных и не очень проектов. По скорости разработки с пхп не сравнится ничто. ближайший аналог - нода, страдает от детских болячек и незрелого комьюнити джава скрипт программистов, функциональный подход откровенная слабость. тайп скрипт нелепая попытка подражать шарпам, хотя сам js меня вполне устраивает. пхп за последние годы вбирает в себя лучшие практики и при этом остаётся верен старшему брату, эталону - крестам. есть асинхронность, мультитрединг, параллелизм, корутины. я писал парсеры логов для хайлоад систем которые работали быстрее аналогов на Go и при этом были несравнимо проще. но вот с популярными cms в работе я никогда не сталкивался, возможно поэтому я свободен от негативных коннотаций. а вот с битриксом работать приходилось, и это зло, так даже японцы не издевались. и ещё кое что - за последнее десятилетие в разных языках и стеках конкретно на пхп я ниразу не столкнулся с проблемами с обратной совместимостью, разве что переход на PDO с mysql. задумайтесь над тем что вы делаете. возможно причина не там где вы её ищете.
все есть, parallel например, корутины есть. в целом товарищ сверху за базу пояснил.
Не хватает кармы что бы немного восстановить Вам, как мне кажется, не совсем оправданно заниженный рейтинг. Всех комментариев не читал, но предвижу толпы ущемившихся девопсов и питонистов. Грамотно спроектированный монолит действительно выигрывает у микросервисов по всем параметрам в мире идеального кода, в том числе и в цене за обслуживание кстати. Проблема в том что мы живём в мире неидеального. Для монолита нужны настоящие сеньоры, архитекторы и аналитики в одном лице, их на рынке не так много, поэтому для бизнеса логичнее диверсифицировать свои риски моделью микросервисов и чуть менее квалифицированным персоналом. Плюс играет роль технологический стэк который может быть разным под разные решаемые задачи. Это уже вопрос риторики - считать ли это разными проектами или "микросервисами" одного проекта.
/thread
Как я понял ключевое отличие от NativePHP в том что тут нет электрона, а концепт позаимствован у Tauri. Почему бы тогда и остальные решение оттуда не перенять ? например AppImage для Linux. В принципе идея достойна жизни, спасибо китайцам которые статически слинковыеные бинари для пыхи сделали и автоматизировали сборку. Вот бы кто оптимизированный обфускатор для PHP фреймворков и vendor запилил (тайно намекаю людям с офигенно большим количеством свободного времени заняться полезным и нужным). Жаль только с асинхронщиной полная шляпа в плане кросплатформенности. Swoole есть только под nix, а Parallel уступает по многим параметрам.
А вот если касаться конкретной задачи из жизни, то тут я например для себя принимаю другое решение - у нас тут Boson даёт использовать GUI фреймворк на JS по сути, не вижу ничего зазорного притащить на бэкенд Node и делать всё что мне нужно в нём (в электроне вроде бы уже это всё из коробки присутствует), а там уже ни с асинхронщиной, ни с другими возможностями проблем нет, плюс экосистема единая 👀
отличная статья, сам не так давно реализовывал мудреный алгоритм с большим количеством вхождений по хэшам и с удивлением обнаружил для себя на сколько эти массивы в php эффективные, просто космос для интерпретируемого языка.
А какие ещё могут быть дженерики ? в первую очередь нужно думать о бенефитах которые это всё предоставляет, а исходя из прочтения оригинальных статей я их для себя так и не смог вывести. Возможно сообществу стоило сместить акцент именно на это, например тотальная типизация могла бы быть использована для кодогенерации в какой нибудь Си. Но пока что это выглядит как тотальное усложнение без видимых преимуществ (о чем критики и говорят упоминая стат анализаторы которые не дают импакта на производительность). Надо продолжать работать, например над библиотеками для ML о чем Пронский и переживает за уход разрабов из стэка в питонисты например. Только тогда комьюнити будет расти и набираться свежей крови.
Пока что я против, по крайней мере до момента когда не появится вменяемый роадмэп который наглядно объяснит где это можно использовать и принесёт преимущества
проще все делать в рамках той экосистемы которой автор в совершенстве владеет, тем более когда как мы видим - инструментарий вполне позволяет. не совсем понятно для чего погружаться в чужеродный стэк с большими перспективами забросить.