Стоимость разработчиков связана не с числом знающих язык (язык там очень простой), а с примитивностью языка, свежестью   экосистемы и отсутствием выстроенных best practice.
То есть тот же kotlin или даже java (да и C#) имею гораздо более мощную и отлаженную экосистему, в которой многие стандартные вещи уже решены, а в go - еще нет

Нет ни сейчас, ни в 2014-м году такой возможности написать в договоре.

С тезисами про "проще, дешевле" я скорее соглашусь, а без ошибок - нет. Чудес не бывает.
Для меня были важны два момента:
1. насколько интуитивны эти ошибки. То есть провоцирует ли язык ошибки при его "наивном" использовании.
2. насколько tooling готов к их поиску и устранению, то есть во что обходится их устранение их кода.

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

Гм, а что такое "выстроенная best practice" ?

Например, требования к форматированию (расположению фигурных скобок) - это best practice?

Скорее нет, это просто про стиль.
Ну вот смотри, в Java лет 10 ушло на выстраивание консенсуса (вернее нескольких) про использование exceptions в коде и вообще про работу с ошибками. Примерно столько же ушло на выбор нормальных практик для DI, для работы с БД и так далее.
В go пока еще такого консенсуса (с соответствующими библиотеками) не сложилось.
Я думаю, что go станет подходящим вариантом для эффективной разработки для web-like app года через три-пять.

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

Вот твой пример про "горутина вместо очереди" - это как раз про эти best practice )

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

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

Возможно, именно от этого в .net я и пытался спастись.
Есть практики, которые Microsoft считает правильными и изменить их тяжело и/или это делается неочевидным образом (магия).
В том случае, если для моей архитектуры это не удобно, я оказываюсь "не в струе" и имею кучу головной боли. То есть я готов платить более низкоуровневым кодом за то, чтобы иметь, больше контроля.

Ну, вот про это я и имею в виду "нет best practice". Это очень похоже на подходы времен Java 1.1 (да и весь go иногда похож на java 1.1)

(Собственно, текущий подход к обработке ошибок - их надо обрабатывать там, где есть смысл, а это обычно сильно выше того места, где они возникли. Потому и потихоньку умерли checked exceptions)

Они есть, просто не похожи на принятые в Java-мире.
"Возвращайте ошибку последним результатом функции" - чем не best practice?

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

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

Это очень примитивный подход.
Ошибки бывают разных типов:
- исправимые в данном code scope;
- неисправимые в данном code scope;
- фатальные.

Первый тип ошибок нуждается в return code.
Исключения нужны для последних двух.

Язык без исключений так же ужасен, как и язык только с исключениями.

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

Не говоря уже о необходимости в манки-кодинге.

Простой пример: невозможность выделить память - фатальная ошибка.
Невозможность открыть файл — неисправимая в данном code scope ошибка.
Таймаут чтения из сокета или пойманный EINTR — исправимая ошибка.

Использовать исключения для отлова EINTR — безумие.

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

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

В go есть паника, которую можно перехватить. Это некий аналог исключения, хотя и корявый + не рекомендованный для такого использования.
Ограничение - нельзя поймать панику из другой горутины.