Что происходит с популярностью Go?

Вот это вот «всегда больше» - это откуда взялось?

Немного не понял? Если это мне вопрос то только из личного опыта.

Личный опыт - это демагогия. Сводится к фразам «зуб дам» или «мамой клянусь». Не верифицируем. Не формализуем. Значит, использовать нельзя.

zero values снижают площадь поверхности ошибки, в отличие от Java, где «всё есть класс» и, стало быть, «всё может null».

Nullable в языке есть, называется «указатель».

Я лично очень редко встречал NPE в Go. И когда встречал, это были тривиальные ошибки.

Значит, использовать нельзя.

Конечно нельзя, вы это как минимум расскажите работодателям что пишут в требованиях: опыт работы от 3х лет и т.д. вот они дураки то.

Могу вам сказать что можно 50 раз прочитать или увидеть но пока 1 раз сам не попробуешь это все чушь.

Вам знакомо понятие «снижение рисков»?

Вам знакомо понятие «снижение рисков»?

нет.

Жаль. Про работодателей вам пока ещё рановато рассуждать. Ваш пример про «опыт три года» - это снижение рисков. Пример «попробуй хотя бы один раз» тоже про это, хотя здесь ещё перекликается теория и практика, тоже вопрос на 300-400 сообщений.

Про работодателей вам пока ещё рановато рассуждать.

Это лишь ваше мнение, я например думаю что вам еще рано на ЛОРе писать. Представьте себе ваше отношение к моим словам и поймете мое отношение к вашим.

Ваш пример про «опыт три года» - это снижение рисков.

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

Хорошо, я не буду больше писать.

Ну в общем-то он прав насчёт уровня любителей в сравнении с опытом профессионалов в текущей ситуации. Этот пост показывает одну из причин такого положения дел. Для профессионалов уже довольно долгое время определяющим стремлением является забота об интересах работодателя, даже в ущерб интересам своим. Любители же подобным искажениям восприятия не подвержены.

Что касается снижения рисков. Если мы принимам необходимость снижения рисков работодателя, мы должны принять и необходимость снижения рисков работника. А это выливается в нулевой опыт(потому как получение опыта это вложение, которое вполне может не окупиться).

Я не знаю, что означает оговорка «в текущей ситуации», но именно она заставляет меня согласиться. Возможно вы и правы, что в некоторой присущей вам текущей ситуации всё сказано верно. У меня другая ситуация и я спорю.

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

что означает оговорка «в текущей ситуации»

Наше время, современность, последние лет 5-10. В нынешней ситуации хотел написать.

наличие пусть небольшого, но опыта во всех основных областях

Примерно эквивалентно нулевому опыту, на мой взгляд. По крайней мере с позиции «3 года опыта», причём чаще всего специфичного, не по основным областям.

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

Хорошо, хотелось бы понять, почему последние десять лет определяющим для профессионала является забота о стремлении работодателя?

Тут совсем всё просто. Набор критической массы приверженцев такого подхода. А далее схема распространения очевидна - работодатель всегда предпочтёт работника, который кроме выполнения работы будет ещё и крайне лоялен. А денег платить столько же(или даже меньше со временем).

Более интересен был бы вопрос «как оно зародилось и смогло закрепиться». Тут уже сложнее и причин может быть много: начиная с роста популярности софтостроения и заканчивая желанием работодателей нанимать дешевле. И конечно же, те статейки про «софт-скиллы» с хабра и не только. :)

А далее схема распространения очевидна - работодатель всегда предпочтёт работника, который кроме выполнения работы будет ещё и крайне лоялен. А денег платить столько же(или даже меньше со временем).

Не понял и где логика?

Если чел с опытом то он уже где то работал и линяет от туда (может выгнали/соглашение сторон) в погоне за лучшей зп.

В случае отсутствия опыта (я не про комп.) чел. идет на меньшую зп, которую не факт что поднимут. Учится без проблем за 3 месяца, причем главная специфика человека - трудоголик, честный, ответственный, порядочной - опытом ни как не измеришь.

То есть ситуацию, когда профессионал работает за интерес, любит и ценит свою работу, добивается признания среди коллег, вообще за любую дополнительную мотивацию кроме денег, вы не рассматриваете? И работают люди только в софто строении? Больше профессионалы нигде не используются?

Всё у вас получается очень просто, даже упрощенно.

Если чел с опытом то он уже где то работал и линяет от туда (может выгнали/соглашение сторон) в погоне за лучшей зп.

Далеко не всегда. Я так понимаю осознанный и добровольный переход с понижением зарплаты рассматривается только как действие чокнутого?

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

У любителей такого нет, и там по прежнему приоритетным является качество решения, а не «софт-скиллы». Что и выливается в

уровень (техническая грамотность) любителя-фаната всегда больше чем у профессионала

– такие дела.

То есть ситуацию, когда профессионал работает за интерес, любит и ценит свою работу, добивается признания среди коллег, вообще за любую дополнительную мотивацию кроме денег, вы не рассматриваете?

За интерес - это любитель, а не профессионал. Если удаётся совместить с профессиональной деятельностью - то это помесь любителя и профессионала, причём основная мотивация - «за интерес» - свойство любителя.

И работают люди только в софто строении? Больше профессионалы нигде не используются?

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

К тому же здесь нет никакой проблемы - в большинстве остальных областей всё то же самое с поправкой на доступность(кол-во любителей).

Рыночная экономика подразумевает, что люди свободно распоряжаются своим трудом и имуществом. Свободно, т.е. без принуждения. Ситуация, когда одна сторона переговоров обладает несоизмеримой силой (в том числе в результате гораздо лучшей информированности), в эту схему укладывается уже с трудом. Вот, вы говорили, все предпочитают быть здоровыми. А в чём разница между «комендант лагеря приказал поставить вакцину всем заключённым» и «благодаря лоббизму и рекламе биг фарма убедило всех сходить на укол»? Как по мне, вторая ситуация даже хуже, тело изнасиловали, да ещё и мозги промыли.

Вы бинарный робот? У вас существует только чёрное и белое?

В данном случае это абсолютно не важно. Ну, было бы вместо if err != nil какое-нибудь if isError(err). Всё равно в рамках философии Go здесь будет стоять явная обработка ошибки.

Ну, было бы вместо if err != nil какое-нибудь if isError(err). Всё равно в рамках философии Go здесь будет стоять явная обработка ошибки.

Позволю себе позанудствовать. Код вида:

if err != nil {
  return err
}

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

А вот этот вот повторение одинаковых строчек в Go-программах – это всего лишь диагностика наличия ошибки и информирование о ней. Но не обработка.

И с задачей диагностики наличия/прокидывания наверх в том же Rust справились гораздо лучше. А Go как выглядел в этом смысле убожеством из 1980-х, так и выглядит.

Вы бинарный робот? У вас существует только чёрное и белое?

Это по поводу моего ответа на «профессионал работает за интерес»? Нет, конечно, не робот. Просто я знаю, что такое определяющие/основные качества и их источник, а что такое качества побочные/второстепенные. И отделяю одно от другого, чтобы не допускать ложных причинно-следственных связей.

Вот как выше, например: «профессионал работает за интерес» + «интерес ставит заглавным приоритетом качество продукта» => «профессионал ставит заглавным приоритетом качество продукта»/«профессиональные отношения не основываются только на деньгах». Это ложные выводы.

Ну хорошо, вы абсолютно правы.

не является «обработкой» ошибок

Да, это проброс ошибки, а не обработка. Но возможно он имел ввиду «всё равно в рамках философии в go нет исключений»(и там будет в каждом месте либо if, либо макрос).

А в карты вы тоже передёргиваете?

И с задачей диагностики наличия/прокидывания наверх в том же Rust справились гораздо лучше. А Go как выглядел в этом смысле убожеством из 1980-х, так и выглядит.

Не справились в той же степени - это теперь называется «справились гораздо лучше»? Странная логика.

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

if err != nil это диагностика ошибочной ситуации. Чего с ней делать — решать вам. Главное, что количество WTF/loc будет минимизировано. Расплачиваться за это приходится большей многословностью. Таков путь.

это диагностика ошибочной ситуации

Тоже не совсем точно, но термин «обработка ошибок» в контексте языка как раз означает проброс ошибки/выделение отдельного пути исполнения в ошибочной ситуации. Поэтому тут я не спорю.

WTF/loc

А это уже неверно. Примерно как если бы не было гц: «гц в go нет для минимизации wtf/loc». :)

Таков путь.

Да, я написал об этом же чуть выше.

if err != nil это диагностика ошибочной ситуации.

Извините, я вот читаю про это, и ни как не могу врубиться, чему тут недоволен народ? Что не так то? Можете мне дураку объяснить?

0. Синдром утёнка. Не так, как они привыкли в их любимом $langName.

1. if err != nil нужно явно писать, а потом явно читать. Писанина утомляет.

2. А раз так, то можно же и зевнуть, забыть, забить и проворонить ошибку.

Синдром утёнка. Не так, как они привыкли в их любимом $langName.

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

Далеко не все, чем вынужденно пользовались диды, сохраняет свою актуальность до сих пор.

if err != nil нужно явно писать, а потом явно читать. Писанина утомляет.

И чтение исходников, 1/3 которых состоит из подобных тривиальных if-ов утомляет тоже.

if err != nil нужно явно писать, а потом явно читать.

ну так вроде компилятор должен ругнуться если это не заюзать.

А если забудут воткнуть какой нибудь try то прога свалится не во время компиляции а во время работы …

ну так вроде компилятор должен ругнуться если это не заюзать.

Если очень хочется, можно и накосячить. Но это ерунда, естественная. Фишка Го, которая очень мешает тем, кто на Го не пишет.

ну хз. В го же явные сравнения а не исключения и я хз зачем это делать снаружи.

package main

import (
        "errors"
	"fmt"
	"log"
)

func Sqrt(f float64) (float64) {
    if f < 0 {
	log.Fatal(errors.New("На ноль делить нельзя!"))
        return 0
    }
    return 2 // доделать после релиза!
}

func main() {
        r := Sqrt(4)
        fmt.Println("Sqrt of 4 is ", r)
        r2 := Sqrt(-1)
        fmt.Println("Sqrt of 4 is ", r2)
}

func Sqrt не знает откуда её вызывали, каков контекст происходящего и что вообще делать, как исправлять ошибочную ситуацию. Вот, вы log.Fatal вызвали. А почему? Может это и не фатальная ошибка. А может пора паниковать. Или повторить попытку (вдруг повезёт). Это только внешний код знает.

P.S. И это только в лиспе реализовано правильно, код обработки ошибки позволяет размотать поток исполнения обратно и продолжить с ошибочного места.

нельзя назвать директории русскими буквами,

можно, go поддерживает юникод, но по моим прикидкам 99.9% российских программистов против русского языка в программировании

поэтому свой проект перенёс на TS

если проект разрастется, то эта тормозная скриптота боком выйдет

И чтение исходников, 1/3 которых состоит из подобных тривиальных if-ов утомляет тоже.

в ide можно сделать автоматическое сворачивание этих блоков кода в одну строку или в указанный символ, а также хоткей повесить на свернуть/развернуть

а при написании своего кода вынести проверку ошибок в отдельную функцию типа

func CheckErrors(err error) {
    if err != nil {
        ..do some..
    }
}

компилятор ее потом заинлайнит

я тут решил ИИ поэтому поводу запытать, в начале он мне писал то что вы писали, потом через 5 минут (когда я ему вилку сделал - чтобы выбирал из 2х своих противоположных примеров он мне выдал)

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

Так что по сути где обрабатывается ошибка это вещь чисто индивидуальная.

Если б я захотел поговоирть с чат-гопотой, зачем бы мне ваше посредничество?

Если б я захотел поговоирть с чат-гопотой, зачем бы мне ваше посредничество?

Я про то что это вещь чисто индивидуальная, и где будет обработка этой переменной (внутри или снаружи) сильно зависит от очень многих факторов. И в конкретном примере что дали ВЫ, это лучше запихать внутрь.

Конкретно этот пример иллюстрировал как можно пропустить обработку err. Никакого иного смысла в него не вкладывалось.

> Код вида: . . . return err . . . не является «обработкой» ошибок

Является. Если есть уверенность, что в err уже содержится вся полезная информация, её не обязательно лишний раз оборачивать. Например, http.Get [1] вполне информативен.

Во-вторых, обработка вида “return err” встречается в реальном исходном коде намного реже, чем людям кажется.

> Обработка – это когда предпринимаются какие-то осознанные действия для преодоления последствий ошибки

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

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

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

В Go хорошей практикой является сообщить что пошло не так, через fmt.Errorf. А достоинством самого языка является тот факт, что он не даёт программисту возможность отложить должную обработку ошибок на потом. Грош цена обработке ошибок, если пользователь не видит ничего, кроме “no such file or directory.”

> Когда такое пишешь в 1989-ом, то какбы ОК. . . . Но когда прошло столько времени и люди перепробовали разного и понапридумывали разного, то ожидаешь чего-то более современного.

Во-первых, нужно учитывать контекст. Лучше ли современное старого *для Go*? Этот язык должен быть маленьким, простым для понимания и без дублирующих функций. Sum types не привнесут достаточно выгоды, чтобы оправдать усложнение.

Кроме того, важно соблюдать принципы. Если бы мы включили в язык sum types из-за давления популярности или современности, а не из-за выгоды, то зачем останавливаться? Добавим что-нибудь из C++, что-нибудь из D, что-нибудь из Haskell и что угодно, что попало в тренды текущего года. У нас и так много современных языков, которые выбирают данный путь. Ещё один язык был бы лишним.

Во-вторых, опыт прошлого нельзя отбрасывать, не осознав его должным образом. В чём проблема 1989 года? Исключения возникли примерно в это время и ничего, люди до сих пор ими пользуются и не плюются. Определённые идеи того времени ещё до сих пор не были всерьёз испробованы, даже близко.

[1]: https://pkg.go.dev/net/http@go1.26.5#Get

можно, go поддерживает юникод

В именах директорий нельзя, что-то ломается в сборке. Мне неважно, что там против 99.9% программистов, у меня свои личные проекты.

если проект разрастется, то эта тормозная скриптота боком выйдет

Тогда можно будет нейросетями переписать

> И чтение исходников, 1/3 которых состоит из подобных тривиальных if-ов утомляет тоже.

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

Я не хочу сказать “X хуже, значит Y не имеет проблем.” Просто дополнительный факт, чтобы измерить «усталость» на основе сравнения.

Что можно сказать точно про обработку ошибок в Go: она занимает пространство и это замедляет чтение алгоритма (сложнее разглядеть лес среди деревьев). Утомление — не так однозначно. По личному опыту, это не та вещь, которая постоянно лезет под руку.

Весь код выглядит однородно, поэтому блоки с обработкой ошибок не дают никакого сигнала «посмотри на меня, я здесь». Более того, блок из 4 строк и одна пустая линия визуально создают единицы, которые крупнее одной строки и поэтому проще для навигации. Легче найти после случайного скроллинга или изменения границ окна.

Является.

Да я давно подозревал, что выбор в пользу Go – это диагноз. А выступления адептов Go в этой теме лишь больше в этом убеждают.

Во-вторых, обработка вида “return err” встречается в реальном исходном коде намного реже, чем людям кажется.

Просто оставлю это здесь: https://github.com/search?q=repo%3Adocker%2Fcompose+%22return+err%22&type=code Результаты поиска return err в исходниках компонента composer из проекта Docker. Это ж, вроде как, одна из икон того, что сделано на Go.

У вас довольно впечатляющий опыт и способность к дискуссиям. Этого более чем достаточно, оскорбления не нужны.

В именах директорий нельзя, что-то ломается в сборке. Мне неважно, что там против 99.9% программистов, у меня свои личные проекты.

А можно пример (кроме вас) где еще диры сырцов на русском? Интересно даже. Кстати я слылшал в 1с операторы на русском, вот крутой язык то ;)

Тогда можно будет нейросетями переписать

Какими еще сетями? Скриптом можно все названия каталогов переименовать в латиницу и весь код что в тексте, да поди какой нибудь ИДЕ это сам сделает, типа рефакторинг.