почему голанг - это кул

А что гугл? В их ключевых продуктах голангом и не пахнет. Они его используют в инфраструктуре, где раньше на ура справлялся питон. Докер это не большой проект ни разу, даже на средний с натяжкой. Типичная утилита, для чего голанг и подходит лучше всего.

На основании чего ты пытаешься судить о моей квалификации и в какой конкретно области? Даже интересно.

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

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

Я думал ты про масштаб и важность.

Не очень понимаю, что именно мешает фигачить на Go проекты с большим объёмом кодовой базы. Поделишься соображениями?

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

То же самое с проверкой ошибок в го, и даже хуже. Вот такой код db.Exec("DELTE FROM foo WHERE id = 1") очень легко набыдлокодить и очень трудно потом выявить что же пошло не так. Откуда у вас такая непробиваемая вера в то, что если ошибку явно возвращать, то все быдлокодеры тут же выпрямят руки? Это чисто техническое решение отказаться от исключений ради более простой реализации concurrency, которое выдали за безусловно хорошую идеологически верную практику.

Мне нравятся исключения, но обозначение ошибки в декларации функции делает такой подход чище, а от checked exceptions все плюются.

Не очень понимаю, что именно мешает фигачить на Go проекты с большим объёмом кодовой базы.

Слабая типизация и мешает. А еще мода отказываться от ООП и всех наработанных паттернов проектирования.

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

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

На основании чего ты пытаешься судить о моей квалификации и в какой конкретно области? Даже интересно.

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

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

примеры когда человек похоже что компетентен, но никогда не говорит по существу есть, но их немного.

Техническая информация, ололо. Я на лоре ради срачей, ну о чём ты, всерьёз здесь пытаются вести исключительно технические обсуждения только отмороженные типа тебя.

Очень советую поберечь твою нежную присихику, зайти в мой профиль и нажать кнопочку «игнорировать».

Докер написан на Го

это заметно. до сих пор какие-то детские глюки, а ipv6 полноценный так и не впилили.

Глупо отрицать, что у языков есть домен.

Если популярность будет расти - будут развиваться фреймворки для всего и гоферы будут писать под все на го. Всегда проще выучить новый фреймворк, чем новый язык и новый фреймворк.

Как на js не пишут под микроконтроллеры

Ахаха.

На esp lua, наверное, популярнее C++. И даже так http://www.espruino.com/

Семантика wait/notify описана в JLS и в соотв. документации в жавадоке.

Ага. Ты на wait/notify будешь писать многопоточку в ынтерпрайзе, наивный. И весь код там будет исключительно твой, ну кроме jvm, конечно. Одну книжку прочитал и умный такой шо дай Бог.

Ты такой старомодный. Следи за трендами! Сейчас в моде ругать исключения и ООП

Я старый становлюсь, но стараюсь не отставать от молодёжи. На ноде вот начал писать, правда хайп уже прошел. Спиннер дочке (себе) купил.

Я твои посты который год уже читаю. Ты некомпетентный самоуверенный быдлокодер. Как и процентов 90 лора.

Ты шо дурак? Ты мой ник видел? Тебе надо было год меня читать?

А вообще то, что трудно говнокодить - это скорее плюс.

Вообще говоря всё как раз наоборот. Наговнокодить без проблем можно на любом ЯП. А вот нормально декомпозировать задачу и написать хороший понятный код можно не везде, в том же голанге это сделать практически невозможно из-за недостатка выразительных средств.

https://ru.wikipedia.org/wiki/Зацепление_(программирование)

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

И в поддержке проекта все так и есть.

Ахаха

Какая сильная аргументация.

И сейчас ты, видимо, назовёшь тех, кто занимается серьёзной промышленой разработкой с использованием указанного поделия. Хотя нет, не назовёшь.

из-за недостатка мозгов

Поправил, не благодари.

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

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

Там самая мякотка в конце:

Существуют различные методы уменьшения зацепления (англ. decoupling). Как правило, они описаны в виде шаблонов проектирования.

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

декомпозировать задачу и написать хороший понятный код [..] практически невозможно из-за недостатка выразительных средств.

Вспоминается высказывание про Фортран.

Если на Го писать, как на Яве или пыхе (что я, к сожалению, слишком часто наблюдаю), то да, получается какашка.

Но если использовать язык, а не бороться с ним, то твоё высказывание, мягко говоря, неверное.

композиция вместо наследования

Я тебе страшную тайну открою: фраза «предпочитайте композицию наследованию» не означает, что надо полностью отказаться от наследования. Надо лишь тщательно продумывать взаимосвязи is-a vs has-a, а не лепить бездумно наследование. Ну а гопники зато лепят везде композицию, потому что наследование им ампутировали. Отличное решение, что тут сказать.

4.2 же. Есть и инструменты и культура - https://www.youtube.com/watch?v=ifBUfIb7kdo&list=PL64wiCrrxh4Jisi7OcCJIUp... https://dave.cheney.net/practical-go/presentations/qcon-china.html

Просто программист на фортране может писать на фортране на любом языке.

ППКС

Программист живет не в вакууме, приходится работать с кодом других людей, многие из которых «лепят бездумно наследование». Вот, чтоб такого не было, гугл и сделал то, что сделал. Результат меня радует.

Если на Го писать, как на Яве или пыхе (что я, к сожалению, слишком часто наблюдаю), то да, получается какашка.

Сделали идеологический пыхпых, и теперь удивляются, что люди пишут на нем как на настоящем пыхпыхе.

Но если использовать язык, а не бороться с ним, то твоё высказывание, мягко говоря, неверное.

А можно пример хорошего кода на го? Не обязательно вашего.

На го не надо пытаться писать как на джаве или чем-то еще, к чему ты привык.

Можно пример хорошего кода на го. Не обязательно вашего.

Но почему по ссылке опять говнокод?

Можно пример хорошего кода на го. Не обязательно вашего.

Мне нравится, например, вот это - https://github.com/cweill/gotests

В Го не принято добавлять пустую строку после условий?

Нет, ни разу такого не видел. Обычно пустой строкой отделяются логические блоки кода, например, чтение файла отдельно, декодирование содержимого отдельно и обработка отдельно, если это все лежит в одной функции. Например - https://github.com/cweill/gotests/blob/master/internal/output/output.go#L23

Владимир

Вопрос к all.

Имеется ли код к которому не будет ни каких замечаний /C, C++, .../?

	srcFiles, err := input.Files(srcPath)
	if err != nil {
		return nil, fmt.Errorf("input.Files: %v", err)
	}
	files, err := input.Files(path.Dir(srcPath))
	if err != nil {
		return nil, fmt.Errorf("input.Files: %v", err)
        }

Я знаю, чем всё это закончится. Они начнут прокидывать велостектрейс через возврат. А пока мы имеем по строке (по 3 строки) на каждый возврат вместо одного единственного try-catch и throw там, где надо. Я тоже недавно подумал, нахрен мне эти исключения, напишу без них, и результат меня не радует. Буду втыкать обратно.

А пока мы имеем по строке (по 3 строки) на каждый возврат вместо одного единственного try-catch и throw там, где надо.

Тю, так можно ошибки просто проглатывать, и будет нормальный привычный код. Лол. Вся их культура зиждется на том, что кодер очень сознательный и усердный, каждый вызов будет проверять. Но дерьмо таки случается.

И вообще, это херовая практика выбирать между оставить и выкинуть, когда речь идёт о языке. Сделайте и то и то. Всё равно потом придётся делать. В JS вон тоже не хотели делать async/await, а пришлось. В яве не хотели делать глобальные «функции», а хотели везде принудительное ООП. В итоге сделали lombook костыли.

https://golang.org/src/regexp/regexp.go?s=9796:9832#L259

Я так же проверяю всё дерьмо, но одним catch, а не дрочу копипаст. И ошибку генерирую там, где она возникла, а не протаскиваю её через все методы руками. Ничего не мешает проверять каждое исключение.

Про panic уже говорили, что его лучше не пихать везде и это - не exception.

Владимир.

Не много об коде chronium.
Перед запуском Chrome можно очистить директорию
«C:\Users\МойЛогин\AppData\Local\Google\Chrome\User Data\»
А ведь он много чего там хранит ...

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

Более того можете в этой директории «исковеркать» файлы.
Ответ смотрите выше.

PS: «И это правильно»

Панику можно использовать если у тебя исключительная ситуация, например отсутствует необходимая для работы сервиса зависимость во время инициализации (отсюда всякие MustGetBlah), или есть глубоковложенные циклы. Но паники должны на верхнем уровне ловится и превращаться в ошибку: https://golang.org/src/encoding/gob/decode.go?h=catchError#L1086 https://golang.org/src/encoding/gob/error.go?h=catchError#L34

И обрати внимание, что код по ссылкам из стандартной библиотеки, соответственно, вполне идиоматичен.

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

У них была задача максимально упростить компилятор, все решения от этого отталкиваются. А потом на сцену выходят евангелисты и начинают лить говно в уши про минимализм и «вам это не нужно». Скорее всего Роб Пайк им и нужен был как в первую очередь евангелист с авторитетом, а не разработчик. Если бы язык делал некий хрен с горы, оправдать многочисленные WTF было бы сложнее.

У меня не настолько исключительная ситуация, например. Пользователь обделался с вводом при вводе параметров и сунул некорректный json или левые данные в нём и выяснилось это где-то в глубине из 10 методов. Мне паниковать из-за этого?

Владимир

Chrome поступает так: https://www.youtube.com/watch?v=PpGcsrsyBjQ

Ничего не мешает проверять каждое исключение.

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

Если что-то может пойти не так, и логика приложения должна это учитывать, то логично чтобы ошибка была в сигнатуре функции. Такой код проще читать и сопровождать. Если ситуация исключительная, а код глубоковложенный, находится в одном internal пакете, и работает, в основном, по happy path, то можно использовать panic во вложенных вызовах, а на верхнем уровне превратить это в ошибку.

У них была задача максимально упростить компилятор, все решения от этого отталкиваются

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

Ошибку видно в сигнатуре функции, в отличие от исключений. И есть линтеры, которые ловят необработанные ошибки.

чтобы вот так вот не копипастить. Ну стыдно же.

Go не про DRY. Для тех, кому стыдно есть более другие языки.

Такой код проще читать и сопровождать

Что проще?

ret, err = alala_1(...);
if (err) {
    return nil, Error("tralala_1:"+err);
}
ret, err = alala_2(...);
if (err) {
    return nil, Error("tralala_2:"+err);
}
ret, err = alala_3(...);
if (err) {
    return nil, Error("tralala_3:"+err);
}
ret, err = alala_4(...);
if (err) {
    return nil, Error("tralala_4:"+err);
}

try {
    ret = alala_1(...);
    ret = alala_2(...);
    ret = alala_3(...);
    ret = alala_4(...);
} catch {
    return Error("tralala:"+err);
}

Go не про DRY. Для тех, кому стыдно есть более другие языки.

Ну я уже понял, что go про DRO.