VM Java создает не нужный оверхед при исполнении и при разработке.
Про исполнение это дискуссионный вопрос. Потому что надо брать и сравнивать что то сложное. Как пример асинхронный драйвер из vertx был самым быстрым. Или взять что из последнего и там в топе Го практически не встречается, а Джава да.
И про разработку, вы тут не правы. На Джаве программы пишутся быстрее чем на Го. Взять например простой рест ендпоинт который ассинхронный и что то читает с базы и отдает потом жсон наружу. в Джаве со спрингом это будет буквально две строчки кода, в Го я думаю вам придется написать их гораздо больше.
Rust создает не нужный оверхед при разработке.
Возможно, но думаю что дело в квалификации программиста.
И при одинаковой квалификации Го и Раст девелопера, последний будет продуктивней. Потому что ему не надо лепить какие то генераторы, а будут генерики. На каждый чих делать if err != nil а использовать цепочку вызовов.
А так же за Растом система типов а в Го будут interface{} и дальше только молится что туда попадет что ожидается.
Вы не правы. Если вы делаете нормальные слои и взаимодействие то заменить какую то имплементацию будет относительно просто. Говорю из своего опыта когда приходилось мигрировать проекты с Монги или ДинамоДБ на Постгрес.
Чистая архитектура это не мы как то разбили криво на слои. Не может быть в чистой архитектуре в слое который сохраняет юзера в базу какого то TaskNotification
или же создание бизнес сущности User не может быть просто структура в которую можно накидать как угодно какие угодно данные.
Те если бы статья называлась пример наших костылей, то я и слова бы не сказал. А так замахнулись на чистую, понимаете ли, нашу архитектуру. И в результате выкатили какую то поделку.
Коммерческую разработку писать нужно на том, что лично вы лучше знаете.
Меня интересовало ваше мнение, а не банальная отмазка.
Решив, что усложнения ни к чему.
Вы считаете, что на Джаве нельзя писать так же коряво и в лоб как и на Го?
Или можно пример когда решение на Джаве потребует больше времени на реализацию и будет сложнее в понимании чем решение на Го?
Но человечество проходило переусложнение еще и до С++ и до Java.
Те по вашему для прикладного программиста сделать в Джаве @Mock MyInterface someVar гораздо сложнее чем на каждый чих перегенерировать моки в Го?
Там и объясняется почему именно авторам языка не хотелось бы видеть их в таком виде в Go.
Авторы лицемеры, потому что для list и map они почему то генерики сделали. Если они не нужны по их мнению, то покажите как надо без них писать.
Приведенная статья большей частью просто ворчание человека, который еще не привык к языку.
Ну вот смотрите запускаю я go build и golint и никаких варнингов. Голанд зеленая тоже. Но вы продолжайте дальше утверждать, что проблем нет.
Есть еще разная квалификация программистов.
Мы говорим об языках и насколько они позволяют избегать ошибок.
Например, я и без линтеров сразу видел косяк в вашем коде.
Я тоже видел и это лишь показывает, что вы умнее Го компилятора :)))
У каждого языка свои проблемы.
Согласен, но назовите по каким причинам мне надо взять и писать мой микросервис не на Джаве или Расте или Ноде/Тайпскрипт а на Го?
Я вижу Го как язык который нахватался каких то обрывочных идей но целостности нет.
У меня и локально go build проходит без всяких предупреждений.
Так же вы говорили про ошибки компилятора, а теперь мы вдруг речь уже ведем о внешних линтерах. Которые не являются частью языка, не у всех установлены, по разному настроены, кидают простыню сообщений и на них забивают через некоторое время. Как пример разных настроек — в Goland никаких сообщений о том, что с кодом что-то не так, не показывается.
На мой взгляд тут вообще не пахнет чистой архитектурой.
Вы в репозиторий при создании юзера передаете какой то TaskNotification — как это относится к созданию юзера в персистент слое???
Функция func (a *Application) CreateUser зачем то делает еще Login, как это узнать не глядя в код и самое главное зачем вы смешиваете разные действия в одно? Что вы будете делать когда создали юзера а логин по какой то причине упал?
Почему (*User, AuthToken, error) возвращает юзера по ссылке а остальные данные по значению? Так же в CreateUser в репозиторий вы этого юзера передаете по значению.
У вас User публичная структура и ничего не мешает взять ее и создавать с частичными полями. А по правильному архитектура не должна давать создавать невалидные объекты.
Начнет с того, что статья утверждает, что на все бросились переписывать с Питона на Го и распиливать свои монолиты на Го.
Вы не говорите почему он не подходит для бизнес логики,
Свое видение я привел, почитайте мой предыдущий коментарий.
Это не является принципиальным препятствием к написанию БЛ быстро и легко.
И где какие то ваши аргументы, от вас кроме демагогии ничего взамен нет. Моя позиция может быть правильной а может и нет. Если вы не согласны с ней то факты в студию, чтобы у нас была какая то дискуссия.
Это в каких-то летописях записано, что без системы типов хаскеля и дженериков бизнес-логику писать нельзя?
Потому что это про различные типы. Там не надо с зеро-кост получать откуда то байты и потом их передавать. А надо уметь выражать бизнес сущности и их отношения между собой. В Го мы можете написать к примеру умный и сложный билдер для вашего User, но вы спокойно в методах UserAddress который в том же пакете сидит будете иметь возможность создать User напрямую с доступом ко всем приватным полям.
что изначально имеет совсем другие подходы к проектированию программ.
Расскажите какие правильные парадигмы для написания бизнес логики в Го, что они столь отличаются от всех других языков.
А вы, как и многие другие пробуете натянуть джаву на синтаксис от го,
причем здесь синтаксис, если я говорю что Го вам не может гарантировать ничего из выше-перечисленного и не дает каких либо других плюшек с помощью, которых вы будете писать бизнес логику быстро и легко.
И посмотрите на ваш ответ — в нем опять никакой конкретики в чем я не прав, а лишь отрицание фактов и ничего вы не понимаете
В Го у вас нет ни системы типов как в Хаскеле ни ООП с Генериками как в Джаве.
Поля у вас или доступные всем внутри пакета или вообще доступные всем. И сделать приватные поля/методы для вашего обьекта вы не можете.
Обработка ошибок кривая — мой комментарий к другой статье
Изначально статья (и не только эта) утверждает что-то и не пытается доказать. Мне же доводы повторять в каждой подобной статье утомительно.
Хотите возьмем какое то утверждение из статьи и приведите ваши доводы.
Go отлично не подходит для написания бизнес логики, поэтому писать на нем корпоративные микросервисы можно либо из-под палки или ты фанат языка и разумные доводы для тебя пустой звук.
А нишу С++ гораздо правильней закрывать Растом.
И простота и надежность как то утомили, тк это — рекламный булшит, никак не связаный с реальностью.
Я думаю, что Арни, будучи губернатором, находил время для тренировок, то и ваше расписание позволит это сделать.
Друзья еще помогают не сидеть дома, плюс какие нибудь концерты, шоу, соревнования.
Можно собаку завести какого нить пита, которому надо выгуливаться много :)))
Про исполнение это дискуссионный вопрос. Потому что надо брать и сравнивать что то сложное. Как пример асинхронный драйвер из
vertxбыл самым быстрым. Или взять что из последнего и там в топе Го практически не встречается, а Джава да.И про разработку, вы тут не правы. На Джаве программы пишутся быстрее чем на Го. Взять например простой рест ендпоинт который ассинхронный и что то читает с базы и отдает потом жсон наружу. в Джаве со спрингом это будет буквально две строчки кода, в Го я думаю вам придется написать их гораздо больше.
Возможно, но думаю что дело в квалификации программиста.
И при одинаковой квалификации Го и Раст девелопера, последний будет продуктивней. Потому что ему не надо лепить какие то генераторы, а будут генерики. На каждый чих делать
if err != nilа использовать цепочку вызовов.А так же за Растом система типов а в Го будут
interface{}и дальше только молится что туда попадет что ожидается.Не, у меня код получается лучше писать чем текст :)))
Так что я лучше побуду критиком.
Вы не правы. Если вы делаете нормальные слои и взаимодействие то заменить какую то имплементацию будет относительно просто. Говорю из своего опыта когда приходилось мигрировать проекты с Монги или ДинамоДБ на Постгрес.
Сторонники Го не поймут эту шутку. Они действительно считают что так и надо писать.
Чистая архитектура это не мы как то разбили криво на слои. Не может быть в чистой архитектуре в слое который сохраняет юзера в базу какого то
TaskNotificationили же создание бизнес сущности
Userне может быть просто структура в которую можно накидать как угодно какие угодно данные.Те если бы статья называлась пример наших костылей, то я и слова бы не сказал. А так замахнулись на чистую, понимаете ли, нашу архитектуру. И в результате выкатили какую то поделку.
Меня интересовало ваше мнение, а не банальная отмазка.
Вы считаете, что на Джаве нельзя писать так же коряво и в лоб как и на Го?
Или можно пример когда решение на Джаве потребует больше времени на реализацию и будет сложнее в понимании чем решение на Го?
Те по вашему для прикладного программиста сделать в Джаве
@Mock MyInterface someVarгораздо сложнее чем на каждый чих перегенерировать моки в Го?Авторы лицемеры, потому что для
listиmapони почему то генерики сделали. Если они не нужны по их мнению, то покажите как надо без них писать.Те для вас вот такое поведение или такое это брюзжание?
Можете подобный зашквар показать в Джаве?
А какая концепция в Го? И можете показать пример кода который бы на Джаве был невыносимо сложнее/дольше писать/понимать.
Зачем брать какую то часть и описывая ее говорить, что все остальное тоже фигня. Там много чего по существу.
Ну вот смотрите запускаю я
go buildиgolintи никаких варнингов. Голанд зеленая тоже. Но вы продолжайте дальше утверждать, что проблем нет.Мы говорим об языках и насколько они позволяют избегать ошибок.
Я тоже видел и это лишь показывает, что вы умнее Го компилятора :)))
Согласен, но назовите по каким причинам мне надо взять и писать мой микросервис не на Джаве или Расте или Ноде/Тайпскрипт а на Го?
Я вижу Го как язык который нахватался каких то обрывочных идей но целостности нет.
Или вот мои вопросы
так же отличный комментарий
У меня и локально
go buildпроходит без всяких предупреждений.Так же вы говорили про ошибки компилятора, а теперь мы вдруг речь уже ведем о внешних линтерах. Которые не являются частью языка, не у всех установлены, по разному настроены, кидают простыню сообщений и на них забивают через некоторое время. Как пример разных настроек — в Goland никаких сообщений о том, что с кодом что-то не так, не показывается.
Вот смотрите мой пример в go playground
Мы успешно забыли про первую ошибку и работаем с
resкак ни в чем не бывало дальше.не будет он ругаться тк
errиспользуется ниже по коду вWriteFileНа мой взгляд тут вообще не пахнет чистой архитектурой.
Вы в репозиторий при создании юзера передаете какой то
TaskNotification— как это относится к созданию юзера в персистент слое???Функция
func (a *Application) CreateUserзачем то делает ещеLogin, как это узнать не глядя в код и самое главное зачем вы смешиваете разные действия в одно? Что вы будете делать когда создали юзера а логин по какой то причине упал?Почему
(*User, AuthToken, error)возвращает юзера по ссылке а остальные данные по значению? Так же вCreateUserв репозиторий вы этого юзера передаете по значению.У вас
Userпубличная структура и ничего не мешает взять ее и создавать с частичными полями. А по правильному архитектура не должна давать создавать невалидные объекты.Дальше устал писать и разбирать.
Начнет с того, что статья утверждает, что на все бросились переписывать с Питона на Го и распиливать свои монолиты на Го.
Свое видение я привел, почитайте мой предыдущий коментарий.
И где какие то ваши аргументы, от вас кроме демагогии ничего взамен нет. Моя позиция может быть правильной а может и нет. Если вы не согласны с ней то факты в студию, чтобы у нас была какая то дискуссия.
Потому что это про различные типы. Там не надо с зеро-кост получать откуда то байты и потом их передавать. А надо уметь выражать бизнес сущности и их отношения между собой. В Го мы можете написать к примеру умный и сложный билдер для вашего
User, но вы спокойно в методахUserAddressкоторый в том же пакете сидит будете иметь возможность создатьUserнапрямую с доступом ко всем приватным полям.Расскажите какие правильные парадигмы для написания бизнес логики в Го, что они столь отличаются от всех других языков.
причем здесь синтаксис, если я говорю что Го вам не может гарантировать ничего из выше-перечисленного и не дает каких либо других плюшек с помощью, которых вы будете писать бизнес логику быстро и легко.
И посмотрите на ваш ответ — в нем опять никакой конкретики в чем я не прав, а лишь отрицание фактов и
ничего вы не понимаетеВ Го у вас нет ни системы типов как в Хаскеле ни ООП с Генериками как в Джаве.
Поля у вас или доступные всем внутри пакета или вообще доступные всем. И сделать приватные поля/методы для вашего обьекта вы не можете.
Обработка ошибок кривая — мой комментарий к другой статье
Не туда отписал.
Изначально статья (и не только эта) утверждает что-то и не пытается доказать. Мне же доводы повторять в каждой подобной статье утомительно.
Хотите возьмем какое то утверждение из статьи и приведите ваши доводы.
Go отлично не подходит для написания бизнес логики, поэтому писать на нем корпоративные микросервисы можно либо из-под палки или ты фанат языка и разумные доводы для тебя пустой звук.
А нишу С++ гораздо правильней закрывать Растом.
И
простота и надежностькак то утомили, тк это — рекламный булшит, никак не связаный с реальностью.Ну я не знаю, что сказать. Вы сами выбрали как жить :)
Я думаю, что Арни, будучи губернатором, находил время для тренировок, то и ваше расписание позволит это сделать.
Друзья еще помогают не сидеть дома, плюс какие нибудь концерты, шоу, соревнования.
Можно собаку завести какого нить пита, которому надо выгуливаться много :)))