• Если вы подумываете начать писать на Go, то вот что вам следует знать
    0
    тем что не надо обновлять/патчить тот же JVM на всех серверах, где это ранится. А если докер — то тут надо следить за тем, что используют программисты и обновлять какой-нибудь базовый image.

    Деплоймент будет гораздо быстрее — компилятор быстрее, плюс не нужно тянуть кучи зависимостей типа docker image с OS, сам docker image будет максимально маленький.
    И все в этом духе.
  • Если вы подумываете начать писать на Go, то вот что вам следует знать
    +1
    Можно еще так — четные строки с запятой, нечетные без.
    Получается 100% защита от случайного удаления любой строки.
    Как тебе такое, 5oclock?
  • Если вы подумываете начать писать на Go, то вот что вам следует знать
    0
    Как часто вы случайно удаляли последний элемент в списке?
    У меня никогда такого не случалось.
    Ошибка — это то, что вам нужно исправить. Вот с удалением (или добавлением) запятой после редактирования кода я сталкивался — json был невалидный.
  • Если вы подумываете начать писать на Go, то вот что вам следует знать
    0
    о он не нужен тем кто работает с java, с#…

    в данном случае Go упрощает деплоймент и поддержку приложений.
  • Если вы подумываете начать писать на Go, то вот что вам следует знать
    0
    2. Ну когда вам нужно реализовать интерфейс, что бы использовать его в библиотеке, то все ок, да. Часто люди упрощают и передают один и тот же обьект, который реализует несколько интерфейсов.
  • Если вы подумываете начать писать на Go, то вот что вам следует знать
    0

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

  • Если вы подумываете начать писать на Go, то вот что вам следует знать
    0
    Это не защита, это источник ошибок. При добавлении элемента, нужно постоянно изменять предыдущею строку, что еще и неудобно.
  • Если вы подумываете начать писать на Go, то вот что вам следует знать
    0

    Это только в случае удаления последней строки, в середину тоже самое, то есть редкий кейс. Да и правильно — git diff и код ревью вам в помощь.

  • Если вы подумываете начать писать на Go, то вот что вам следует знать
    0
    и уже в 1.11. Если проект не в GOPATH — по-дефолту модули включены.
  • Если вы подумываете начать писать на Go, то вот что вам следует знать
    0
    > У Go есть рантайм? Или вы про стандартную библиотеку?

    Рантайм рантайм — сборщик мусора, планировщик goroutine, etc. Рантайм.
    Все это будет в вашем одном бинарном файле.
  • Если вы подумываете начать писать на Go, то вот что вам следует знать
    0
    > Домашние проектики и десяток стартапов.

    Ничего себе заявления. А вы случайно свои сайтики не в DigitalOcean хостите? А дропбоксом пользуетесь?
    Все проекты в CNCF написаны на Go (а те что не были, как linkerd, переписали на Go). Вот тут у Go как раз своя ниша — все что связано с платформой.

    Как бы вам не хотелось, но Go это как раз не домашние проектики.
  • Если вы подумываете начать писать на Go, то вот что вам следует знать
    0
    ну тут проблема в стиле — «вот в json не нужно запятую после последнего элемента ставить, а в Go нужно, ууууу, неудобно».
    @zubor правильно подметил — запятая после последнего элемента в много строчном объекте требуется специально (даже Russ Cox об этом писал), как раз из-за того, что при удалении и добавлении элементов (и генерации кода) не нужно было постоянно проверять последний ли элемент это или нет.
  • Red Hat будет поглощен IBM
    0
    OpenShift сейчас самый популярный дистрибутив Kubernetes. Весь интерпрайз (типа больших банков) ломанулись внедрять стильный-модный-молодежный Kubernetes, а тут и RedHat c OpenShift — OS они им уже сапортят, связи налажены.
    А еще RedHat недавно CoreOS купили со всеми их поделками (Tectonic, etcd, etc).
  • Обработка ошибок в Go 2
    +1

    Судя по тому, что хотят дефолтный хендлер добавить вида handle err { return err }, то так и будет, как вы написали во втором случае

  • Обработка ошибок в Go 2
    –1
    тогда можно не использовать общий хендлер и создать специальный или обработать просто с if err != nil
  • Обработка ошибок в Go 2
    0
    вариантов очень много, можете держать названия файла в структуре ошибки и потом сначала проверить тип, а потом поле с файлом
  • Обработка ошибок в Go 2
    0
    делает check с дефолтным хендлером в Go

    не делает, но то что предлагают, конечно же

  • Обработка ошибок в Go 2
    0
    я не готов дискутировать на эту тему, так как не знаю как это реализовано.
    Знаю что в расте оператор? или макрос try! это такая же обработка ошибочной ситуации паттерн матчингом.
    Точно тоже, что делает check с дефолтным хендлером в Go или вручную с if err != nil.
  • Обработка ошибок в Go 2
    0
    действия который происходят во время ошибочной ситуации (то есть после диагностирование) есть обработка ошибочной ситуации. Возврат ошибки — это остановка дальнейшего выполнения функции/метода.

  • Обработка ошибок в Go 2
    0
    отличный комментарий.
    Вы считаете, что все что в теле `if err != nil` все еще диагностирование?

  • Обработка ошибок в Go 2
    0
    Диагностирование есть часть с проверкой, обработка — это возвращение ошибки.
    if err != nil { // диагностирование
        return err // обработка
    }
    
  • Обработка ошибок в Go 2
    0
    нет, я считаю, что
    * вызов дефолтного хендлера это обработка ошибки, так же как `?` в Rust — это обработка ошибки. Так же как `unwrap` это обработка ошибки — бросает панику если есть ошибка.

    * будут не только дефолтные хендлеры, конечно же, хотят добавить больше возможностей (что бы добавлять контекст во все ошибки функции, например)

    Я вам привел пример того, что в Rust есть «обработчик ошибки в Rust, который определяется задолго до места, в котором ошибка диагностирована»
  • Обработка ошибок в Go 2
    0
    У вас вот тут противоречие:
    Задача '?' и 'try!' лишь в том, чтобы проверить результат операции и, если результат отрицательный, возвратить его в вызывающую функцию.

    И
    Все. Никакой обработки ошибок ни '?', ни 'try!' не задействует.

    Тоже самое будет делать check c дефолтным хендлером.

    Обработка реализуется в вызывающей функции посредством обычного паттерн-матчинга (либо через match, либо через if let). И, что важно, обработчик ошибки в Rust-е пишется там же, где результат операции проверяется.

    Как и в Go c `if err != nil`
  • Обработка ошибок в Go 2
    0

    а что не так? Если не определять handler то будет использоваться дефолтный handle err { return nil } — как в Rust c?..
    В тоже время можно определить свой в начале метода/функции или обработать ошибку в месте, где возникла if err != nil {}.

  • Обработка ошибок в Go 2
    0

    ? и unwrap

  • Обработка ошибок в Go 2
    0
    Ну даже написали почему не добавили generics — golang.org/doc/faq#generics
    Ниже там и про exceptions, assertions, etc.
  • Обработка ошибок в Go 2
    +1
    о там что бы сделать удобно

    А вам более удобно пользоваться тачпадом или мышкой?

  • Обработка ошибок в Go 2
    +1
    сегодня видел статистику — за второй квартал 2018 года коммитов в Go от не-гуглеров больше чем от гуглеров.
  • Обработка ошибок в Go 2
    0
    Но в моем исправленном тезисе вопрос был про удобство, а как я понимаю, эти костыли в целом влияют на производительность.

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


    Офф-сайд: некоторые опытные люди, например, автор fasthttp предлагают в go так же запускать по процессу на процессор (в README написано, что на ядро, но в telegram чатике go вызвали вроде как core-разработчика и он пояснил, что это старая информация и имеет смысл только в том случае, если у вас несколько процессоров, прирост почти 15-20%)

    Вы сами хоть читаете ссылки, что постите?


    Use Go 1.6 as it provides some considerable performance improvements.
  • Обработка ошибок в Go 2
    0
    Мы можем конечно повторить разговор — вы покажете, как сделано concurrency в питоне (с IPC и процессах), я скажу что это костыли, а вы, что «мне кажется, вместо каналов вы чаще будете использовать какие-то другие MQ, например nats.»
  • Обработка ошибок в Go 2
    +1
    Это тут причем?
    Мы говорили про concurrency в Go. Вы сказали, что в питоне не хуже, потом привели пример с IPC и процессами.
  • Обработка ошибок в Go 2
    +1
    Даже тут я говорю про каналы и горутины. Вы свой комментарий то прочитайте.
    Если вы говорите, что вместо каналов в реальности будут использовать внешнюю очередь — то вы не понимаете, что такое многопоточность.
  • Обработка ошибок в Go 2
    0
    Мы разговаривали не про какие-то абстрактные воркеры, а про горутины.
    А вот ваш комментарий
    А еще обратно к реальному миру, мне кажется, вместо каналов вы чаще будете использовать какие-то другие MQ, например nats.
  • Обработка ошибок в Go 2
    +1
    SirEdvin типичный троль, его цель тут просто набрасывать. При этом человек рассуждает на счет concurrency в Go, даже не понимаю что-то такое многопоточность, говоря, что «в реальности вместо каналов в Go будет использоваться внешняя очередь типа NATS».
  • Обработка ошибок в Go 2
    +1
    Так как подавляющее большинство функций может завершиться ошибкой, то получается, что перед всеми вызовами будут писать check. Какой смысл в такой "явности" ума не приложу. Тем более что всё равно не понятно какие именно ошибки может кинуть функция и все ли из них были обработаны.

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

  • Введение в систему модулей Go
    0
    это я предположил, просто еле расшифровал ваш комментарий
  • Введение в систему модулей Go
    0
    как минимум за грамматику
  • Введение в систему модулей Go
    0
    ну так как вы можете это сравнивать? Так же как сравниваете горутины и процессы питона.

    Вы сравниваете многопоточное приложения с практически распределенными системами. Это разные уровни.
    Точно так же сервисы на Go будет использовать внешнею очередь для коммуникации между сервисами.
  • Введение в систему модулей Go
    0
    Касательно каналов, как часто вы используете их не как очередь и не из-за того, что у вас недостаток контроля над горутинами?

    Каналы использую для коммуникации (в основном) и управления (старт-стоп).


    Вы разницу понимаете между каналами в Го внешней очередью?

  • Введение в систему модулей Go
    –2
    И это означает, что несколько запросов будут обрабатываться параллельно, я не прав?

    Вы не правы, если у вас один тред (как вы сами сказали), выполняться будут конкурентно, не параллельно, просто тред не будет ждать i/o и в это время обрабатывать другой запрос.


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