Советую посмотреть ozzo-{что-то}. Это независимые библиотеки от создателя Yii-фреймворка на PHP.
Мы используем его:
Логер, он реально крут, по моему мнения вне конкуренции на данный момент.
Валидацию, все просто, удобно и хорошо группируются ошибки.
Роутер, на самом деле используем не на 100%, он, не понимаю почему, построен по аналогии с express.js и другими подобными решениями под node.js с передачей запросов по цепочке обработчиков, что на самом деле не имеет смысла в Го, так как есть нормальный стек вызовов. Не используем его обработчик ошибок.
На счёт DI, не знаю с каких пор он стал анти-паттерном? Вот IoC реализовать в Go я бы не решился. Может я что-то не правильно понимаю, но IoC — это когда контейнер сам управляет приложением и мы просто даём знать объект какого интерфейса нам нужен, а в DI мы можем и сами взять из контейнера зависимости.
Может я путаюсь в этих терминах, но мы тоже решили оставить набрать типизацию, по возможности без всяких interface {}. Просто есть пакет container, которой создаёт все нужные зависимости уровня приложения, типа соединения с БД или логом, а потом в приложении каждый тип достает из контейнера то, что ему нужно.
Каждый подход характеризуется своим набором приемов, но если вы используете неизменяемые объекты — это ещё не значит, что это функциональное программирование.
Основное в каждой парадигме — это абстракция моделирования, а не приемы и организация кода.
То есть, если у меня есть персонаж в игре, который умеет что-то делать, то это ООП, он хранит свои данные и умеет выполнять какие-то действия, которые основаны на этих данных и на входящих параметрах (или сообщениях, если кому-то принципиально смотреть на это именно так).
Но если у нас есть MVC в вебе в каком-то его виде, то Контроллер — это просто группа методов, и то, что они представлены классом — это просто организация кода.
Вот уже в Модель можно что-то моделировать на основе ООП, если в этом есть смысл.
Но объективно, в большей части ситуаций действующее лицо — это "Deus ex machina", который уже управляет группой связанных объектов, который мы обычно и называем уровнем Сервиса, тогда мы приходим к тому, что данные отдельно, функции отдельно и это уже не ООП.
По-моему, такие рейтинги — это средняя температура по больнице и могут влиять очень много факторов.
Мне кажется, что человек решающий задачу для одного и того же сектора, с равной квалификацией получит одну и ту же ЗП с поправкой на то, на сколько просто найти такого человека (если людей не хватает, они дороже).
Отсюда разница больше будет вылазить от сферы применения, чем от языка.
Статья о том, как отсеяться на стадии HR и не дойти до технического специалиста.
P.S. На сколько в компании человеку должно быть нечем заняться, чтобы тратить от 10 до 40 минут на резюме? Это о том, что если все-таки пройти собеседование, то потом можно вообще не напрягаться? Новый уровень отмазки «оно компилируется» — «думаю над резюме» )))
P.P.S. Уже проще было сделать звонок, потратив 3-5 минут на человека, можно больше понять, чем медитирую над резюме!
По поводу фреймворков и Go, есть же знаменитая статья о том, что для Go не нужны фреймворки, мы используем библиотеки по необходимости, а так написать лишние несколько строчек, и то не всегда, — это на много меньшая проблема, чем потом разбираться как сделать то, что нужно в рамках фреймворка.
Главная проблема в современном программировании, что большинство читает всяких Фаулеров и Мартинов, но почти никто не читает Таненбаума, Кернигана и других умных людей, которые реально учёные и инженеры, а не "консультанты".
Вот реально, судя из комментариев, много народу считает, что название и иерархия папок — это проблема, которая требует серьезнейшего решения, но потом начинаешь общаться с людьми и оказывается, что они даже не знают, что такое кеш-линия.
Тут просто у части людей тяжело с чувством юмора, соответственно и с мозгами, поэтому и минусуют.
VSCode полезен для своих задач, WebStorm для своих, но немного иронии — это в тему )))
Простой пример, недавно небольшой проект, который писался в vscode открыл в phpstorm, сразу начал показывать кучу deprecated и ещё кучу всяких штук, которые не обрабатывают расширения vscode.
В общем, это не одно вместо другого, это дополнение.
Например, в связи с тем, что vscode не делает кучу анализов, можно открыть папку с кучей кода, если иногда нужно просматривать, и это никак не скажется на производительности компьютера.
Или нужно что-то быстро поправить.
Или язык не тот, под который основная IDE.
В общем, vscode полезен во многих случаях, но никак не замена полноценного IDE.
Тут все просто учить много языков нужно для того, чтобы курсы не закрылись.
А вообще, конечно, если человек пишет, например, на Delphi и понимает, что если лешится работы, то на расстоянии 500 км шансов на работу нет, то конечно пора учит что-то новое.
Во всех остальных случаях лучше изучать как работает компьютер, начиная от железа, заканчивая рантаймом среды под которой пишите, изучать предметную область для которой пишите.
Но на курсах такому не научат, там расскажут основы языка, которые можно освоить за неделю, поэтому нужно учить много языков, и обязательно на курсах.
Кстати, вот я знаю одну, вроде бы мелочь, но которая сильно радует, в сравнении с тем же VS Code, это форматирование кода, которое реально всегда работает!
Человек, которой сам заявляет, что пишет на языке, на котором нужно, чтобы просто создать класс написать конструктор копий, копирующий конструктор и ещё кучу всякой хрени, а во втором языке нужно при вызове каждого метода класса передавать ссылку(или указатель, не помню что такое self в Python), просто не может говорить о странностях других языков.
Для части описанных задач нужен HTML+CSS, там даже особо серверная часть не совсем нужна.
Для второй части, это все пишется за часы один раз, а потом пользуется в веб-студии без всяких CMS.
Руками писать все равно в разы быстрее получится, если хоть на шаг отходить от того, что умеют плагины к CMS.
Интеграция с сервисами тоже самое, обычно нужно 5 функций из всего API( это максимум, а то и всего две), что делается также руками. И сервисы в основном нужны одни и те же. Ну или веб-студия со временем создаст свою реализацию по частям от разных клиентов.
Его создали одни из крутейших инженеров в Ай-Ти мире, реально как раз хайпа и маркетинга особого и нету, что ещё пока живы куча бессмысленных вещей типа Python в вебе.
Ну и Go это не системный язык, хоть и компилируется в нативный код. Он не прямой конкурент для Rust. Для Rust, как я понимаю, конкурент C++, так как C он тоже скорее всего не заменит.
Советую посмотреть ozzo-{что-то}. Это независимые библиотеки от создателя Yii-фреймворка на PHP.
Мы используем его:
На счёт DI, не знаю с каких пор он стал анти-паттерном? Вот IoC реализовать в Go я бы не решился. Может я что-то не правильно понимаю, но IoC — это когда контейнер сам управляет приложением и мы просто даём знать объект какого интерфейса нам нужен, а в DI мы можем и сами взять из контейнера зависимости.
Может я путаюсь в этих терминах, но мы тоже решили оставить набрать типизацию, по возможности без всяких interface {}. Просто есть пакет container, которой создаёт все нужные зависимости уровня приложения, типа соединения с БД или логом, а потом в приложении каждый тип достает из контейнера то, что ему нужно.
Каждый подход характеризуется своим набором приемов, но если вы используете неизменяемые объекты — это ещё не значит, что это функциональное программирование.
Основное в каждой парадигме — это абстракция моделирования, а не приемы и организация кода.
То есть, если у меня есть персонаж в игре, который умеет что-то делать, то это ООП, он хранит свои данные и умеет выполнять какие-то действия, которые основаны на этих данных и на входящих параметрах (или сообщениях, если кому-то принципиально смотреть на это именно так).
Но если у нас есть MVC в вебе в каком-то его виде, то Контроллер — это просто группа методов, и то, что они представлены классом — это просто организация кода.
Вот уже в Модель можно что-то моделировать на основе ООП, если в этом есть смысл.
Но объективно, в большей части ситуаций действующее лицо — это "Deus ex machina", который уже управляет группой связанных объектов, который мы обычно и называем уровнем Сервиса, тогда мы приходим к тому, что данные отдельно, функции отдельно и это уже не ООП.
HOC — это костыль из React, зачем его тащить туда, где даже нет таких архитектурных косяков, ради которых его придумали?
Если человек хочет писать бизнес логику на SQL, то кто ему доктор? Уже некоторые базы данных дают REST API, которое дёргает функции внутри самой БД.
Но по сути статья бредовая.
По-моему, такие рейтинги — это средняя температура по больнице и могут влиять очень много факторов.
Мне кажется, что человек решающий задачу для одного и того же сектора, с равной квалификацией получит одну и ту же ЗП с поправкой на то, на сколько просто найти такого человека (если людей не хватает, они дороже).
Отсюда разница больше будет вылазить от сферы применения, чем от языка.
P.S. Не говорю, что я написал бы лучше.
P.S. На сколько в компании человеку должно быть нечем заняться, чтобы тратить от 10 до 40 минут на резюме? Это о том, что если все-таки пройти собеседование, то потом можно вообще не напрягаться? Новый уровень отмазки «оно компилируется» — «думаю над резюме» )))
P.P.S. Уже проще было сделать звонок, потратив 3-5 минут на человека, можно больше понять, чем медитирую над резюме!
Люди просто решили сделать себе антиреклама, показать, что они рекрутеры, которые вообще не понимают сути профессии для которой они ищут людей.
Oracle просто продвигает .Net. Кто теперь в здравом уме начнет новый проект на Java?
По поводу фреймворков и Go, есть же знаменитая статья о том, что для Go не нужны фреймворки, мы используем библиотеки по необходимости, а так написать лишние несколько строчек, и то не всегда, — это на много меньшая проблема, чем потом разбираться как сделать то, что нужно в рамках фреймворка.
Главная проблема в современном программировании, что большинство читает всяких Фаулеров и Мартинов, но почти никто не читает Таненбаума, Кернигана и других умных людей, которые реально учёные и инженеры, а не "консультанты".
Вот реально, судя из комментариев, много народу считает, что название и иерархия папок — это проблема, которая требует серьезнейшего решения, но потом начинаешь общаться с людьми и оказывается, что они даже не знают, что такое кеш-линия.
Тут просто у части людей тяжело с чувством юмора, соответственно и с мозгами, поэтому и минусуют.
VSCode полезен для своих задач, WebStorm для своих, но немного иронии — это в тему )))
То есть, всякие консультанты, чтобы напаривать свои никому не нужные услуги, решили вместо слова "асинхронный" написать слово "реактивной"?
Вот что за бред?
Редактор кода и IDE — это не одно и тоже.
Простой пример, недавно небольшой проект, который писался в vscode открыл в phpstorm, сразу начал показывать кучу deprecated и ещё кучу всяких штук, которые не обрабатывают расширения vscode.
В общем, это не одно вместо другого, это дополнение.
Например, в связи с тем, что vscode не делает кучу анализов, можно открыть папку с кучей кода, если иногда нужно просматривать, и это никак не скажется на производительности компьютера.
Или нужно что-то быстро поправить.
Или язык не тот, под который основная IDE.
В общем, vscode полезен во многих случаях, но никак не замена полноценного IDE.
Тут все просто учить много языков нужно для того, чтобы курсы не закрылись.
А вообще, конечно, если человек пишет, например, на Delphi и понимает, что если лешится работы, то на расстоянии 500 км шансов на работу нет, то конечно пора учит что-то новое.
Во всех остальных случаях лучше изучать как работает компьютер, начиная от железа, заканчивая рантаймом среды под которой пишите, изучать предметную область для которой пишите.
Но на курсах такому не научат, там расскажут основы языка, которые можно освоить за неделю, поэтому нужно учить много языков, и обязательно на курсах.
Только вчера вечером задался вопросом, а Хабр вчера утром на него даёт ответ )))
Кстати, вот я знаю одну, вроде бы мелочь, но которая сильно радует, в сравнении с тем же VS Code, это форматирование кода, которое реально всегда работает!
Человек, которой сам заявляет, что пишет на языке, на котором нужно, чтобы просто создать класс написать конструктор копий, копирующий конструктор и ещё кучу всякой хрени, а во втором языке нужно при вызове каждого метода класса передавать ссылку(или указатель, не помню что такое self в Python), просто не может говорить о странностях других языков.
Ничего из описанного не является проблемой.
Для части описанных задач нужен HTML+CSS, там даже особо серверная часть не совсем нужна.
Для второй части, это все пишется за часы один раз, а потом пользуется в веб-студии без всяких CMS.
Руками писать все равно в разы быстрее получится, если хоть на шаг отходить от того, что умеют плагины к CMS.
Интеграция с сервисами тоже самое, обычно нужно 5 функций из всего API( это максимум, а то и всего две), что делается также руками. И сервисы в основном нужны одни и те же. Ну или веб-студия со временем создаст свою реализацию по частям от разных клиентов.
В общем, вообще странно относить CMS к SEO.
При чем тут хайп к Go?
Его создали одни из крутейших инженеров в Ай-Ти мире, реально как раз хайпа и маркетинга особого и нету, что ещё пока живы куча бессмысленных вещей типа Python в вебе.
Ну и Go это не системный язык, хоть и компилируется в нативный код. Он не прямой конкурент для Rust. Для Rust, как я понимаю, конкурент C++, так как C он тоже скорее всего не заменит.