Во-первых, браузер к одному домену может делать только примерно 8 параллельных запросов, остальные будут в очереди. Если у вас много мелких картинок, которые не склеены в одну большую по той или иной причине, они могут забить канал (например, много превьюшек продуктов), то CDN может помочь освободить канал для загрузки других данных .
Типично CDN — предоставляет конкретному пользователю один свой конкретный сервер, пусть даже в сети CDN серверов тысяча.
Ну будет у вас вместо 8 потоков этих потоков 16. Вы что же скажите, что разработчик криворукий не сможет эти потоки перенагрузить? Смог 8, и сможет 16.
Правильная оптимизация ваших HTML/CSS/JS даст лучший эффект.
Ну и ещё многие CDN оптимизируют изображения на лету, в том числе могут автоматом генерировать превьюшки. Да, это делается простыми плагинами для nginx, но опять же, это отъедает ресурсы, которые можно потратить с большей пользой.
Это вообще для кого? Для совсем неграмотных? Для совсем ленивых?
Сжатие/превьюшки реализуется в современных веб-системах с полпинка.
Где-то нужно всего то галку включить, где то десяток строк кода написать. И — вуаля — после первого получения пользователем картинки она уже сжата и в дальнейшем отдается из подготовленной превьюшки/из предварительно сжатых закэшированных, не отнимая ресурсов.
Причем, что важно, что эти превьюшки и закэшированные сжатые картинки вы контролируйте сами. Обновилась картинка оригинала — и обновление кэша/превьюшки будет мгновенным.
Ну и для международных компаний может быть польза в том, что контент физически хранится ближе к пользователю, от чего меньшие задержки.
А какой смысл быстро отдавать картинки, если сам ваш сайт при этом тормозит у удаленного пользователя.
То о чем вы пишете имеет смысл только для тяжелого контента.
Если вы специализируетесь на видеохостинге — тогда да, безусловно, CDN нужен.
9-й пункт — притянуто за уши. Автор использует пример с append, которая при необходимости сама распределяет новую память. Если бы он использовал пример A[10] = «нельзя», то было бы всё логично
Но вставка нового элемента в мапу и так выделяет память, так что нифига не логично.
Разумеется распределяет. Но неявно.
Согласно концепциям Go всё по возможности должно быть явным.
Минимум магии.
8-й пункт — ээээ… А что вы вообще ожидали увидеть в языке со статической типизацией?
В языке со статической типизацией я бы хотел видеть вывод типов.
Оно работает в Go, если написать вот так:
a:= 5
или так
a:= «Привет»
В концепциях Go приветствуется явность.
Конечно это все, что вы ожидаете, — можно сделать.
Но тогда это будет другой язык.
Где концепции «явности» уже не столь чисты.
Чтобы что-то начало меняться в лучшую сторону, требуется смена режима с авторитарного на демократический.
Отнюдь не гарантирует.
Ну вот мы же наблюдаем как часто сменяется оппозиция-власть в Украине. Уже десятилетиями.
И что? Одни олигархи у других отжимают заводы-газеты-параходы-банки-нефтянную трубу. Простым людям с этого чего?
В то же время, если посмотреть историю Южной Кореи с её диктатором. Тот экономически рост, рост благосостояния давно и устойчиво идет еще с глубоких авторитатрно-диктаторских времен. Вплоть до гегемонии корейских фирм в мире в некоторых сферах.
Нет прямой связи «демократия — хорошо живем, а авторитарный режим — плохо живем».
Для той оппозиции что рвется во власть — да, разница есть.
Для простых людей — наличие того или иного режима никаких гарантий не дает.
Вы считаете, что на Джаве нельзя писать так же коряво и в лоб как и на Го?
Или можно пример когда решение на Джаве потребует больше времени на реализацию и будет сложнее в понимании чем решение на Го?
Вам известна история создания Java?
Там была идея — что нужно разработчика обложить со всех сторон жесткими ограничениями языка. И тогда он, мол, косячить станет меньше.
Затем мир шарахнулся в противоположенную сторону. «Программиста не нужно ограничивать. Тогда у него выше производительность». И мы наблюдали всплеск использования динамических языков.
Но по мере усложнения проектов понадобилось всё же добавить больше контроля в язык программирования.
И когда позже создавали Go, использовалась противоположенная концепция нежели у Java и динамических языков — язык должен быть со статическими типами, но при этом язык не должен быть таким многословным как Java, что нашему мозгу проще работать с облегченными концепция, это позволяет больше ресурсов мозга выделить не на борьбу с языком, а на решение собственно прикладной задачи, ради чего программиста и нанимают. И в эту концепцию прекрасно вписывается и выведение типов и сборщик мусора.
Rust в свою очередь создан для решения вполне конкретной задачи Mozilla и подобных задач. Для крупных ответственных проектов нуждающихся в надежности и производительности.
И как следствие имеем, что в Rust программисту нужно детально прописывать коде свою хотелку. Что существенно увеличивает стоимость (и сроки) реализации проектов.
Если вы одинаково хорошо знаете все эти языки и хорошо представляете что за проект вы будете делать следующим — то, в зависимости от проекта, вы можете выбрать индивидуально под проект идеально подходящий под него язык — Java, Python, Go или Rust.
На практике, разумеется, это невозможно. У нас есть предпочтения, любопытство в изучении нового или напротив желание расслаблено работать по накатанной технологии. Кроме нас над проектом (если он сколько-нибудь крупный) работают куча других людей, которые обладают другими знаниями языков.
Поэтому объективный выбор языка программирования лучше подходящий под тот или иной проект — невозможен. Но это не означает, что к этому не нужно стремиться.
Коммерческую разработку писать нужно на том, что лично вы лучше знаете.
Меня интересовало ваше мнение, а не банальная отмазка.
То что мой ответ вам не нравится, вовсе не означает, что я вам не ответил.
Как человек с опытом в 25 лет я отлично знаю как много факторов влияют на выбор инструмента.
И самый главный из них на сегодня — наличие свободных рук квалифицированных разработчиков, доступных для привлечения к работе над проектом.
Если рассматривать какой-то реальный проект, то, возможно, какое значение для каких то отдельных кусков вашего гипотетического проекта будет иметь производительность и тогда скриптовые языки нежелательны. Но рассуждать об этом не зная никакой конкретики проекта не могу.
В подавляющем большинстве случаев проблема производительности связана не столько с языком программирования, сколько с квалификацией программистов. Ибо такие вещи как работа с сетью или с БД от языка уже не зависит. А эти вещи будут серьезно влиять на производительность всей системы. Тем более микросервисной, где внутренняя сеть сжирает прилично производительности.
Мой ответ не изменился: если мы не знаем о проекте ничего конкретного, то лучше всего писать на том, что разработчики лучше всего знают.
Да, возможно, в каком-то конкретном случае был бы целесообразнее TypeScript (один и те же разработчики бэкенда и фронтенда) или Erlang (хитрая многопоточность, работа системы без необходимости перезагрузки при обновлениях) или Java (обновления версий без перезагрузки системы) и пр. и пр.
Но без знания что там именно у вас за проект — ничего более точного сказать нельзя.
Однако полный разбор этой статьи — потратить кучу времени.
Я сразу отметил низкий уровень знакомства автора с языком.
Разбирать его брюзжание — стоит ли?
У автора выпирает то, что он ожидает увидеть другой язык.
Первые 3 пункта — достоинства языка, идущие в глазах автора как недостатки
4-й пункт — чисто вкусовщина, реально нейтральная вещь. Просто ему не нравится.
5-й пункт — автор говорит о неудобстве, но при этом не замечает реальной проблемы (о которой вы упомянули). Я бы не принимал всерьез слова человека с таким уровнем незнания языка как у него.
6-й пункт — вкусовщина, нейтральная вещь, но ему не нравится.
7-й пункт — вкусовщина. Кто то скажет что это плохо. Кто то скажет, что удобно, что можно одноименную переменную использовать.
8-й пункт — ээээ… А что вы вообще ожидали увидеть в языке со статической типизацией?
9-й пункт — притянуто за уши. Автор использует пример с append, которая при необходимости сама распределяет новую память. Если бы он использовал пример A[10] = «нельзя», то было бы всё логично
На этом я устал разбирать его ворчание.
В первых 9 пунктах — только пункт номер 7 по делу. Да и то это вкусовщина. Можно засчитать за 0,5 проблемы языка.
Косяк языка что можно было бы заметить в пункте 5 автор статьи не заметил.
0,5 найденных автором проблем в 9 первых пунктах?
И 3 достоинства языка, преподносимые как его недостатки в этих же 9 пунктах?
Как после этого можно серьезно воспринимать этого автора и эту статью?
Конечно, косяки в языке есть, как и в других языках. Се ля ви.
Но статья больше кликбейтная, чем по делу. Львиная доля претензий — высосана автором из пальца.
а вот PS к FreeBSD привязаны не сильно и вполне могут «перекочевать» и на Linux.
Зачем?
Кроме проблемы драйверов — веских причин перехода на Linux нет.
Железо там отборное под PS сделанное, с драйверами проблем нет.
Кроме того, на рынке могут появиться новые игроки
Не могут. Это дико дорого такой проект провернуть.
Тут же нужно целую инфраструктуру создавать.
Плюс сейчас мобильные игры еще больше задавили этот рынок, чем было ранее.
За десятилетия существования консолей — число тех, кто смог, можно перечислить по пальцам одной руки.
Вы считаете высокой вероятность появления нового игрока просто потому что вам хочется? Или какие-то объективные соображения?
В подобных многомиллиардных проектах развитие сдерживает уж точно не ядро ОС.
Кстати и теснящий консоли Андроид — там ключевой момент вовсе не в ядре ОС.
Оппозиция — это противопоставление текущей власти. Противовес Это люди и движения, которые хотят чтоб текущая власть не хамела.
А по моему он тупо хотят во власть.
Спят и видят себя там.
И будут они ровно такими же.
Ну понятно, что какие-то нюансы в государстве поменяются, но так чтобы всё диаметрально поменялось — это невозможно. Можно как Жириновский обещать каждому по бабе или по миллиону долларов, но физически это заявление выполнить невозможно. Мешают объективные законы мироздания.
Имею ввиду: каков бэкграунд, как сейчас принято говорить.
Работали до этого в какой сфере?
Ну например, работали в геймдеве на дядю — решили попробовать на себя.
Работали не в геймдеве и даже не в ИТ — решили попробовать.
Работали в разработке ПО в других сферах, не в геймдеве.
Ну вот смотрите запускаю я go build и golint и никаких варнингов. Голанд зеленая тоже. Но вы продолжайте дальше утверждать, что проблем нет.
Для Go существует множество линтеров (golint, vet, errcheck, deadcode, пр.)
Но проще использовать стандарт де-факто для линтеров Go, их все объединяющий в одну утилиту, запускающую множество линтеров параллельно: golangci-lint.run
Согласен, но назовите по каким причинам мне надо взять и писать мой микросервис не на Джаве или Расте или Ноде/Тайпскрипт а на Го?
Коммерческую разработку писать нужно на том, что лично вы лучше знаете.
Я вижу Го как язык который нахватался каких то обрывочных идей но целостности нет.
Я вижу Го как язык из которого создатели осознанно выкинули кучу заведомо известных им концепций, применяемых в других языках. Решив, что усложнения ни к чему.
Пример: усложненная Ява, монстр С++ vs упрощенный Go.
Строго говоря, зачем бы создавать Go, если оставить его таким же переусложненным как Java/C++? В чем бы тогда был смысл очередного языка?
Может показаться, что отказ от каких то концепций — это шаг назад. Что нужно только добавлять и добавлять… Но человечество проходило переусложнение еще и до С++ и до Java.
Так кучу концепций впихнули в PL/I, разработанный в середине 1960-х. И для него так и не было создано ни одного компилятора, реализующего все концепции языка.
На Хабре был перевод интервью с разработчиками. Может, кто вспомнит и ссылку приведет.
Там и про генерики подробно с доводами написано почему именно они их не стали вставлять в версию Go1 (но уже будет в Go2).
В частности, в том интервью рассматриваются особенности генериков Java/C++/C#. У каждого — свои особенности, свои недостатки и свои достоинства. У всех этих языков сильно разные концепции генериков и ни одна авторов Go на тот момент полностью не устраивала. Там и объясняется почему именно авторам языка не хотелось бы видеть их в таком виде в Go.
В самом начале статьи по приведенной вами ссылке очень хорошо написано:
Go — простой и забавный язык. Но в нём, как и в любых других языках, есть свои подводные камни. И во многих из них сам Go не виноват. Одни — это естественное следствие прихода программистов из других языков, другие возникают из-за ложных представлений и нехватки подробностей
Да, действительно, это типичная ошибка, когда программисты, привыкшие к одному языку концепции из того языка пытаются притянуть за уши в другой язык.
Иногда это получается нормально. А иногда нет.
Ведь зачастую языки создаются вовсе не потому чтоб просто вместо «BEGIN END» использовать "{}". А именно для реализации несколько иных концепций.
Поэтому не все паттерны/рецепты из вашего прежнего языка хороши для использования их в вашем новом языке.
Если пробежаться по «проблемам» Go, озвучанными в статье по приведенной вами ссылке, то первые 3 пункта критикуют как раз именно достоинства Go, что компилятор препятствует замусориванию кода, что компилятор и go fmt заставляют следовать тому, для чего в других языках создаются внешние утилиты и пишутся портянки code styles.
У каждого языка есть свои особенности (иначе какой смысл в другом языке). Приведенная статья большей частью просто ворчание человека, который еще не привык к языку.
Я за свою 25-летнюю карьеру программиста освоил порядка 15 языков программирования. И концепции Go не вызвали у меня отторжения.
У меня и локально go build проходит без всяких предупреждений.
Так же вы говорили про ошибки компилятора, а теперь мы вдруг речь уже ведем о внешних линтерах.
Есть еще разная квалификация программистов.
Например, я и без линтеров сразу видел косяк в вашем коде.
Линтер включил только чтобы было формальное сообщение об ошибке, которое можно процитировать.
Что из того? Программисты разной квалификации существуют. Это объективно.
Как пример разных настроек — в Goland никаких сообщений о том, что с кодом что-то не так, не показывается.
У каждого языка свои проблемы.
У Раста — другие.
И что из того?
Линтеры существуют. Они осуществляют кучу полезных проверок.
Глупо их не использовать, если вашей квалификации недостаточно, чтобы наметанным опытным взглядом сразу выявить косяки в коде.
На современном железе это бесплатно, синтаксический разбор кода Go делается быстро.
не будет он ругаться тк err используется ниже по коду в WriteFile
Хоть и до этого мне было известно, что компилятор Go умный, но на всякий случай
прежде чем написать свой ответ — я попытался скомпилировать этот кусок кода.
Ошибка компилятора, которая процитирована — именно с этой проверки.
Тем самым Го позволяет вам забить/забыть на обработку ошибок и программа что то будет дальше выполнять.
Сругается компилятор, если вы использовали возвращаемые значения, но проигнорировали возвращаемую ошибку. Вы должны явно указать, что игнорируете ошибку, использовав "_", пример:
retValue, _:= funcName(param)
вместо:
retValue, err:= funcName(param)
То есть если программист явно отказался рассматривать ошибку, то ему виднее. Может там несущественная ошибка.
Типично CDN — предоставляет конкретному пользователю один свой конкретный сервер, пусть даже в сети CDN серверов тысяча.
Ну будет у вас вместо 8 потоков этих потоков 16. Вы что же скажите, что разработчик криворукий не сможет эти потоки перенагрузить? Смог 8, и сможет 16.
Правильная оптимизация ваших HTML/CSS/JS даст лучший эффект.
Это вообще для кого? Для совсем неграмотных? Для совсем ленивых?
Сжатие/превьюшки реализуется в современных веб-системах с полпинка.
Где-то нужно всего то галку включить, где то десяток строк кода написать. И — вуаля — после первого получения пользователем картинки она уже сжата и в дальнейшем отдается из подготовленной превьюшки/из предварительно сжатых закэшированных, не отнимая ресурсов.
Причем, что важно, что эти превьюшки и закэшированные сжатые картинки вы контролируйте сами. Обновилась картинка оригинала — и обновление кэша/превьюшки будет мгновенным.
А какой смысл быстро отдавать картинки, если сам ваш сайт при этом тормозит у удаленного пользователя.
То о чем вы пишете имеет смысл только для тяжелого контента.
Если вы специализируетесь на видеохостинге — тогда да, безусловно, CDN нужен.
Это странно.
Если игра сетевая, то можно просто дублировать логику игры на сервере.
И чит там есть в клиенте или нет — вас не волнует.
Разумеется распределяет. Но неявно.
Согласно концепциям Go всё по возможности должно быть явным.
Минимум магии.
Оно работает в Go, если написать вот так:
a:= 5
или так
a:= «Привет»
В концепциях Go приветствуется явность.
Конечно это все, что вы ожидаете, — можно сделать.
Но тогда это будет другой язык.
Где концепции «явности» уже не столь чисты.
Отнюдь не гарантирует.
Ну вот мы же наблюдаем как часто сменяется оппозиция-власть в Украине. Уже десятилетиями.
И что? Одни олигархи у других отжимают заводы-газеты-параходы-банки-нефтянную трубу. Простым людям с этого чего?
В то же время, если посмотреть историю Южной Кореи с её диктатором. Тот экономически рост, рост благосостояния давно и устойчиво идет еще с глубоких авторитатрно-диктаторских времен. Вплоть до гегемонии корейских фирм в мире в некоторых сферах.
Нет прямой связи «демократия — хорошо живем, а авторитарный режим — плохо живем».
Для той оппозиции что рвется во власть — да, разница есть.
Для простых людей — наличие того или иного режима никаких гарантий не дает.
Жириновский за много-много лет попал «возле власти», а «не во власть».
Верное замечание — подавляющее большинство современных языков программирования являются вариациями Алгола.
Кроме SQL (HTML — не язык программирования). Ну и кроме Хаскеля.
А все эти C, C#, Go, Rust, Java, Python и пр. — по сути вариации Алгола, да.
Вам известна история создания Java?
Там была идея — что нужно разработчика обложить со всех сторон жесткими ограничениями языка. И тогда он, мол, косячить станет меньше.
Затем мир шарахнулся в противоположенную сторону. «Программиста не нужно ограничивать. Тогда у него выше производительность». И мы наблюдали всплеск использования динамических языков.
Но по мере усложнения проектов понадобилось всё же добавить больше контроля в язык программирования.
И когда позже создавали Go, использовалась противоположенная концепция нежели у Java и динамических языков — язык должен быть со статическими типами, но при этом язык не должен быть таким многословным как Java, что нашему мозгу проще работать с облегченными концепция, это позволяет больше ресурсов мозга выделить не на борьбу с языком, а на решение собственно прикладной задачи, ради чего программиста и нанимают. И в эту концепцию прекрасно вписывается и выведение типов и сборщик мусора.
Rust в свою очередь создан для решения вполне конкретной задачи Mozilla и подобных задач. Для крупных ответственных проектов нуждающихся в надежности и производительности.
И как следствие имеем, что в Rust программисту нужно детально прописывать коде свою хотелку. Что существенно увеличивает стоимость (и сроки) реализации проектов.
Если вы одинаково хорошо знаете все эти языки и хорошо представляете что за проект вы будете делать следующим — то, в зависимости от проекта, вы можете выбрать индивидуально под проект идеально подходящий под него язык — Java, Python, Go или Rust.
На практике, разумеется, это невозможно. У нас есть предпочтения, любопытство в изучении нового или напротив желание расслаблено работать по накатанной технологии. Кроме нас над проектом (если он сколько-нибудь крупный) работают куча других людей, которые обладают другими знаниями языков.
Поэтому объективный выбор языка программирования лучше подходящий под тот или иной проект — невозможен. Но это не означает, что к этому не нужно стремиться.
То что мой ответ вам не нравится, вовсе не означает, что я вам не ответил.
Как человек с опытом в 25 лет я отлично знаю как много факторов влияют на выбор инструмента.
И самый главный из них на сегодня — наличие свободных рук квалифицированных разработчиков, доступных для привлечения к работе над проектом.
Если рассматривать какой-то реальный проект, то, возможно, какое значение для каких то отдельных кусков вашего гипотетического проекта будет иметь производительность и тогда скриптовые языки нежелательны. Но рассуждать об этом не зная никакой конкретики проекта не могу.
В подавляющем большинстве случаев проблема производительности связана не столько с языком программирования, сколько с квалификацией программистов. Ибо такие вещи как работа с сетью или с БД от языка уже не зависит. А эти вещи будут серьезно влиять на производительность всей системы. Тем более микросервисной, где внутренняя сеть сжирает прилично производительности.
Мой ответ не изменился: если мы не знаем о проекте ничего конкретного, то лучше всего писать на том, что разработчики лучше всего знают.
Да, возможно, в каком-то конкретном случае был бы целесообразнее TypeScript (один и те же разработчики бэкенда и фронтенда) или Erlang (хитрая многопоточность, работа системы без необходимости перезагрузки при обновлениях) или Java (обновления версий без перезагрузки системы) и пр. и пр.
Но без знания что там именно у вас за проект — ничего более точного сказать нельзя.
Однако полный разбор этой статьи — потратить кучу времени.
Я сразу отметил низкий уровень знакомства автора с языком.
Разбирать его брюзжание — стоит ли?
У автора выпирает то, что он ожидает увидеть другой язык.
Первые 3 пункта — достоинства языка, идущие в глазах автора как недостатки
4-й пункт — чисто вкусовщина, реально нейтральная вещь. Просто ему не нравится.
5-й пункт — автор говорит о неудобстве, но при этом не замечает реальной проблемы (о которой вы упомянули). Я бы не принимал всерьез слова человека с таким уровнем незнания языка как у него.
6-й пункт — вкусовщина, нейтральная вещь, но ему не нравится.
7-й пункт — вкусовщина. Кто то скажет что это плохо. Кто то скажет, что удобно, что можно одноименную переменную использовать.
8-й пункт — ээээ… А что вы вообще ожидали увидеть в языке со статической типизацией?
9-й пункт — притянуто за уши. Автор использует пример с append, которая при необходимости сама распределяет новую память. Если бы он использовал пример A[10] = «нельзя», то было бы всё логично
На этом я устал разбирать его ворчание.
В первых 9 пунктах — только пункт номер 7 по делу. Да и то это вкусовщина. Можно засчитать за 0,5 проблемы языка.
Косяк языка что можно было бы заметить в пункте 5 автор статьи не заметил.
0,5 найденных автором проблем в 9 первых пунктах?
И 3 достоинства языка, преподносимые как его недостатки в этих же 9 пунктах?
Как после этого можно серьезно воспринимать этого автора и эту статью?
Конечно, косяки в языке есть, как и в других языках. Се ля ви.
Но статья больше кликбейтная, чем по делу. Львиная доля претензий — высосана автором из пальца.
Заинтересовался что за игра. И в Википедии нашел:
Писец.
Игра про средневековую Чехию. Какие там могут быть негры и азиаты?
Зачем?
Кроме проблемы драйверов — веских причин перехода на Linux нет.
Железо там отборное под PS сделанное, с драйверами проблем нет.
Не могут. Это дико дорого такой проект провернуть.
Тут же нужно целую инфраструктуру создавать.
Плюс сейчас мобильные игры еще больше задавили этот рынок, чем было ранее.
За десятилетия существования консолей — число тех, кто смог, можно перечислить по пальцам одной руки.
Вы считаете высокой вероятность появления нового игрока просто потому что вам хочется? Или какие-то объективные соображения?
В подобных многомиллиардных проектах развитие сдерживает уж точно не ядро ОС.
Кстати и теснящий консоли Андроид — там ключевой момент вовсе не в ядре ОС.
А по моему он тупо хотят во власть.
Спят и видят себя там.
И будут они ровно такими же.
Ну понятно, что какие-то нюансы в государстве поменяются, но так чтобы всё диаметрально поменялось — это невозможно. Можно как Жириновский обещать каждому по бабе или по миллиону долларов, но физически это заявление выполнить невозможно. Мешают объективные законы мироздания.
Имею ввиду: каков бэкграунд, как сейчас принято говорить.
Работали до этого в какой сфере?
Ну например, работали в геймдеве на дядю — решили попробовать на себя.
Работали не в геймдеве и даже не в ИТ — решили попробовать.
Работали в разработке ПО в других сферах, не в геймдеве.
Или т.п.
Студенты?
Там больше ворчание, которое мы издаем при изучении всего нового.
Скажем, первые 3 пункта подряд — чисто достоинства языка, выставляемые как недостаток.
Там пишется, что компилятор Go ограничивает мусор в коде и требует определенного форматирования.
Для чего для других языков создаются code styles и утилиты их проверящие (в Go же своя встроенная go fmt и ограничения компилятора на мусорный код)
Для Go существует множество линтеров (golint, vet, errcheck, deadcode, пр.)
Но проще использовать стандарт де-факто для линтеров Go, их все объединяющий в одну утилиту, запускающую множество линтеров параллельно:
golangci-lint.run
Коммерческую разработку писать нужно на том, что лично вы лучше знаете.
Я вижу Го как язык из которого создатели осознанно выкинули кучу заведомо известных им концепций, применяемых в других языках. Решив, что усложнения ни к чему.
Пример: усложненная Ява, монстр С++ vs упрощенный Go.
Строго говоря, зачем бы создавать Go, если оставить его таким же переусложненным как Java/C++? В чем бы тогда был смысл очередного языка?
Может показаться, что отказ от каких то концепций — это шаг назад. Что нужно только добавлять и добавлять… Но человечество проходило переусложнение еще и до С++ и до Java.
Так кучу концепций впихнули в PL/I, разработанный в середине 1960-х. И для него так и не было создано ни одного компилятора, реализующего все концепции языка.
Это к разработчикам языка.
На Хабре был перевод интервью с разработчиками. Может, кто вспомнит и ссылку приведет.
Там и про генерики подробно с доводами написано почему именно они их не стали вставлять в версию Go1 (но уже будет в Go2).
В частности, в том интервью рассматриваются особенности генериков Java/C++/C#. У каждого — свои особенности, свои недостатки и свои достоинства. У всех этих языков сильно разные концепции генериков и ни одна авторов Go на тот момент полностью не устраивала. Там и объясняется почему именно авторам языка не хотелось бы видеть их в таком виде в Go.
В самом начале статьи по приведенной вами ссылке очень хорошо написано:
Да, действительно, это типичная ошибка, когда программисты, привыкшие к одному языку концепции из того языка пытаются притянуть за уши в другой язык.
Иногда это получается нормально. А иногда нет.
Ведь зачастую языки создаются вовсе не потому чтоб просто вместо «BEGIN END» использовать "{}". А именно для реализации несколько иных концепций.
Поэтому не все паттерны/рецепты из вашего прежнего языка хороши для использования их в вашем новом языке.
Если пробежаться по «проблемам» Go, озвучанными в статье по приведенной вами ссылке, то первые 3 пункта критикуют как раз именно достоинства Go, что компилятор препятствует замусориванию кода, что компилятор и go fmt заставляют следовать тому, для чего в других языках создаются внешние утилиты и пишутся портянки code styles.
У каждого языка есть свои особенности (иначе какой смысл в другом языке). Приведенная статья большей частью просто ворчание человека, который еще не привык к языку.
Я за свою 25-летнюю карьеру программиста освоил порядка 15 языков программирования. И концепции Go не вызвали у меня отторжения.
Есть еще разная квалификация программистов.
Например, я и без линтеров сразу видел косяк в вашем коде.
Линтер включил только чтобы было формальное сообщение об ошибке, которое можно процитировать.
Что из того? Программисты разной квалификации существуют. Это объективно.
У каждого языка свои проблемы.
У Раста — другие.
И что из того?
Линтеры существуют. Они осуществляют кучу полезных проверок.
Глупо их не использовать, если вашей квалификации недостаточно, чтобы наметанным опытным взглядом сразу выявить косяки в коде.
На современном железе это бесплатно, синтаксический разбор кода Go делается быстро.
У меня линтеры включены и ваш код выдает такое:
main.go:9:7: ineffectual assignment to `err` (ineffassign)res, err := getInt()
^
main.go:10:2: ineffectual assignment to `res` (ineffassign)
res++
^
main.go:15:2: ineffectual assignment to `res2` (ineffassign)
res2++
^
Хоть и до этого мне было известно, что компилятор Go умный, но на всякий случай
прежде чем написать свой ответ — я попытался скомпилировать этот кусок кода.
Ошибка компилятора, которая процитирована — именно с этой проверки.
Сругается компилятор, если вы использовали возвращаемые значения, но проигнорировали возвращаемую ошибку. Вы должны явно указать, что игнорируете ошибку, использовав "_", пример:
вместо:
То есть если программист явно отказался рассматривать ошибку, то ему виднее. Может там несущественная ошибка.
Потому что ваш пример не скомпилируется, а компилятор сругается на эту строчку
такими словами: «err declared but not used»