21 жовтня – JS Conference 2017 у Києві. Як уникнути критичних помилок при створенні нового проекту?
×Закрыть

Какие перспективы Golang в Украине и в целом?

Всем добрый день.

Хотел бы задать на форуме неторые вопросы о перспективах разработки на Go в Украине.
Сам достаточно давно пишу под мобайл и немного интересуюсь бекендом.
Поэтому рассматриваю Go как дополнение к тому что знаю а не первую технологию.
Go привлек внимание статической типизацией, схожестью со Swift, тем что это продукт Google.
Но когда видишь на доу около 10 вакансий по всей Укриане сильно сомневаешься в востребованности данного языка.
В связи с этим и отсутствием понимания того что происходит в мире бекенда решил задать вопросы.

1. Достаточно ли знать Go для работы бекендщиком (в плане языка) — или только со стеком других языков?
2. Востребован ли Go на рынке в принципе или все же это экзотическая технология
3. Применяется ли Go в энтерпрайзе
4. Есть ли какие-то перспективы Go в Украине (какие компани) или это только США
5. Видите ли Вы Go перспективным в ближайшее время и стали бы его изучать?
Если да — то на какие ресурсы по изучению стоит обратить внимание?
(Английский свободный поэтому буржуйские ресурсы с сертификацией приветствуются)

Спасибо тем кто найдет время ответить.

LinkedIn

Лучшие комментарии пропустить

Валялкина 3 дня нет, он в порядке?

1. Из личного опыта — можно использовать чисто его. Но некоторые вещи логичнее делать на каком-то python/ruby/js. Например нету смыла админку для какого-то процессинга пилить на Go только потому что сам процесинг на нем.
2. Если сравнивать с js — то нет) Если же говорить о возможности устроится разработчиком — как нефиг. Конкуренция низкая, а проектов уже тонны.
3. Из того что знаю точно:
Uber/Docker/Gogs/juju используют основным и помимо того свои либы выкладывают.
FB/Percona используют точечно.
Еще знаю 2, которые используют исключительно Go на бекенде для реализации закрытых проектов.
4. В Украине точно SoftServe/Ciklum/ZeoAlliance + еще жменька стартапов и мелких продуктовых компаний.
5. Пол года уже только на нем сижу. Причин возвращатся на python не вижу.
Попробовать базу: tour.golang.org
Для большего понимания что внутри: golang.org/doc/effective_go.html
Грабли: go-traps.appspot.com
Рассылка самого актуального за неделю: golangweekly.com
Ну и комьюнити всегда можно спросить: golang-ua.slack.com

щас набежит Валялкин и все расскажет)))

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Пишем Cloud провайдера на Golang. Система основана на микросервисной архитектуре, контейнерах (Docker, Kubernetes), распределенных базах (Cassandra) и еще куче всего.

Самый большой профит в Go, это его коммюнити, есть много наработанных best practices и подходов. Чего стоят только Effective Go и Code Review Guide, плюс тулинг на хорошем уровне, golint, go vet, go fmt, металинтеры, профайлер, race detector, все это очень сильно облегчает и убыстряет разработку. Хотя delve(дебаггер) конечно еще сыроват.

Что реально бесит, так это конченный менеджмент зависимостей, vendoring hell, хотя эта проблема решена с блеском в других языках. Была у меня надежда на dep, но посмотрев что твориться в их репе, мне кажется что они не решат проблему.

Так что, отвечая на ваш вопрос, в основном го это стартапы (иногда правда очень enterprisey), кроме самого языка следует знать основные идиомы, практики и подходы.

В общем, Golang это не только язык, но и хорошая инженерная культура. Большинство гоферов это опытные девелоперы перекочевавшие из других языков. В основном, кстати, из питона и джавы/скалы.

p.s. turnoff.us/geek/lang-buddies

Что реально бесит, так это конченный менеджмент зависимостей, vendoring hell, хотя эта проблема решена с блеском в других языках. Была у меня надежда на dep, но посмотрев что твориться в их репе, мне кажется что они не решат проблему.

Мы успешно используем gb — getgb.io — для управления внешними зависимостями.

Кстати, а в чём vendor hell? То что из коробки не было «стандартного» решения для пиннинга версий и вендоринга — это понятно, но всегда были сторонние тулзы, и сейчас с vendor/ и тулзами вокруг него, ну как бы максимум на что можно жаловаться — это на то, что надо учить команды новые, как этим пользоваться.

эта проблема решена с блеском в других языках.

А вот это было смелое утверждение. :) Где именно там блеск — в Cabal Hell или в истории с leftpad?

Ну и как бы самое лучшее чтиво на тему того, почему менеджеры зависимостей это сложная тема — medium.com/...​kage-manager-4ae9c17d9527

Взгляд с моей колокольни

срез devops стека 3-4 года назад:
— vagrant (ruby)
— KVM/vmware etc (c, c++)
— zabbix, collectd, naigios (php, c)
— syslog-ng, rsyslog ( с)
— apt, yum etc (c, python)
— chef, puppet etc (ruby)

что я использую сегодня
— docker (Go)
— docker-compose (python)
— influxdb (Go)
— prometheus (Go)
— k8s (Go)
— terraform (Go)
— packer (Go)
— vault (Go)
— ansible,salt (python)
— aws, doctl и прочие мелкие утилиты (Go, python)
— filebeat (Go)
— ELK (ruby, java)

Комментировать не буду, всё очевидно

3-4 года назад були ще нормальні, православні адміни.

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

А чем Ansible/Salt победил Chef? Вопрос без всяких подколок, интересно услышать мнение.

Тем временем Go 1.9 уже на подходе, а перспектив все так и не наблюдается.

Может, после go 1.9 будет go 2.0 с дженериками и эксепшнами? github.com/golang/go/labels/Go2

Скорее когда New horizons долетит таки до Сириуса))))

Ну или точнее пролетит с ним приблизительно рядом)))
А случиццо это очень нескоро.....

Я взял примерный промежуток от С к С++)

Тю. А навіщо? Гоубої й самотужки справляються www.reddit.com/...​y_in_go_and_rust/dcsgk7n

P.S. Попри мою любов до С++, найбільше там сподобалось «c++ allows 0-width spaces in variable names. Where’s your god now?»

P.S. Попри мою любов до С++, найбільше там сподобалось «c++ allows 0-width spaces in variable names. Where’s your god now?»

Хм. Не працює в гцц і клангу. Може фейк :)

go 2.0 с дженериками и эксепшнами?

Это зрада от некоторых скала-программистов, никакие дженерики в Go не нужны, и тем более эксепшены. Уже есть интерфейсы, и механизм panic-recover, работающий аналогично эксепшенам. Они хотят напичкать Go механизмами из скалы, чтобы попытаться самим приблизиться к всеобщей популярности и славе Go. Но ничего у них не выйдет, мы это вовремя заметили, пусть лучше сами переходят на Go, как большинство других скала-программистов.

наврядли в Go когда нибудь появятся монады, патамушта это сильно сложно для типичного Гошника

Какие нафиг монады. То джаву ругали за отсутствие вменяемого апи для работы с коллекциями, теперь пипл снова счастлив лупы, ифы и трансформеры ручками писать.

Зато для типичного Гошника несложно писать сетевые сервисы, которые не текут, в отличие от типичного С+±сника :)

А в чем проблема писать сетевые сервисы, которые не текут, на С++?

Количество лет опыта, необходимое для этого, надо полагать.

Вот вроде и ответ, а не ответ :)

Кстати, взаимно :)

Вот как вы опишете стандартный путь С++ программиста с нулевого уровня до уровня «могу написать production-level сервер, по всем лучшим практикам, который не течет, и не стыдно в open-source выложить и коллегам показать»? Сколько лет, шишек, простреленых ног и прочитанных книг нужно, чтобы программист был уверенным на таком уровне? Ваше мнение?

Давайте краще Ви все ж таки аргументуєте

Зато для типичного Гошника несложно писать сетевые сервисы, которые не текут, в отличие от типичного С+±сника :)

Чи розходимось?

Чи розходимось?

Тобто ви відмовляєетесь відповідати на просте питання?

Зрозумів, розходимось. Бо я спитав, мені не відповили, а тепер звинувачують, що це я не відповідаю :)

мені не відповили,

Відповів і задав вам запитання, щоб розкрити думку і перевірити чи ми однією мовою говоримо.

то есть на Go можно джуновские поделки оп оп и в продакшен?

Именно. В Go не обязательно быть зазнавшимся сеньором с 10+ годами опыта, чтобы мочь что-то написать, которое работает, хорошо выглядит и нестыдно выкладывать в продакшн. Вы уловили суть )

для стартапа такой подход норм, все равно код на свалку пойдет потом

Это если бы он был на С++, то да, ваши рассуждения верны.

на С++ не пишут стартап поделки, и это хорошо

1. Достаточно ли знать Go для работы бекендщиком (в плане языка) — или только со стеком других языков?

Зависит от проекта.

2. Востребован ли Go на рынке в принципе или все же это экзотическая технология

Востребован. Сравните количество популярных проектов на go с проектами на других языках программирования , размещенных на github — github.com/...​arch?q=language:go stars>666 (скопируйте ссылку полностью с >666 — не знаю, как это исправить на смартфоне). Go уверенно опережает c, c++, php, swift, scala и rust по количеству популярных проектов.

3. Применяется ли Go в энтерпрайзе

не знаю. Хотелось бы, чтобы не применялся.

4. Есть ли какие-то перспективы Go в Украине (какие компани) или это только США

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

5. Видите ли Вы Go перспективным в ближайшее время и стали бы его изучать?

см. ответ на предыдущий вопрос.

Если да — то на какие ресурсы по изучению стоит обратить внимание?

На www.amazon.com/...​l-Computing/dp/0134190440

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

Это вы загнули. Тоже говорили про Dart, Node, кто-то говорил, что все будет Elixir/Erlang. Golang хороший язык для своей области применения.

Вот Top 10 ЯП с TechCrunch Hackaton:

HTML/CSS (see note below)
JavaScript
Python
Java
C/C++
PHP
Objective-C
C#
Swift
JSON (which isn’t ... really a programming language, but is on their list for some reason, so I’m including #11 too)
Ruby

Вероятность выжить у стартапов 2017 года на go в 10 раз выше вероятности выжить у стартапов на остальных языках программирования, особенно на HTML/CSS/JSON :)

Вероятность выжить у стартапов 2017 года на go в 10 раз

может быть. будем считать что так.

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

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

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

ну а писать необходимый функционал, абстрагируясь от задач программирования ради программирования — можно только на Go

Валялкин — перелогинься))

шутка начинает терять свежесть

но не теряет актуальность))

а разве есть стартапы на чистом html/css/json?)

неважно, главное использовать пробелы всесто табов)

3. Применяется ли Go в энтерпрайзе
не знаю. Хотелось бы, чтобы не применялся.

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

Go привлек внимание статической типизацией, схожестью со Swift, тем что это продукт Google.

Пошутил о схожести? Неудачно.

У Go нет перспектив с такими адептами, как Валялкин. А таких в го чересчур много на мой нерепрезентативный вкус.

Шо, опять? Го может и хороший язык, но его упоротые фанаты портят все впечатление.

1. Да, и более того — сейчас очень мало причин писать бекенды на чём-то другом. Точнее, есть ровно две причины: а) команда упоротая и не готовая учить новое, б) команда должна писать и фронтенд и бекенд => node.js
2. Этот рынок очень инерционный, статистически Go еще не сильно популярен, но его популярность растёт очень стабильно, без пиков и провалов, что есть хороший знак. Посмотрите тред Who is hiring на Hacker News, мягко говоря востребован.
3. Редко, там засилье спецыалистов по джаве, они в своих мирах. Monzo, к примеру, онлайн банк написали на Go, но они не такие умные, как большинство комментаторов, они не знали, что Go в энтерпрайзе плохо.
4. Да везде есть. На самом деле Go использует много кто для внутренних проектов и инфраструктурных вещей, и это, конечно, не афишируется.
5. Go это С 21-го века, и всё новое для облачных технологий пишется на Go и этому есть веские причины. Писать бекенды и сервера не на Go в наши дни особо смысла нет — себе дороже. Кроме того Go дизайнился по многим параметрам для того, чтобы быть языком на 2-3 десятилетия вперед. Начиная от promise of compatibility и заканчивая дизайном сборщика мусора. Программы написанные на Go вчера будут эффективно работать через 30 лет на новых платформых и новых масштабах ресурсов. По крайней мере, такова идея и задумка. Мало кто из языков таким может похвастаться.

Да везде есть. На самом деле Go использует много кто для внутренних проектов и инфраструктурных вещей, и это, конечно, не афишируется.

У нас есть такие приборы, но мы вам их не покажем

всё новое для облачных технологий пишется на Go

Прям перл на перле.

Оставьте уже язык в покое, пусть живет по мере сил и возможностей без пихания во «всё»

У нас есть такие приборы, но мы вам их не покажем

Ну причём тут. Не все компании пишут посты про свой стек.

Оставьте уже язык в покое, пусть живет по мере сил и возможностей без пихания во «всё»

Он и живет :) Его делали для клауда, так что ничего удивительного.

Неё, градус упоротости маловаць))

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

А можете пояснить в чем он плох для Enterprise ?

А можете пояснить в чем он плох для Enterprise ?

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

но, как и на plain C писали когда-то и энтерпрайз, так и на нем можно.

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

Сколько С++ и Java-поделок полегло от фанатов эксепшенов, которые считают, что обработку ошибок нужно сбрасывать на магию языка. Спасибо, натерпелись.
А вот вам исследование, показывающее статистику о том, как ваши волшебные эксепшены костыльно используются на практике. neverworkintheory.org/...​a-exception-handling.html

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

Они точно так же будут использоваться в формате if (err != nil) { залогать_и_забыть(); }
Если ошибку можно игнорировать — это будет сделано кем-то, и больше случаев, чем можно.

Они точно так же будут использоваться в формате if (err != nil) { залогать_и_забыть(); }

Залогать и забыть это противоречивые вещи. Если вы написали проверку на статус ошибки, и приняли решение, что здесь нужно вывести сообщение в лог, придумали это сообщение — это уже не «забыть». Вы уже подумали об ошибке и как будет код себя вести, когда ошибка случится. Более того, ваш коворкер или вы через 5 месяцев, читающий этот код, тоже сразу же будете знать, что происходит в случае ошибки. И на добавку, это формирует просто другое отношение к ошибкам — мол да, они часть работы программы, их не надо прятать или считать каким-то «неполноценным» кодом, который надо засунуть подальше от глаз. Многие люди пишут, что Go научил их относиться к ошибкам правильно, и я их отлично понимаю.

Залогать и забыть это противоречивые вещи.

Забыть — в смысле, не обрабатывать дальше/полнее в самой программе.

Если вы написали проверку на статус ошибки, и приняли решение, что здесь нужно вывести сообщение в лог, придумали это сообщение — это уже не «забыть». Вы уже подумали об ошибке и как будет код себя вести, когда ошибка случится.

Верно, и это точно так же делается (но удобнее) в случае механизма исключений.

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

И что же их стимулировало раньше прятать ошибки, кроме собственной... мнэээ... лени?

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

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

Да не нужно ничего костылить — это просто другое отношение к обработке ошибок. Они просто другие и все. Как писал Pike: Ошибка это значение, а если это какое-то значение или состояние которые вы можете обработать, значит вы можете вернуть ошибку как значение. Для каких-то критических ситуация есть Defer, Panic, and Recover.

Ошибка это значение, а если это какое-то значение или состояние которые вы можете обработать, значит вы можете вернуть ошибку как значение.

И в других языках могу, и что с того?

Для каких-то критических ситуация есть Defer, Panic, and Recover.

И зачем тут отделять эти критические ситуации?

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

А ошибки и error path — это такой же код, как и happy path и заслуживает ровно столько же внимания. Без надежды на магию языка.

А ваше аргументы «я тоже могу» мало на что влияют — люди выбирают всегда путь наименьшего сопротивления и используют язык, как проще и удобней, а не «как тоже можно» и «как правильно». Но мне кажется вы агрессивно отказываетесь это понимать.

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

Согласен. На исключениях это будет точно так же, если их не перехватили.

А ошибки и error path — это такой же код, как и happy path и заслуживает ровно столько же внимания. Без надежды на магию языка.

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

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

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

Зато они позволяют избавиться от тонн тупого boilerplate.

Это правда, в редких случаях, эксепшены действительно экономят целых 10-15 строк кода. Ценой а) уменьшения понятности кода (error path, точнее) б) формирования стиля мышления, не стимулирующего относиться к ошибкам с должным вниманием. Это большая цена, и статистика выше это подтверждает, и, как бы вам не хотелось верить, что «надо просто научиться их правильно использовать» и «никакой язык не ограничит» — это не так. Гугл запретил эксепшены в своих С++ проектах не просто так, и тулинг на самом деле очень сильно влияет на то, как мы и что используем. Вообще-то это должно быть очевидно, но ладно.

Ценой а) уменьшения понятности кода (error path, точнее)

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

Это большая цена, и статистика выше это подтверждает,

Уже сказано — ничего не подтверждает, потому что сравнивать не с чем. Когда те же миллионы индусов повалят в Go, потому что для них создали все условия, и пойдёт поток дерьмового кода — Вы это увидите. Ну а до этого можно увидеть анализом кода на C — например, какая доля от всех писателей обращает внимание на ошибки функций типа close().

Гугл запретил эксепшены в своих С++ проектах не просто так,

Этот запрет растёт из тех времён, когда реализация исключений в gcc ещё отрабатывалась и была сырой (да, у gcc долго были тяжёлые проблемы с C++, они их полечили в принципе только где-то к 2002-му, а местами и позже). А дальше — legacy condition.
Ссылаться на этот запрет сейчас — неадекватно и показывает уровень аргументации.

Вообще-то это должно быть очевидно, но ладно.

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

А самое смешное, что >50% механизма для исключений уже есть — за счёт defer + recover — и понимаемость что main path, что error path уже существенно снизилась за счёт перехватов и срабатываний на выходе. Но чтобы авторы Go в этом признались — да ни в жисть, им же придётся сознаться в своей глупости...

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

Ахаха, блин, надеюсь вы никакой важный софт не пишете. War is peace, «переопределение операторов» это понятность. Ясно всё.

Когда те же миллионы индусов повалят в Go, потому что для них создали все условия, и пойдёт поток дерьмового кода — Вы это увидите.

Ждём. Пока что это лишь ваше предубеждение, не подтверждаемое ничем.

А самое смешное, что >50% механизма для исключений уже есть — за счёт defer + recover — и понимаемость что main path, что error path уже существенно снизилась за счёт перехватов и срабатываний на выходе.

Ну если вы начинаете понимать tradeoff между verbosity и readibility и обвиняете defer в усложнении понимания, то от эксепшенов вас вообще должно воротить. Это если у вас логическое мышление, конечно.

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

Ну да, куда там людям, написавших UNIX до вашей мудрости :D
Черт, я уже отвык от таких умнее-всех-на-свете :) Спасибо, что развлекли.

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

Ахаха, блин, надеюсь вы никакой важный софт не пишете. War is peace, «переопределение операторов» это понятность. Ясно всё.

Ну вперёд говнокодить тоннами нечитаемых нагромождений и вводить типы данных в язык под каждый чих.

Ну если вы начинаете понимать tradeoff между verbosity и readibility и обвиняете defer в усложнении понимания, то от эксепшенов вас вообще должно воротить. Это если у вас логическое мышление, конечно.

Боюсь, с Вашей «логикой» мне не подружиться. В нормальной же — воротить от исключений не будет.

Ну да, куда там людям, написавших UNIX до вашей мудрости :D

Ранний UNIX вообще-то был не очень приятной и весьма костыльной штукой. Только переработка (с кучей несовместимостей) привела его к нормальному виду. Но отсылка к нему ещё и показывает, что аргументы по сути у Вас кончились, и начались отсылки к авторитетам. Этим обычно такие дискуссии и характерны — для тех, кому Пайк бохъ и пророк.

Черт, я уже отвык от таких умнее-всех-на-свете :) Спасибо, что развлекли.

Даже не начинал. Ещё одна «особенность» Вашего восприятия, в копилочку.

И в других языках могу, и что с того?

Можете, но здесь это часть ЯП. Опять же — всегда видно, если метод может вернуть ошибку. Допустим в .NET нет явного упоминаеть может метод вернуть ошибку или нет. В результате код обрастает конструкция try/catch или какими-то обработчиками Unhandled Exception или добавляют пакеты...

Есть дискуссия на redditt по этому поводу.

Можете, но здесь это часть ЯП.

В Java, например, тоже часть ЯП (в плане checked exceptions). На эту фичу больше жалоб, чем положительных отзывов; в C# её не перетащили. И это явно не из-за возможной громоздкости писать catch.

Допустим в .NET нет явного упоминаеть может метод вернуть ошибку или нет. В результате код обрастает конструкция try/catch

У вас логическая ошибка: код обрастает try/catch не потому, что нет упоминания, что вернёт или нет, а потому, что может быть вернута ошибка, которую именно тут хочется обработать.

Но если нет такой необходимости, то в языке с исключениями просто пропускается действие (по умолчанию — передача выше), а в языке с явной передачей кода (Go) надо ещё каждое такое место обернуть в проверку. Boilerplate-мусор в чистом виде.

Есть дискуссия на redditt по этому поводу.

Там есть много дискуссий, и что?

Boilerplate-мусор в чистом виде.

Вот об этом я и говорю. То что программисты, травмированные эксепшенами называют «мусором в чистом виде» является просто напросто должным отношением к ошибкам и их адекватной обработкой. Когда перестанете относится к error path как к «мусору» или как чему-то «исключительному», что нужно прятать от глаз подальше с помощью «исключений», тогда Линус Торвальдс перестанет ненавидеть ваш код :)

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

[mode=зеркало]Тот лишний код, который программисты, травмированные отсутствием исключений, называют «должным отношением к ошибкам» и «их адекватной обработкой», таки является мусором в чистом виде.[/mode]

Когда перестанете относится к error path как к «мусору» или как чему-то «исключительному», что нужно прятать от глаз подальше с помощью «исключений», тогда Линус Торвальдс перестанет ненавидеть ваш код :)

Мне неинтересна ненависть Торвальдса. А про error path как «мусор» и «от глаз подальше» Вы домыслили сами, вот со своими домыслами и разбирайтесь.
Error path в виде catch — это не мусор, это нормальная обработка ровно там и так, где она нужна.

И зачем тут отделять эти критические ситуации?

Defer это где-то аналог finally. Вы говорите, что должно выполнится после завершения работы фунции.
Panic — останаваливает работу приложения
Recover — перехватывает работу после Panic.

Если очень кратко. Вообщем это просто другой подход.

Defer это где-то аналог finally.

[...]

Спасибо, кэп. Эта группа банальных фактов никак не отвечает на мой вопрос.

Если очень кратко. Вообщем это просто другой подход.

И ничего тут не объясняет, чем этот закат солнца вручную будет лучше.

Panic/Recovery — предоставляет обработку ошибок времени выполнения.

Что касается Error вместо Exception — так сделано, чтобы уменьшить злоупотребление блоками try/catch. Поэтому повысили гранулярность с блок до функции.

Мне лично более понятна конструкция try/catch, но я не против посмотреть в другую сторону и пытаюсь вам пояснить, почему разработчики Go пошли таким путем.

Panic/Recovery — предоставляет обработку ошибок времени выполнения.

Опять кэпствуете.

Что касается Error вместо Exception — так сделано, чтобы уменьшить злоупотребление блоками try/catch. Поэтому повысили гранулярность с блок до функции.

Получили вместо этого злоупотребление проверкой переменной-ошибки.

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

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

злоупотребление блоками try/catch

Злоупотреблять можно практически чем угодно.
Го язык декларируется — как очень простой язык- в то же время способ обработки ошибок- уж очень дырявый.
1. на куждый чих проверять код ошибки
2. где то зыбыл проверить код ошибки с функции- и приплыли- попробуй отлови такое место потом.

1. на куждый чих проверять код ошибки

В Go нет «кодов ошибки». Вы либо спросите у тех, кто знает, либо сначала изучите тему, а потом спорьте :)

где то зыбыл проверить код ошибки с функции- и приплыли- попробуй отлови такое место потом.

Я, снова же, боюсь, что слишком сложными концепциями оперирую тут, но то, что я пытаюсь донести, что Go «стимулирует» программиста относится к ошибкам как к таким же значениям, как и любые другие. Тоесть вот есть у вас функция, допустим sqrt() - прежде чем ее использовать, вы смотрите, что она возвращает, допустим float64. Вы вызываете функцию и что-то делаете с возвращенным значением. Вы же не скажете «можно забыть проверить результат функции — значит способ возвращения результата плохой»? Глупость, правда? То же самое с ошибками — вы смотрите сигнатуру функции и очень явно видите, что она может вернуть ошибку — допустим func sqrt(float64) (float64, error). Чтобы «забыть обработать ошибку», вам нужно сознательно замьютить возвращенное значение — res, _ := sqrt(x) — и это не просто дополнительный символ, это блин сознательное решение «я говорю компилятору, что я явно забиваю на ошибку». И это биг дил, это режет глаза, на это плюются специальные линтеры, за это бьют по рукам в код-ревью, и в целом, в большинстве кодовых баз на Go на ошибки не «забивают». Вы можете как угодно это себе объяснять (проще всего сказать «вы все врете»), но это факт.

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

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

В Go нет «кодов ошибки». Вы либо спросите у тех, кто знает, либо сначала изучите тему, а потом спорьте :)

В коде вида res, err := Foo() это err можно назвать кодом ошибки, даже если оно объект. Это уже устоявшееся выражение.

res, _ := sqrt(x)
И это биг дил, это режет глаза, на это плюются специальные линтеры, за это бьют по рукам в код-ревью

Точно так же в код-ревью будут бить за невыловленное исключение — а в случае checked exceptions это поймает компилятор. Причём явный catch или декларирование в заголовке функции лучше ловится, чем _ в назначении ошибки.

Вы можете как угодно это себе объяснять (проще всего сказать «вы все врете»), но это факт.

«Факт» без единого доказательства. Да, «вы всё врёте» не просто «проще» — оно тут вполне уместно.

Но, кажется, это слишком сложно пока для понимания.

Ну так на то и ваша религия, что понимать её посторонние не хотят.

Иван- вы и правда думаете что

это слишком сложно пока для понимания

?
Это больше похоже на то- что Вам сложно понять- что не все хотят быть столь категоричны по поводу ошибок и исключенией. Отсутствие проверки на исключение- это еще не означает что программист забил на неё.
Я хочу написать чистый код — реализующий определенный алгоритм/логику. Это код должен в первую очередь легко читаться посторонним разработчиком.
В том же Java, C# -отловить ошибки я могу и на более высшем уровне вызова или или вообще создать глобальный отлов исключений- тем самым не засоряя код лишним кодом.
Я прекрасно понимаю- что это разные философии и разные подходы- говорю лишь, что мне не нравится гоу подход, а также весьма резкий тон сообщений большинства поклонников гоу языка.

Я прекрасно понимаю- что это разные философии и разные подходы

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

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

Go, будучи языком, в котором решили использовать только проверенные годами и десятилетиями концепции (та же фишка со встроенной concurrency, хоть и новая для языков, но основана на CSP пейпере 78го года), попытался взять знакомую концепцию возвратных значений и решить её проблемы (ограниченность значений, необходимость в errno и тд). Разница между использованием кодов возврата в С и использования интерфейса error в паре с множественными return значениями — это примерно как разница между пользованием дисковым телефоном и 7-м айфоном: и тот и другой вроде как телефоны и умеют звонить, но экспириенс совершенно другой. Поэтому когда, люди знакомые только с кодами возврата и эксепшенами рассказывают своё мнение о том, какова же обработка ошибок в Go, это сначала забавно, потом смешно, потом скучно. И чем более яростно они доказывают своё предубеждение, тем сильнее реакция на их глупости.

Но всё же главная идея — и она вот даже в вашем комментарии хороша видна — это то, что Go заставляет считаться с ошибками на равных с остальным кодом. Код, который обрабатывает ошибку, это не то что не «грязный код» это очень часто, куда более важный и первичный код, о котором нужно думать, чем happy path. И это настолько правильно, это надо вбивать в головы с ясель, и Go это делает неявно. Эксепшены же в этом плане полная противоположность и стимулируют думать о коде обработки ошибок в последнюю очередь, поощряют «а, потом подумаю что делать с ошибкой» и так далее, что очень хорошо и продемонстрировано вышеприведенным исследованием (ну, или мнением людей с тонной практического опыта).

прятать код обработки с глаз подальше и так далее

Я думаю, что понять преимущество чистого кода можно с опытом работы над очень крупной codebase, в команде где уровень скиллов может разниться от джуна до крепкого сеньора- помидора.
Можно привети множество примеров- но основной пример состоит в том- что человек пришел на существующий проект- смотрит кодовую базу и хочет понять что и как работает- он хочет видеть логику программы- код проще читать — когда он чистый. Если/когда ему будут интересны- обработки ошибок- оптимизации, методы логирования- он пойдет в сервисную часть кода приложения- и посмотрит/подправит.

проверенные годами и десятилетиями концепции

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

Go заставляет считаться с ошибками на равных с остальным кодом

Верно. Либо ошибка обработана- или проигнорирована. Но для кого-то думаю это вполне подходит.. Я похоже слишком балованный возможностями Java/C#

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

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

та же фишка со встроенной concurrency,

Это классно- тут не поспоришь- не надо тянуть сторонние библиотеки.
Но в том же C# уже тоже давно есть возможности лековесной concurrency — TPL(в базовой библиотеке .Net поставляется) а также async/await на уровне языка.
В Java — там куча асинхронных фреймворков — тот же Vert.x

Думаю правильно будет согласится — что го очень простой язык- и у него есть свои поклонники, просто не всем он подходит/нравится.

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

Это, скорее, проблема с реализацией/кодом, а не c обработкой ошибок.

Есть такие принципы, как «SOLID» — они полезны. А если код (скажем, класс, не говоря уж об одной функции) содержит в себе кучи свистелок-тарахтелок — скорее всего, там нарушение как минимум 2-х принципов («S» и «O») + кучи прочих рекомендаций, типа «KISS».

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

При этом, эксэпшены без сборщика мусора — ведут к многочисленным ликам, т.к. средний кодерок не заботится о написании «эксэпшн-сэйф» кода.
Кроме того, недостатками эксэпшенов являются 1) непрозрачность (т.к. как правило сложно понять, где находится хэндлер и что он делает) 2) сложность в безбаговой реализации компилятора 3) +~10% к тормознутости и размеру бинарников.

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

П.С. Почитал ниже страсти по поводу гошного сборщика мусора...

Если в Го корявый сборщик мусора — я понимаю, почему решили не реализовывать эксэпшены. :)
Абсолютно правильное решение!

Если в Го корявый сборщик мусора — я понимаю, почему решили не реализовывать эксэпшены. :)
Абсолютно правильное решение!

Нет, у причины не добавлять эксепшены корни как раз в непрозрачности и печальном опыте того, как среднестатические программисты их недо или переиспользуют. В Google даже в С++ Style Guide эксепшены давно запретили.

А корявый сборщик мусора в Go только глазами джавистов, которым сложно выбраться из своего bubble. В Go совсем другая модель памяти, и, соответственно, совершенно другие трейдоффы, которые невозможны в джаве.

В Go совсем другая модель памяти,

Вот тут, пожалуйста, подробнее. Что именно тут зовётся моделью памяти (этот buzzword имеет минимум 3 разных значения) и в чём она «другая»? Только без рассказов, пожалуйста, про передачу через каналы — это не имеет отношения к вопросу.

Да причём тут каналы. Под моделью памяти я понимаю паттерны того, как и где выделятся и используется память. В джаве, как я понимаю, объекты создаются на каждый чих, часто и много, и всё кладётся в кучу. В Go же, большинство объектов выделяется непосредственно на стеке, и активно используется escape-анализ, чтобы понять скоуп жизни объекта ещё на этапе компиляции. При необходимости можно вообще писать код, который создаёт нулевую нагрузку на GC. Более того, в Go основные типы — это структуры, которые примерно также близки к железу, как структуры в С, вы можете даже с выравниванием полей играться, и такого оверхеда на создание объекта, как в джаве нет. Также Go умеет делать embedding структур, что тоже избавляет необходимости использовать поинтеры повсюду.
В итоге у Go совсем другой паттерн выделения и работы с памятью, другие размеры необходимой памяти, хехе, ну и фрагментация намного меньше. Поэтому то, без чего GC в джаве просто немыслим — поколения, например, в Go особого смысла не имеет.

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

Это достаточно нестандартное использование этого понятия:), но приму для данной ветки.

При необходимости можно вообще писать код, который создаёт нулевую нагрузку на GC.

На Java тоже так пишут, это достаточно просто, и у меня на работе много такого кода.

Но идею я понял и частично согласен. Да, многие стили с Java и прочими плодят промежуточные объекты, полагая, что GC всё разрулит.

Более того, в Go основные типы — это структуры, которые примерно также близки к железу, как структуры в С, вы можете даже с выравниванием полей играться, и такого оверхеда на создание объекта, как в джаве нет.

Это решается через ByteBuffer — сейчас, и через value types — в будущем. Можно сравнивать не с Java, а с C#, где это решено давно (и то же выравнивание определяется по вкусу программиста).

Оверхед же на один объект должен быть сходен до мелочей во всех языках с GC.

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

А вот это сомнительно — больше похоже, что таки первична попытка оптимизации под минимальные задержки.

А вот это сомнительно — больше похоже, что таки первична попытка оптимизации под минимальные задержки.

Ну так generational GC как раз тоже ради уменьшения задержек, как я понимаю, и нужен, только он эксплуатирует предположение о том, что большинство объектов короткоживущие.
В го очень сильно уменьшили паузу (с секунд на 100+GB хипе до 100 микросекунд на 500+GB) после Go 1.5, имплементировав конкурентный сборщик мусора, который жертвует немного CPU (на практике около 0.1%), но основную работу делает параллельно с основным кодом. Для этого, кстати сам Go был переписан (точнее транслирован) с С на Go. А так да, в Go сделан приоритет на предсказуемость задержки.
При этом там еще масса пространства для оптимизации (чем Рик Хадсон и ко занимаются).

тогда эксэпшены были бы терпимы (добавление их в «плюсы» это был фэйл, на мой взгляд).

Добавление исключений в C++ было неизбежно за счёт того, что иначе в принципе не было метода передать ошибку из операций типа a+b, если «+» переопределено для них. Тут в принципе нет места для иного представления неожиданного результата.

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

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

Да. Но это достаточно легко свести к обёрткам на границе. И чем лучше обработка исключений в основном коде, тем эти обёртки легче и осмысленнее. В этом смысле, да, система исключений «инфицирует» среду, и это многим не нравится.

Кроме того, недостатками эксэпшенов являются 1) непрозрачность (т.к. как правило сложно понять, где находится хэндлер и что он делает)

Так не надо вообще особо решать задачу «кто поймает исключение, порождённое в точке X», это не какая-то исключительная (не каламбур) задача. Передача кода/объекта ошибки и передача исключения наверх — идентично по последствиям для данного вопроса. Это или решается в том верхнем уровне, или неважно, если мы смотрим только на нижний уровень.

2) сложность в безбаговой реализации компилятора

Тут согласен — полный набор мер очень обширен.

3) +~10% к тормознутости и размеру бинарников.

Скорость — давно не падает. Это было существенно во времена sjlj exceptions. Сейчас main path не замедляется.
Размер — может быть, при кривых реализациях, и 10%, согласен (а для Java придумывали варианты экспоненциального роста). В нормальных, как я слышал, 2-3%, не больше.

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

Без GC — да, проблемно. Для C++ давно разработаны методы против этого (RAII, unique_ptr с компанией, boost::scope...), но им надо учиться и следить внимательно за качеством выхода.

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

Как говорится, complexity is a symptom of confusion, not a cause.
Вот этот кейс (когда нужно много однотипных вещей сделать в одной функции) — обычно признак корявого дизайна, и я, если вижу более 3-х подобных вызовов, идущих друг за другом, уже задумываюсь над тем, как можно это абстрагировать в более понятное что-то. В 90% случаев осмысление и рефакторинг избавляет от этой простыни.
В тех же случаях, когда такое действительно имеет место быть (например, нужно сделать 15 подряд вызовов функции, которая может вернуть ошибку — скажем запись последовательности байт кастомного протокола, сильно не наабстрагируешься, сложность идет из самого определения задачи), то есть масса вариантов, как можно улучшить читабельность кода, не жертвуя при этом обработкой ошибкой. И это исходит из того, что — сюрприз — ошибки в Го это такие же значения, и можно ими оперировать как угодно, и для этого ничего не нужно нового учить и специальных лекций и книг читать. Банальный пример — анонимная функция перед этой простыней однотипных вызовов, которая заворачивает в себя проверку на ошибку. Если вызовы эти друг с другом слабо связаны — можно создать свой тип MultiError и аггрегировать все ошибки, и в конце вернуть его, в котором будет слайс из всех ошибок на этапе выполнения. Можно вообще сделать отдельной горутиной обработчик ошибок, и их плевать в канал в этой анонимной функции.

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

Все языки, программирования эволюционируют и пытаются привнести новые /хорошо забытые старые идеи.

И всё же, Go тут выделяется, потому что сознательно положил болт на почти все новинки новых теоретических изыскателей Programming Language Theory, и руководствовался только практическим опытом авторов, накопленных за много десятилетий практического опыта. Именно поэтому столько места в Go занимают решения основанные на социальном контексте программирования (promise of compatibilty — мы (почти все) знаем кумулятивные потери от устаревших туториалов, кодовых баз которые уже не компилируются и ада с «не той версией», go fmt — срачи надоели, go test/bench — надоело, что программисты не пишут тесты, потому что накладно, go doc — который генерирует шикарные доки из комментариев без всякого специального синтаксиса, простота грамматики — AST-парсер из стандартной библиотеки очень легко позволяет делать адски крутые static analysis тулзы, простота самого языка — меньше когнитивной нагрузки, меньше двумысленности и тд). Если честно, я не знаю, какой другой язык таким может похвастаться. Большинство языков создаются фанатами компиляторов, которые живут в своём мире.

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

Есть несколько простых «лакмусовых бумажек» практического опыта, и первая тут срабатывает идеально: это восьмеричные константы с ведущим нулём. Сколько из-за них седых волос и потерянных ночей — страшно посчитать. В правилах MISRA C такие константы запрещены категорически, несмотря на то, что для embedded есть много мест, где бы это представление подошло. В современных языках пытаются от них избавляться всеми силами (как Python, Swift — или особый префикс, или вообще запрет). Но авторы Go, несмотря на то, что по выходу языка им только ленивый не указывал на эту проблему — сохранили их и послали нафиг все возражения.
Второй лакмус — незакрытые управляющие структуры. После того, как на них обжёгся Вирт — в Modula, Oberon оставил только явно закрытые — но было поздно, Паскаль ушёл в широкое развитие. Авторы Go знали это — и тем не менее повторили их со всеми возможными проблемами типа неуместно висящего else.

Когда после этого начинают говорить о «практическом опыте» авторов Go — остаётся только смеяться — потому что такое могут делать не опытные практики, а сенильные олухи. Как минимум один такой там точно есть, и уже напаскудил.

простота грамматики

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

это восьмеричные константы с ведущим нулём

Вы лучше про ТАКИЕ «лакмусовые бумажки» никому не рассказывайте. Это знаете как, когда реальных проблем нет, начинают придираться к реально незначительным вещам. Записал себе в TODO «встретить хоть одного человека, который хотя бы раз обжегся на восьмеричных константах». Отпишусь, если встречу.

типа неуместно висящего else.

Это, вообще, как?

Когда после этого начинают говорить о «практическом опыте» авторов Go — остаётся только смеяться — потому что такое могут делать не опытные практики, а сенильные олухи. Как минимум один такой там точно есть, и уже напаскудил.

Да, это всем известно. Остаётся только быть снисходительными к ним, не всем легендам computer science удаётся достичь уровня Валентина Нечаева.
Кстати, можно будет вас пригласить провести семинар по дизайну языков программирования для Go team? Перелёт и проживание оплачиваем. У вас реально есть шанс повлиять на развитие языка.

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

Не забывайте, что Go писали «сенильные олухи», они таких и слов-то не знают. Будьте снисходительны.

Вы лучше про ТАКИЕ «лакмусовые бумажки» никому не рассказывайте. Это знаете как, когда реальных проблем нет, начинают придираться к реально незначительным вещам.

Были бы незначительны — не было бы правила у MISRA. У меня к ним как-то больше доверия, чем к Вам :)

Это, вообще, как?

Хм, кто-то говорил о годах практического опыта? ;)

Остаётся только быть снисходительными к ним, не всем легендам computer science удаётся достичь уровня Валентина Нечаева.

Ну опять приём «отсылка к авторитетам». «Скучно.» (© некто Иван Данилюк)

Кстати, можно будет вас пригласить провести семинар по дизайну языков программирования для Go team?

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

Не забывайте, что Go писали «сенильные олухи», они таких и слов-то не знают. Будьте снисходительны.

Верно — его писали их молодые клевреты. Снисхождение — зачем?

У меня к ним как-то больше доверия, чем к Вам :)

Кто-то там не любил отсылку к авторитетам. Выборочно, надо полагать.

Хм, кто-то говорил о годах практического опыта? ;)

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

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

Не знаю, я как-то ужинал с Пайком и его женой, и они отличные слушатели, уверяю. Может дадите все же шанс? Такой ум и опыт как у вас бывает раз в 100 лет, нельзя же пропадать добру.

Кто-то там не любил отсылку к авторитетам. Выборочно, надо полагать.

Да. Потому что у упомянутой организации понятная логика функционирования, процедуры работы, входные данные и результаты — это можно всё самому проверить (да, с затратой времени, денег — но это делается), наконец, известны случаи подтверждения типа «не выполняли и вот докатились» (педаль газа у Toyota). А у авторов Go чёрный ящик неизвестной конструкции.

Может дадите все же шанс? Такой ум и опыт как у вас бывает раз в 100 лет, нельзя же пропадать добру.

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

(педаль газа у Toyota).

Я пытаюсь вспомнить как эта логическая ошибка называется. Тоесть вы берете пример просто адового говнокодинга, говорите «оно не соответствовало MISRA C» и из этого делаете вывод, что «MISRA C заслуживает уважения и доверия»?
Не поймите меня неправильно, к таким вещам как MISRA C я отношусь уважительно, но ваш пример это как увидеть бомжа, сказать «он не вкладывал в МММ» и этим доказать, что МММ стоит доверия. Мда.

чем несколько минут по сети в расслабленный субботний вечер

Человек, который не пишет на Go, не любит Go, тратит суммарно часы своего времени, чтобы набрасывать на Go, и оправдывать себя «несколькими минутами», «субботним вечером» и «под настроение», хахаха :) Еще забыли добавить «с бокалом красного вина и у камина», ага.

Тоесть вы берете пример просто адового говнокодинга, говорите «оно не соответствовало MISRA C» и из этого делаете вывод, что «MISRA C заслуживает уважения и доверия»?

Не «из этого», а это работает дополнительным фактором, подчёркивающим вывод, сделанный независимо от него.

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

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

Человек, который не пишет на Go, не любит Go, тратит суммарно часы своего времени, чтобы набрасывать на Go, и оправдывать себя

Я никого и ни перед кем не оправдываю:) не хватало. Цель дискуссии — сбор аргументов и доводов, ну и из «общественно полезного» — стимуляция критического мышления (в отличие от поклонения авторитетам, столь характерного для Go-тусовки). А под что я буду их использовать у себя — уже посмотрим :) Может, судьба занесёт и к этому... хм... средству, тогда буду знать, где грабли зарыты. (Надеюсь, что в нынешнем виде — таки не занесёт.)

Ну а на тему «не любит Go» — слегка перефразируя незабвенного Бутенко, любить надо женщин и алкоголь (да-да, ниже про вино Вы как раз вовремя вспомнили), а ОС и языки — использовать.

Еще забыли добавить «с бокалом красного вина и у камина», ага.

Жаль, камина нет. Но я запомню оборот на будущее :)

Может, судьба занесёт и к этому... хм... средству, тогда буду знать, где грабли зарыты. (Надеюсь, что в нынешнем виде — таки не занесёт.)

зря надеетесь. Если в течение этого года вам не придется иметь дело с кодом на go, то в июне 2018 года проставлюсь 15-летним виски.

Угадал все буквы, 18 года ждать не пришлось)
Какой вискарь?

Когда после этого начинают говорить о «практическом опыте» авторов Go

когда вышел Go, посмотрел я его, почитал немного, и у меня возникло ощущение что авторы в 70ых куда-то удалились, и вот вернулись, и продолжили то на чем они там, в 70ых остановились.
когда же поднялась дискуссия, они подтвердили, что да, мы решили вернуть вас «в старые добрые времена! и мы таки вас туда вернем, как бы вы не вопили!»

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

меня не убеждают.

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

На моем опыте Go хорошо заходит тем, кто:
а) много лет набивал шишки на других системных языках и понимает боль, которую решает Go
б) тем, кто не считает себя умнее всех на свете
в) прагматикам, которым важен качественный результат, а не фанатичная вера в одну привычную технологию.
г) тем кто любит решать проблемы, а не воевать с фреймворками/языками, короче получать fun от программирования.

Как-то так.

Никто ничего никому не должен.
Авторы Go любят ретро — их право.

Остальное пацанячее опускаю.

Хм, а тогда и все.
Да, разве что, фроненд не пишу(на ноде тоже), если это важно.

И всё таки, что имелось ввиду под

неуместно висящего else.

?

Это спорный вопрос. У каждого языка есть свои методы обработки ошибок и не факт, что добавление блоков try/catch/finally лучше чем if err != nil.

Оно лучше, потому что после очередного наворота конструкций «опознать ошибку, а если мы не знаем, что это — отдать дальше» станет понятно, что это try-catch и получился, только доморощенный и кривой. Как оно и происходит в реальных проектах на C и прочих языках без исключений.
Я этих закатов солнца вручную насмотрелся во всех стилях.

Для начала, поскольку в Go ошибки это не какая-то специальная конструкция языка, то вы вольны делать с ними что угодно — отнюдь не только «пробрасывать наверх». Вы можете их анализировать, передавать выше по стеку, логгировать, отправлять в канал ошибок, группировать и тд. Ошибки это просто значения. это интерфейс. Поэтому, то что вы насмотрелись в С, где есть только return codes, совершенно отлично от того, что есть в Go. Неверно судить о Go по опыту в С. Это как судить о Тесле по опыту в Жигулях. Но дело за вами, конечно.

Для начала, поскольку в Go ошибки это не какая-то специальная конструкция языка, то вы вольны делать с ними что угодно — отнюдь не только «пробрасывать наверх». Вы можете их анализировать, передавать выше по стеку, логгировать, отправлять в канал ошибок, группировать и тд.

Я могу это точно так же делать в Java, Python и почти всех прочих, где есть механизм исключений. Кого и чем Вы хотели удивить?

Поэтому, то что вы насмотрелись в С, где есть только return codes, совершенно отлично от того, что есть в Go.

Я насмотрелся в Фортране (переходы по меткам), C (не обязательно return codes, есть и другие методы), исключения-только-тип, исключения-объект... А Вы себе домысливайте дальше про чужой опыт, домысливайте.

Это как судить о Тесле по опыту в Жигулях. Но дело за вами, конечно.

Верно — Жигуль тут Go, и мне такое не нужно.

Я могу это точно так же делать в Java, Python и почти всех прочих, где есть механизм исключений. Кого и чем Вы хотели удивить?

Не уверен, что вы поняли мессдж. Почитайте paper выше о статистике реального использования эксепшенов. Дело не в том, как *вы лично* можете использовать, дело в том, как реальные люди это используют в массе. Вы можете постичь дзен эксепшенов, пройти десять семинаров и прочитать 150 книг о том, как правильно использовать эксепшены, но 80% менее талантливых, чем вы, программистов, будут использовать их путем наименьшего сопротивления. Собственно, статистика об этом говорит. А мы говорим о дизайне языка, а не о вас лично.

Я насмотрелся в Фортране (переходы по меткам), C (не обязательно return codes, есть и другие методы), исключения-только-тип, исключения-объект... А Вы себе домысливайте дальше про чужой опыт, домысливайте.

Интересно будет, что вы скажете, когда вы «насмотритесь» на использование goto в Go. Я прямо вижу как вы стараетесь, пытаетесь объяснить отличие от того, на что вы насмотрелись в Фортране.
Но вы продолжайте держаться за прошлый опыт, ограждая себя от нового опыта, продолжайте.

Верно — Жигуль тут Go, и мне такое не нужно.

Это радует.

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

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

А мы говорим о дизайне языка, а не о вас лично.

Именно. Дизайн, в котором маскировка видна как специальные конструкции — помогает её вычислить и обезвредить.

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

Если Вы всерьёз считаете, что Go — это новый опыт в плане обработки ошибок, то у меня для Вас плохие новости. :)

Дизайн, в котором маскировка видна как специальные конструкции — помогает её вычислить и обезвредить.

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

Если Вы всерьёз считаете, что Go — это новый опыт в плане обработки ошибок,

Я то могу сравнивать, писал 13+ лет на С, С++, Python и Go. А вы пока оперируете лишь своими домыслами о том, «как оно там в Go», обещая мне принести «новости». Ну-ну.

Я то могу сравнивать, писал 13+ лет на С, С++, Python и Go.

Что, померяться длиной стажа решили? У меня больше получится :)

А вы пока оперируете лишь своими домыслами о том, «как оно там в Go», обещая мне принести «новости». Ну-ну.

Ну, если для Вас это таки новый опыт... «Хорошая штука склероз, каждый день что-то новое» (tm)

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

Аргументы в студию. Без таких обзорных статей, как Вы тут размахивали.

Что, померяться длиной стажа решили? У меня больше получится :)

Нет, я вам пытался донести, что я могу сравнивать разницу между С и Go на своем опыте.

Ну, если для Вас это таки новый опыт.

Под словом «это» вы подразумеваете вашу личную интерпретацию того, в чём у вас опыта нет. Скучно.

Без таких обзорных статей, как Вы тут размахивали.

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

Нет, я вам пытался донести, что я могу сравнивать разницу между С и Go на своем опыте.

Оно и видно — что этот Ваш опыт позволяет назвать «новым опытом», от которого я «ограждаю себя», редукцию до уровня 68-го года.

Я верю, что языки ранее C вы не видели, но хотя бы почитать критику Go могли бы.

Под словом «это» вы подразумеваете вашу личную интерпретацию того, в чём у вас опыта нет. Скучно.

Вы ничего про меня не знаете, но утверждаете, что у меня нет опыта в чём-то. Скучно.

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

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

про сборщик мусора особенно поржал, люблю пионеров в IT

Ещё один джавист, который думает, что знает о сборщиках мусора всё, потому что потратил годы на зубрежку параметров тюнинга GC в джаве, хаха. Люблю таких октябрят.

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

Пойдите расскажите этим чувакам про офигенный сборщик мусора ГО, а то они так и не осилили как побороть его мемори лики и недоумевают почему hello world на го отъедает 300 ГБ памяти

Ха, спасибо за статью, кстати, не видел. Когда он начал писать про слайсы, уже было понятно, в чем причина их проблемы. Это одна из самых известных и популярных gotchas в Go, и, к вашему сожалению, дело там не в GC, а в не знании авторами того, как работать со слайсами.

Давайте реальный наброс на гошный GC лучше. Go team на самом деле ищет таких, у которых хип под терабайт и изо всех сил пытаются найти кейсы в которых пауза stw будет больше 100 микросекунд. Так что буду признателен.

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

Но да, вам же сказали что это катинг эдж cs

Линк в студию, где нам сказали, что это cutting edge cs?

Если бы вы были чуть умнее, и действительно послушали, что в Go коммьюнити говорят и пишут про GC, то нашли мы отличные статьи и доклады о том, какой в Go сборщик, почему он именно такой, почему в го не нужны поколения, какие трейдоффы были сделаны с учетом memory layout го, почему и как удалось добиться пауз меньше 100 микросекунд даже на сотенногигабайтных хипах, почему в Go нету этого ада с сотней параметров тюнинга GC и почему единственный параметр позволит Go программам работать даже в будущем с памятью на порядок больше нынешних.

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

аааааааа бл я не могу, он поехавший еще хуже первого.

Ага, это тут местный авторитет по «умению общаться», понятно. :)

Так где там линк с пруфом? Ну хоть один, а?

Расслабьтесь сэр. Это воин одного наброса.

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

пруфом чего? Того что у го gc рвет всех и вся? Ну так нет таких пруфов, нет

Долго будешь увиливать?
Пруф того, что "

Но да, вам же сказали что это катинг эдж cs

blog.golang.org/go15gc

Go is building a garbage collector (GC) not only for 2015 but for 2025 and beyond: A GC that supports today’s software development and scales along with new software and hardware throughout the next decade. Such a future has no place for stop-the-world GC pauses, which have been an impediment to broader uses of safe and secure languages such as Go.

Go 1.5’s GC ushers in a future where stop-the-world pauses are no longer a barrier to moving to a safe and secure language.

Що ж реально відбувається? Хлопці заоптимізували GC під хорошу latency на шкоду throughput і пафосно розповідають про GC майбутнього:

blog.plan99.net/...​e-collection-911ef4f8bd8e

Так ви самі прочитали ці статті? :) Чи просто вичепили фразу з першого абзацу і далі домислили?

Обидві ці статті, по-перше, доводять саме той поінт, що в Go комм’юніті ніхто не каже, що GC cutting edge — а навпаки, пояснюють, що взято давню технологію, чому саме її і дають базові розуміння компроміссів у GC. Я просив того фанатичного джавіста-хейтера надати лінк, де кажуть саме те, що він собі надумав.

По-друге, у першій статті пояснюється, чому Go GC позиціонується саме як довгострокове рішення, і, навіть відклавши в сторону питання, чи правильне рішення, чи ні, але сам факт, что дизайнери думають наперед на 20-30 років, це вже про щось говорить. І якщо коротко, то ідея в том, що програма написана і скомпільована зараз, зможе завтра працювати на залізі на порядки потужнішому, і достатньо буде лише підтюнити одну змінну, щоб досягти потрібного балансу latency/throughput.

Ще питання?

А можно я наброшу про питон, авс лямбда и серверлесс?

Позволю себе дать еще раз ссылку.
На все Штаты по Golang аж 61! вакансия
www.indeed.com/...​bs?q=title:golang&l=&rq=1
Для сравнения — С# - почти 2000, Java — более 10000 вакансий.

Еще можно попробовать на других сайтах смотреть:

stackoverflow.com/jobs?q=java — 319 результатов

stackoverflow.com/jobs?q=golang — 185 результатов

Только смотреть нужно в заголовке, так — title:golang. Иначе получите просто описание непрофильных требований в вакансии
stackoverflow.com/...​obs?sort=i&q=title:golang — 8
stackoverflow.com/jobs?sort=i&q=title:java — 84

Судя по трендам, пик хайпа гошки уже прошел — trends.google.com/...​ore?date=all&q=/m/09gbxjr

Го растет

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

Падение джавы понятно — котлин, го, скала и тд.

в самом начале графика у Го — 1, у джавы — 96, в конце у го 6, у джавы 22, собственно Го вырос в 6 раз, а джава упала в 4.

В самом начале у Го должен быть 0, так что рост не определен.

Но текущий тренд — отрицательный. Это гораздо важнее исторической ретроспективы.

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

trends.google.com/trends/explore?q=Golang — вот правильный тренд. Уверенный экспоненциальный рост без признаков падения.

ну так все эти сайты на пхп сами себя не перепишут

Не похоже на правду, если смотреть на рост количества проектов на github в разрезе новых языков программирования:
— go — 715 проектов — github.com/...​arch?q=language:go stars>666
— swift — 545 проектов — github.com/...​h?q=language:swift stars>666
— scala — 113 проектов — github.com/...​h?q=language:scala stars>666
— rust — 68 проектов — github.com/...​ch?q=language:rust stars>666

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

1 нет
2 востребован как замена пхп и для сетевых штук
3 нет ( судя по коментам гошники еще и не понимают что такое ынтерпрайз)
4 нет
5 нет
почему местные гоибанаты сачкуют, непонятно

Объективный комментарий джависта/го-хейтера detected.

Ні, це коментар розумної людини, не джавіста а людини, котра бачить оцей голянгачий хайп недочасним та недоречним)))
Валялькин, це ти, зізнайсо))

Хайпа вже давно немає. Людина шось собі бачить, вважає це недоречним, ображає незнайомиїх їй людей через цю свою фантазію, а ви її за це розважливо називаєте розумною.

Це було дуже точне визначення терміну «упоротість». Дякую за чудовий приклад. Є користь!

я с этими ’незнакомыми’ наобщался в других темах достаточно что бы убедитсья в их полной и глубокой невменяемости ( и полному отсутвию умения общаться, так что других ярлыков они не заслужили )

Судя по всему, себя вы относите к тем, кто «умеет общаться»? Ну-ну, на этом и закончим диалог..

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

Да мне всё равно, кто с вами и как общался — я вижу как вы общаетесь сейчас. Приятно не иметь дела с такими людьми.

Валялкина 3 дня нет, он в порядке?

сломался?
может на галоперидоле наконец то

Постараюсь наверстать упущенное :)

Постараюсь наверстать упущенное

Давно пора, а то тут пользуясь случаем, уже пишут, будто бы Go не подходит для разработки в интерпрайзе. Хотя совершенно очевидно, что лучшего языка для интерпрайза — не найти. Это следует хотя бы из того факта, что Go уже уверенно уделал scala, и стремительно теснит джаву. Программисты которой кусают локти, и не знают как бы перейти на Go так, чтобы бремя джава-кода из прошлого не отягощало дальнейшую разработку.

Подскажите где с качать конвертер кода с Java на Go

Сначала конвертируете Java код в C с помощью github.com/raphaelcohn/java2c
Затем конвертируете С код в Go с помощью github.com/elliotchance/c2go

Сначала конвертируете Java код в C с помощью github.com/raphaelcohn/java2c

„Obviously, this isn’t perfect. Currently, it’s designed to use a subset of java — a dialect.”
репа дохлая с 14 года

Затем конвертируете С код в Go с помощью github.com/elliotchance/c2go

„The ultimate milestone is to be able to compile the SQLite3 source code and have it working without modification. This will be the 1.0.0 release.”
текущая версия: 0.13.3
возраст проекта — 3 месяца

вобщем придумай что-то повеселее))

не стоит забывать при этом что Go ужасен

Если сравнивать с плюсами то да — все так просто и очевидно. Нужно больше сложности.

то что он примитивный не делает его автоматически хорошим

а что нибудь по существу ответить?

Ни чем в своей области применения. А в других он там как седло на корове выглядит.

1. В языке который позиционируется для много поточных програм нету immutable данных
2. Нет генериков
3. Каналы тормознутые
там еще можно много много писать про кривое ООП или стремную систему пакетов в которой нету относительных импортов, но самое главное что Go это шаг назад в 70тые это регресс и деградация.

Почти по учебнику: divan.github.io/posts/go_complain_howto
Хотя иммутабилити это да, новый rant. Спасибо, надо будет обновить учебник.

там по ссылке в гистограмме есть no immutables, не читаем свою же статью

> divan.github.io/posts/go_complain_howto
> Gopher. Figure skating enthusiast.

і вас ця хороба заразна вчепила, писати про себе в третій особі, і добавляти ентузіаст ?
:-)
блог енд форум рідінг ентузіаст
кофі ентузіаст
і прочая

О, спасибо, новый хипсто-оборот есть, до этого было только ninja and artisan + enthusiast

Ентузіаст не значить просто «мені це подобається», фігурне катання в моєму житті займало і займає дуже велику роль, катався сам, розвивав ФК в Україні, писав статті, робив відеотрансляції, входжу в міжнародну спілку спортивних журналістів, і пишу софт для різних аспектів фігурного катання. В чому власне, проблема?

В чому власне, проблема?

у тому, що

і вас ця хороба заразна вчепила, писати про себе в третій особі, і добавляти ентузіаст ?

А де там третя особа, підкажіть будь ласка? І як потрібно було правильно «по-здоровому» написати?

по здоровому — це не мавпячити до оскоми так як інші хіпстери пишуть :-)

мавпячити до оскоми

Я навіть не уявляю, що ви маєте на увазі під цим.

Будь які соц.мережі та ресурси у профілях мають поле «Bio» де закликають людей вводити коротеньку інформацію про себе. Це нормально і зручно. Якщо я хочу написати що я гофер і ентузіаст фігурного катання, то я так і пишу — gopher. Від першої особи («я є гофер»).
В третій особі лише пишу в більш розгорнутих біо для конференцій — точніше редактори самі наполягають на цьому (я взвгалі використовую шаблон, який про мене написали O’Reilly — власне третя особа звідти і йде)

Поясніть мені будь ласка, де тут «хвороба», де тут «третя особа» і що таке «мавпячати до оскоми», бо ми справді говоримо різними мовами.

шаблон, який про мене написали O’Reilly — власне третя особа звідти і йде

ааа, ок, буду знати, хто це започаткував

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

Спорим, будут тонны счастливых соплей, когда выйдет вот это? www.jetbrains.com/go

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

Никто такого не говорит, но есть разница между «языком в котором невозможно работать без IDE» и «языком, в котором спокойно можно работать в любом нормальном редакторе», согласитесь.

Gogland давно уже в ходу. Люди, которые привыкли к джетбрейнсовских IDE очень рады, да.

Перечитал внимательнее хауту, да, ок

Было бы любопытно пару сервисов на работе переписать, т.к. для Go просто джекпот. Базы нет, полный stateless и concurrency

Тогда Go Tour (tour.golang.org/welcome/1), Effective Go (golang.org/doc/effective_go.html) и велком в слак-чатик по любым вопросам, подскажем (gophers.in.ua)

Говорят за бугром перспективы есть.

Во-первых, Go можно выучить всего за пару дней максимум, по урокам на официальном сайте, там же можно потренироваться писать код ничего не устанавливая. Так что ответ на вопрос стоит ли изучать — очевиден, конечно стоит, поскольку в любом случае это не отнимет много времени. Во-вторых, не обязательно искать вакансии с требованием именно к Go, нередко нужно решить какие-то задачи без привязки к языку, и для их решения можно сделать отличный выбор в пользу Go, код на котором можно писать быстрее и эффективнее, чем на других языках. В-третьих, тут всё намного проще, на гитхабе достаточно библиотек на любую тему, которые можно скачать через go get, и тут же сразу юзать. Это заметно отличается, допустим от разработки на C++, где установка любой новой библиотеки требует ещё пляски с бубном, чтобы хотябы скомпилировать. Go — самодостаточен, код на других языках писать не обязательно для backend, но можно при желании. Есть возможность встраивать код на C прямо в исходниках Go, который компилится через gcc, ну и кроме того, можно эмбедидь скрипты. Так что любой проект, вместе с frontend, может запросто содержать код на нескольких языках сразу, и это нормально.

Если вместе с жабой /гадюкой / ещё чем, почему нет.

1. Из личного опыта — можно использовать чисто его. Но некоторые вещи логичнее делать на каком-то python/ruby/js. Например нету смыла админку для какого-то процессинга пилить на Go только потому что сам процесинг на нем.
2. Если сравнивать с js — то нет) Если же говорить о возможности устроится разработчиком — как нефиг. Конкуренция низкая, а проектов уже тонны.
3. Из того что знаю точно:
Uber/Docker/Gogs/juju используют основным и помимо того свои либы выкладывают.
FB/Percona используют точечно.
Еще знаю 2, которые используют исключительно Go на бекенде для реализации закрытых проектов.
4. В Украине точно SoftServe/Ciklum/ZeoAlliance + еще жменька стартапов и мелких продуктовых компаний.
5. Пол года уже только на нем сижу. Причин возвращатся на python не вижу.
Попробовать базу: tour.golang.org
Для большего понимания что внутри: golang.org/doc/effective_go.html
Грабли: go-traps.appspot.com
Рассылка самого актуального за неделю: golangweekly.com
Ну и комьюнити всегда можно спросить: golang-ua.slack.com

Сам интересуюсь golang. Перспектив в скором и широком развитии в Украине не наблюдается.Пробовал найти работу в своем регионе — не получилось.Поиски прекратил.

На Апворке заказы, тем временем, начали появляться. При чем требования к Го-дэвам по икспириенсу выставляют не такие уж малые.

Это самое главное. Экспириенс нормальный на GO можно получить когда вы проработали в нормальной конторе над нормальным проектом и при этом вы прочувствовали ту узкоспециализированную область где GO необходим.Это можно получить в Украине?Наверно да. но масштаб не тот.Это не ширпотреб.В Украине нет широкого рынка где можно было бы получить данный опыт.И при «украинской культуре» производственного процесса это невозможно(может лет через 5 что то изменится, не раньше)

Норм все с Golang. Учить стоит даже просто для себя — там и учить то собственно нечего :-)

1. Надо знать тематическую область. На каком конкретно языке писать — вторично, хотя желательно уметь делать хотя бы базовые вещи на нескольких.
2. Востребован.
3. Докер это энтерпрайз?
4. Такие же как в Штатах, но с опозданием года на три.
5. Да, но отнюднь не для бекенда.

5. Да, но отнюднь не для бекенда.

А для чого?

Все что можно сделать на Питоне, но быстрее.
Все что можно сделать на С, но удобнее.

Чесно кажучи, я чекав більш конкретної відповіді.

P. S.
Не думаю що на Go швидше писати ніж на Python.

щас набежит Валялкин и все расскажет)))

Чтоб все комментаторы тут делали такие охрененные проекты, как Валялкин. :)

Подписаться на комментарии