ну в принципе мнение автора статьи с моим совпадает, что Go, больше для инфраструктурных и серверных задач. Было бы конечно круто, чтобы и в вебе он развивался, а то пока для веб-разработки вспоминает только Revel или собирать самому из библиотек
вот проекты у вас однозначно лучше, чем статьи, уж простите
я бы с удовольствием послушал например статья о том, с какими проблемами/ограничениями в Go вы реально столкнулись и как их решили
да и как я вижу для обработки ошибок вы сами используете err:=nil ;)
вот кстати из статьи в статью упоминается про нишу Go — так а какая она?
На Go я писал только демоны-воркеры для RabbitMQ да и всякие тесты. Причем с таким же успехом приходится писать все это и на Java и честно говоря, Java ближе
Дорогой автор, мне кажется своими статьями и комментариями Вы сделали больше для депопуляризации Go больше, чем любая критическая статья, которую видел до этого
По-моему, в плане громоздкости нет разницы. Может быть Вам непривычно, это да
Но с переменными вы правы, но это уже к синтаксису перменных, а не к типам
вместо def up напишите if
а вообще тут дело в := и это то как он ведет себя согласно документации
другое дело, что программист, пишущий/читающий код, может ожидать от этого оператора немного другого
когда возникает желание что-то выделить в отдельный слой, абстракцию и тд вспоминаю цитату
Управление сложностью — самый важный технический аспект разработки ПО. По-моему, управление сложностью настолько важно, что оно должно быть Главным Техническим Императивом Разработки ПО
если желание осталось — значит действительно надо выделять :)
а вообще с каждым годом МакКоннел открывается в новом свете
1) все классы содержащие эти аннотации должны создаваться через фабрики/DI контейнеры/сервис локаторы
2) это будут не декораторы, а прокси, который будет через __call__ отлавливать вызовы, парсить аннотации, вызывать нужный код, потом вызывать метод проксируемого класса
(именно прокси, а не декораторы, поскольку обычно мы декорируем конкретный класс объектов, а создавать для разных классов декораторы с одинаковым кодом парсинга аннотаций тоже не очень класс)
ну и по итогу
1) в хорошей архитектуре в большинстве случае классы так и будут создаваться, это не проблема
2) из-за использования такого прокси теряется читаемость, да и вызывать call_user_func_array на каждый вызов оборачиваемого метода тоже не класс
поэтому в PHP как и Fesor я предпочитаю использовать явные декораторы
да я и не пытался их сравнивать, в smalltalk классы тоже не такие как в java, но тем не менее паттерны применимы
вот и в случае с python, для программиста незнакомого с python более уместным/классическим будут выглядитт class decorators
можно ведь просто опубликовать на github или написать в блоге, или как вариант есть сайты со сниппетами, могли бы добавить туда
я бы с удовольствием послушал например статья о том, с какими проблемами/ограничениями в Go вы реально столкнулись и как их решили
да и как я вижу для обработки ошибок вы сами используете err:=nil ;)
На Go я писал только демоны-воркеры для RabbitMQ да и всякие тесты. Причем с таким же успехом приходится писать все это и на Java и честно говоря, Java ближе
Пример на Go
Пример на C
По-моему, в плане громоздкости нет разницы. Может быть Вам непривычно, это да
Но с переменными вы правы, но это уже к синтаксису перменных, а не к типам
а вообще тут дело в := и это то как он ведет себя согласно документации
другое дело, что программист, пишущий/читающий код, может ожидать от этого оператора немного другого
если желание осталось — значит действительно надо выделять :)
а вообще с каждым годом МакКоннел открывается в новом свете
1) все классы содержащие эти аннотации должны создаваться через фабрики/DI контейнеры/сервис локаторы
2) это будут не декораторы, а прокси, который будет через __call__ отлавливать вызовы, парсить аннотации, вызывать нужный код, потом вызывать метод проксируемого класса
(именно прокси, а не декораторы, поскольку обычно мы декорируем конкретный класс объектов, а создавать для разных классов декораторы с одинаковым кодом парсинга аннотаций тоже не очень класс)
ну и по итогу
1) в хорошей архитектуре в большинстве случае классы так и будут создаваться, это не проблема
2) из-за использования такого прокси теряется читаемость, да и вызывать call_user_func_array на каждый вызов оборачиваемого метода тоже не класс
поэтому в PHP как и Fesor я предпочитаю использовать явные декораторы
вот и в случае с python, для программиста незнакомого с python более уместным/классическим будут выглядитт class decorators
А в js такое часьл называют decorator function ;)