если ты работаешь один возможно. В любом другом случае помогают.

а что можно на микрофреймворке сделать быстрее и эффективнее чем на yii2?

а что можно на микрофреймворке сделать быстрее и эффективнее чем на yii2?

опять таки - быстрее - это неинтересно :)

быстро нагенерить какието jQuery обвязки - это не то, о чем стоит говорить

опять таки - быстрее - это неинтересно :)

Интересно - это что то из района фанатизма

а что можно на микрофреймворке сделать быстрее и эффективнее чем на yii2?

зависит от проекта. Но вообще если функционала хватает -все.

зависит от проекта. Но вообще если функционала хватает -все.

Мой поинт в том что ничего)

йи разворачивается за 5 сек и еще за полчаса можно модельки набросать

Мой поинт в том что ничего)

это же унаследованный код к которому уже есть доки и куча людей его знающих. Если он приносит 200мб кода и его хватает то твои гигабайты Yii (я вообще хз сколько там кода и зачем этот фремйворк и считаю его корявым и бездарным...) избыточны

не понял кто унаследованный и кто приносит 200 мб?

если речь о микрофреймворках, то обычно их сравнивают со своим велосипедом. Сравнивать их с полноценным фреймворком странно

йи разворачивается за 5 сек и еще за полчаса можно модельки набросать

sf разворачивается за 5 сек и еще за полчаса можно модельки набросать не показатель

sf разворачивается за 5 сек и еще за полчаса можно модельки набросать не показатель

ну да, и люмен снова не нужен

блин. нафиг сравнивать фреймворк на проектах где "модельки набросать" - это 30 минут делов. какой в этом смысл?

ну да, и люмен снова не нужен

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

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

а че жалко 20 мб места на диске?

для таких проектов скоро сделают полноценную замену бэкэнда подобную Firebase.

ну да, и люмен снова не нужен

lumen не знаю, а вот silex точно не нужен - я пробовал - вышла с ним полноценная sf standart edition в свое время

а че жалко 20 мб места на диске?

просто бесполезный код. который нужно поддерживать и за который нужно платить.

как поддерживать и чем платить? Абсолютно не нужно

я конечно понимаю, что пхп программисты в среднем школоло и их работа стоит дешево, но все же это деньги. Даже обновление фреймворка -это деньги, поскольку это работа тех, кто его поддерживает.

Никакой конкретики не сказал. Микрофреймворк тоже обновляется.

Вообще есть простое слово -избыточность. Про него тысячи страниц в интернете исписанны.

А увольнять за то что на диске +20мб пакетов лежит - ну это неадекват.

Никакой конкретики не сказал. Микрофреймворк тоже обновляется.

микрофреймворк обновляется, но все его компоненты используются, контролируются и от этого не избавиться.

Вообще есть простое слово -избыточность. Про него тысячи страниц в интернете исписанны.

У избыточности есть еще сотня трактовок.

ух. тогда у всех у кого есть node_modules надо сразу увольнять. там больше 100Мб почти всегда лежит :))

А увольнять за то что на диске +20мб пакетов лежит - ну это неадекват.

избыточность, не понимание задачи. Любой не используемый код в проекте -это мусор и в любом проекте который не умрет через год это убытки.

избыточность, не понимание задачи. Любой не используемый код в проекте -это мусор и в любом проекте который не умрет через год это убытки.

что за чушь ты несешь :)

ну лежит и лежит. о нем никто и не знает никогда

избыточность, не понимание задачи. Любой не используемый код в проекте -это мусор и в любом проекте который не умрет через год это убытки.

Вендорный код нет конечно. Это то на что ты не можешь повлиять. И пусть себе лежит.

ну я сильно обобщаю конечно, но смысл почти верный )

Ты ж не сокрушаешься что в ядре линукса куча вызовов которые твой продукт не дергает? Не выбираешь из-за этого busybox ?

Вендорный код нет конечно. Это то на что ты не можешь повлиять. И пусть себе лежит.

зачем? на самом деле мне сложно придумать аргумент почему это плохо. Но могу точно сказать что код в котором куча лишнего выглядит не профессионально. Возможно это субъективно мое мнение, но это мусор, от которого нужно избавляться. Это потенциальное место для багов, это то за чем нужно следить. Зачем это все, когда пользы этот код несет -0. И да я уверен, если какой -то кусок мусора остается в проекте, то в конце концов он станет причиной проблем. И если и не увольнять, то по крайней мере заставить отработать исправления бесплатно или оплатить работу того, кто будет исправлять -это норма.

ну это же был сарказм )

зачем? на самом деле мне сложно придумать аргумент почему это плохо. Но могу точно сказать что код в котором куча лишнего выглядит не профессионально. Возможно это субъективно мое мнение, но это мусор, от которого нужно избавляться. Это потенциальное место для багов, это то за чем нужно следить. Зачем это все, когда пользы этот код несет -0. И да я уверен, если какой -то кусок мусора остается в проекте, то в конце концов он станет причиной проблем. И если и не увольнять, то по крайней мере заставить отработать исправления бесплатно или оплатить работу того, кто будет исправлять -это норма.

Я вижу что в таком мышлении как раз и есть куча проблем. Работа над зачисткой того что не требует внимания, брать новый микрофреймворк только потому что якобы в нем файлов меньше - это все снижает сильно скорость разработки.

в противном случае использования Yii для создания сайта визитки я вижу равносильно тому, что я просто сгенерю html, а при деплое положу на сервере пару томов "гарри поттера", места же не жалко. Пусть лежит

> на самом деле мне сложно придумать аргумент почему это плохо. Потому что такого аргумента и не существует. Это никогда не плохо, за исключением случаев когда у нас система должна запускаться в 200кб свободного места какого-нибудь.

Я вижу что в таком мышлении как раз и есть куча проблем. Работа над зачисткой того что не требует внимания, брать новый микрофреймворк только потому что якобы в нем файлов меньше - это все снижает сильно скорость разработки.

это бред. Фреймворк выбирается под задачу и только тогда, когда он упрощает работу. Если есть фреймворк, который лучше подходит под задачу -то использовать нужно его. Хотя конечно если у кого -то работают операторы фреймворков, а не программисты и новый фреймворк потребует значительных усилий, то может и подумать стоит...

это бред. Фреймворк выбирается под задачу и только тогда, когда он упрощает работу. Если есть фреймворк, который лучше подходит под задачу -то использовать нужно его. Хотя конечно если у кого -то работают операторы фреймворков, а не программисты и новый фреймворк потребует значительных усилий, то может и подумать стоит...

Ну вот как раз таки микрофреймворки не упрощают работу ни в чем. А зато надо в голову вбивать новые концепции и методы.

Мне один чел задвигал что все фреймворки это плохо, так как там очень много файлов. А ему нравится когда весь проект написан в 5-6 файлах, и так меньше избыточности.

> на самом деле мне сложно придумать аргумент почему это плохо. Потому что такого аргумента и не существует. Это никогда не плохо, за исключением случаев когда у нас система должна запускаться в 200кб свободного места какого-нибудь.

для тебя не существует, а я всегда удалю по максимуму лишний код, большая часть тех, кого знаю делают так же. Конечно никто не лезет в код фреймворка, просто его не используют там, где не нужно. И я сотни раз слышал, как не используемый код был стоп сигналом. Буквально даже уверен, что эти код джуна отличается -мусором.

Мне один чел задвигал что все фреймворки это плохо, так как там очень много файлов. А ему нравится когда весь проект написан в 5-6 файлах, и так меньше избыточности.

при чем тут файлы? это не используемый код. Ты понимаешь что тебе платят за решение поставленной задачи наиболее эффективным способом. Оставлять мусор в проекте -это не выполненная работа.

что такое термин "мусор" ? vendors это не мусор

ну ок. возможно, спорить не буду, я лет 5 сайты не делал, а визитки не делал никогда.

А два контроллера и так будут что в йи что в люмене. userspace кода и там и там крохи.

что такое термин "мусор" ? vendors это не мусор

ок, я понял суть твоего мнения. И переубедить тебя я не пытаюсь, просто координально не согласен с этим, у нас скорее всего просто разные задачи и потому разный взгляд на мир. Я пытаюсь всегда минимизировать число библиотек и особенно открытых, без поддержки за деньги. Не использовать инструменты вроде ноды, которые часто ломают совместимость своими пакетами и т.д. Ну и соответсвенно дело не в размере, дело в том, что этот код может быть зависим, нести баги, уязвимости и т.д. Если этот код мне не нужен я не хочу его поддерживать, а просто оставлять его в проекте я не имею права. Мне платят за другое.

Ты значит говоришь про "userspace" код. А если один контроллер со вьюхой, ну и плевать что там к ней 20мб вендоров валяется. Это не повод брать микрофреймворк.

ну как бы сложно сказать, может я слишком долго в мире го и микросервисов живу, но эти 20мб -это дорого. Хотя это не причина отказа, причина именно в неиспольуемости и том, что я не хочу оставлять то. что мне не нужно.

То есть тебя не смущает что бинарник go который выводит hello world компилируется в монстра весом в 3 мегабайта? И туда вкомпилируется весь libc ?

При том что статическая линковка библиотек считается плохим тоном

И еще - снисходительно говорить о php разработчиках а самому писать на go это очень неадекватно, т.к. довольно массивная часть айтишников считает go разработчиков тупыми кодомакаками и разработческим мясом :)

И еще - снисходительно говорить о php разработчиках а самому писать на go это очень неадекватно, т.к. довольно массивная часть айтишников считает go разработчиков тупыми кодомакаками и разработческим мясом :)

гошники - кодомакаки? :) а phpшники - кто тогда?

гошники - кодомакаки? :) а phpшники - кто тогда?

Ну тоже типа

То есть тебя не смущает что бинарник go который выводит hello world компилируется в монстра весом в 3 мегабайта? И туда вкомпилируется весь libc ?

код, который я пишу -это неизбежность... а увеличение веса контейнера на эти 20мб мусора -это идиотизм )

И еще - снисходительно говорить о php разработчиках а самому писать на go это очень неадекватно, т.к. довольно массивная часть айтишников считает go разработчиков тупыми кодомакаками и разработческим мясом :)

это их проблемы, я начну переживать, когда их зарплаты хотя бы сравняются с моей ) Но если я тут значит мне нужн писать код на пхп, вот я и пытаюсь разобраться и вспомнить как оно... но если честно просто жопа... отвык я не только от такой архитектуры (прям против шерсти все) но и от этой свалки функций )

это их проблемы, я начну переживать, когда их зарплаты хотя бы сравняются с моей ) Но если я тут значит мне нужн писать код на пхп, вот я и пытаюсь разобраться и вспомнить как оно... но если честно просто жопа... отвык я не только от такой архитектуры (прям против шерсти все) но и от этой свалки функций )

Раскрой какая у тебя зарплата

Она у гошников впринципе не больше чем у пхпистов, как мне кажется

Раскрой какая у тебя зарплата

есть такая штука - nda. Но ты можешь посмотреть опросы стековерфлоу и примерно прикинуть верхний перцентиль )

Она у гошников впринципе не больше чем у пхпистов, как мне кажется

на уровне сеньера мой знакомый после 3 лет опыта на пхп и месяца изучения Го на курсах пошел на 150к в Питере в марте (еле еле натянул на мидла и да знаний у него было почти 0, он в доках, где 80 страниц путался ))) и это совсем не верхняя планка из офферов была. Но в целом да зп всех разработчиков на одном уровне по квалификации. ЯП значения не имеет. Просто в Go задачи несколько другие и сайты никто не пишет, потому в среднем планка выше значительно Но если брать какой -то сеньера в Яндексе (пxп) том же. то да примерно также

То есть ты меряешь зарплатой в основном?

То есть ты меряешь зарплатой в основном?

зарплатой я не мерялся, я о ней вспомнил, когда ты сказал, что Go шники рукожопы (или как -то так), зп в данном случае дял меня значительный формфактор

но я еще на python 2 года писал и пол года на руби, довольно не плохо с js и ts знаком и java стороной не прошла с objc

Ну да рукожопы, а получают много из-за хайпа )

ERROR: S client not available

Да нет конечно :) Квалификация разработчика не всегда зависит от языка на котором он пишет

потому по ощущениям -да зп похожи. Но задачи в мире Go обычно завязанны на большой доле девопса, всей этой оркестрации и куче инструментов. Я вообще мало джунов на Go видел )

Я вижу главное отличие (и преимущество пхп) в том что пхп макаки способны создать целостный продукт (ну еще js придется выучить), а вот гошники могут идти только как винтики в готовую систему.

ты в курсе сколько сегодня веб фреймворков на Go ?)

Да но на них ничего не напишешь, факт

го как язык просто отвратителен когда речь заходит о программировании бизнес логики

и что создать сайт можно едва ли не быстрей, пхп только встраиваемостью в хтмл выигрывает и колличеством хостингов)

А вот как I/O молотилка байтов он неплох.

го как язык просто отвратителен когда речь заходит о программировании бизнес логики

мне сложно найти в нем минусы, кроме отсутствия дженериков... а вот отсутсвией всей этой лапши ООП прям радует.

Ну про минусы не одна статья написана

Ну про минусы не одна статья написана

боюсь писали их либо фанаты java и C# либо те, кто не осилил остутсвие array reverse и подобного ))) Но вообще это инструмент, не больше. Я не верю в программиста на каком -то ЯП. Если мне будет нужно использовать другой я буду использовать (именно потому я в пхп, мне не нужна статическая типизация в монолитах веба, а поддержка пхп всеми удобна, ну и плюс 7+ прям хороший..). Пока альтернатив адекватных нет. Go позволяет писать код для людей, достаточно быстрый и отлично паралелится. И да прям не проверял раньше, но сейчас посмотерл, helloworld -1.1мб на убунте собрался )

И да прям не проверял раньше, но сейчас посмотерл, helloworld -1.1мб на убунте собрался ) Это как если бы hello world на php занимал 110мб

Я вот написал на одном _нормальном_ языке прокси сервер и он у меня получился 31кб ? Вот это - ничего лишнего.

это обратная сторона GC, но это то, почему Go отличный инструмент для людей.

Go -это не скорость и не минимализм. Это современный ЯП для быстрой разработки в команде. При чем с упором на опытных пользователей. Да нужно знать основы CS иначе будет сложно, библиотека тонкая.

PHP -это не скорость и не минимализм. Это современный ЯП для быстрой разработки в команде. При чем с упором на опытных пользователей. Да нужно знать основы STL иначе будет сложно, библиотека толстая.

и "современность" тут не базворд, а факт. Он решает задачи, которые важны сегодня. Сборка под любую платформу, которая работает. Своя объектная модель, которая очень эффективно работает без липши кода. Многопоточность, встроенные тесты, профилировщик и т.д

вся суть в том, что на нем удобно писать. После go сложно писать на чем то другом.. постоянно чего то не хватает. А дженерики... надеюсь скоро появятся )))

$ ls -alh | grep hello -rwxrwxr-x 1 ubuntu ubuntu 2.2M May 8 15:14 hello -rw-rw-r-- 1 ubuntu ubuntu 82 May 8 15:14 hello.go

А как ты собирал?

ты наверно fmt импортировал )

$ ls -alh | grep hello -rwxrwxr-x 1 ubuntu ubuntu 721K May 8 15:18 hello -rw-rw-r-- 1 ubuntu ubuntu 60 May 8 15:18 hello.go

?

ну оптимизировать и отключать GC было бы не честно )

?

если соберешь GOGC=off go build -ldflags "-s -w" то меньше 650 будет ) -rwxrwxr-x 1 artem artem 674K May 8 18:22 hello -rw-rw-r-- 1 artem artem 53 May 8 18:21 hello.go

Давайте не оффтопить

вообще удивляюсь, сколько пхп хейтеров сидят по пхп чатам ;)

а где ты тут хейтеров то увидел? я вроде как наоборот хвалил 7+ ))

Слушайте, а ктонить раскуривал как работает php ffi ?

суслика видишь? а он есть!