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

Beginner level (синтаксис языка):

1. Начать с golang-book.ru . Это на русском и довольно неплохо для начинающего.

2. https://golang.org/doc/effective_go.html - это уже на английском, но всё равно толково и хорошо заходит после 1-го пункта. Кратко, по делу, без воды, достаточно понятно.

После прочтения этих 2 пунктов у Вас уже будут базовые понятия о языке.

Intermediate level (concurrency - многопоточность):

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

(продолжаем последовательность изучения Go по пунктам):

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

4. M. Curtis - Level Up Your Web Apps With Go
Читал - и не понимал - что происходит? Чувак явно пишет рельсы на Go! Всё такое до боли знакомое... Что такое? А потом смотрю в профиле https://www.linkedin.com/in/mal-curtis/ - так он же пишет на работе на Ruby on Rails! Так что книжка отлично зайдёт рельсовикам, осваивающим Go. Книга неплохая, автор явно старался. Автор, ты хороший человек.

5. K. Cox-Buday - Concurrency in Go. Tools and Techniques for Developers. Книга не очень удачная, но пока я не успел найти что-то получше. Автор - женщина, и глупая. Книга читается мучительно и крайне медленно. Охват материала неплох - но объяснения косноязычные, с водопадом лишних слов и эмоций, примеры кода неоправданно переусложнены, ряд тем вообще остались бы непонятыми, если бы не гугление. Читаю и матерюсь на каждом шагу.
PS Последние 2 главы пошёл уже такой горячечный бред, что я просто не смог заставить себя читать этот ужас. Бросил. В общем, далее параграфа Queuing читать не стоит. Книга прекрасно иллюстрирует тезис, что, какими бы умными ни были женщины, они всё равно дуры, и нечего им в программировании делать (кроме разве что 1С).
К сожалению, книгу прочесть всё-таки надо, ибо охват хорош - а заменить книгу особо нечем (в смысле другой книгой, продаваемой за деньги - разве что статьями).

Есть ещё книга N. Kozyra - Mastering Concurrency in Go - но у неё ужасные отзывы - да и я пытался читать другую книгу по Go у этого же автора - и мне также крайне не понравилось.
Смешно сказать - но по Go нет ни одной путёвой книги про Concurrency (единственное, ради чего Go был создан)!

6. Лучшее объяснение Go Context, что я пока видел. Оно даже лучше официального (написанного индусом, и оттого плохого).

7. M. Tsoukalos - Mastering Go - но только Chapter 10: Concurrency in Go – Advanced Topics - и исключая параграф Worker pools (он ошибочный - там ничто не сдерживает размножение горутин - какой же тогда это пул).
Средне-удовлетворительная глава, звёзд с небес не хватает, интереснее всего был параграф Sharing memory using goroutines - частный пример Катькиного Confinement'а.

Advanced level (микросервисы на Go):

Я пытался читать N. Jackson - Building Microservices with Go - это оказалось невозможным, книгу написал какой-то сумасшедший безумец, находящийся в состоянии наркотического опьянения. Отзывы на Амазоне это подтверждают.

Также я попытался читать M. Ryer - Go Programming Blueprints (2 ed) - только главу Chapter 10: Micro-services in Go with the Go kit Framework - не понравилось. Примеры кода сложноваты (автор пытается построить реальную систему - ну и дурак - вместо того, чтобы ограничиться демо-примером), объяснения сопутствующего материала никакие (по сути, их нет). Бесполезная глава. Несколько тем свалены вместе - но ни одна толком не объяснена. Очень слабенький автор.

Вердикт: нормальной книжки по теме "Go микросервисы" пока не обнаружено. Придётся изучать эту тематику из статей и инструкций по использованию микросервисных Go-фрэймворков - вот списочек фрэймворков:

• gRPC (а вместе с этим и его пререквизит - гнуснейшая мерзость protobuf)
  
• Go Micro
  
• Go kit
  
• Gizmo
  
• Kite
  

Я начал с gRPC. Сначала прочёл официальную доку по protobuf (включая раздел о Go). Дока оказалась достаточно вменяемой. Но зато официальная дока по gRPC уже оказалась совершенно паршивой. Там 2 примера - попроще и посложней. Писали доку явно последователи тех, кто писал доку к первому ангуляру (т.е. те, кому я бы отрубил обе руки по самые плечи). Понять что-либо без исходников (к статье) - нереально. Но - исходники ещё надо найти, ибо в статье ссылки на них ... нет. Оказалось, исходники тут: https://github.com/grpc/grpc-go/tree/master/exampl... . Но даже с ними - всё довольно непросто понять - даже в простейшем примере. Потому что авторы умолчали о многих важных моментах. Т.к. им в падлу шевельнуть задницей лишний раз. В общем, есть нужда в нормальном авторе, кто опишет, что такое gRPC. Попробуйте почитать статью от Шизы - это слегка окультуренный сокращённый пересказ сложного случая.

Рассмотрим Go Micro. Продукция очередного кретина (да ещё и спорного качества). Что, скажите, можно понять из таких "объяснений"? Кстати, ищите в Яндексе термин "Service Discovery" - здесь нужно понимать, что это. Посмотрите и Consul. Вот ещё разумная статья о Go-микросервисах. И ещё я понял - без предварительного изучения protobuf и gRPC понять Go Micro будет затруднительно (если вообще возможно). Желаю вам никогда не встретить на работе продукцию этого дегенерата. Go Micro показался мне китайским фонариком со встроенными компасом, радиоприёмником, часами, зарядкой, отвёрткой, точилкой для карандашей, ногтерезкой, и т.д.

Идём дальше. Go kit производит намного более лучшее впечатление. Правда, документация не полная - автору не хватило терпения её закончить. Но всё же разобраться можно - есть исходники-примеры, снабжённые подробными комментариями. Автор мне понравился.

Почитайте полезную статью-сравнение.

Приложение:

Гоняться за русскоязычными книгами по Golang не рекомендую. Я прочёл на русском:
- А. Донован, Б. Керниган - Язык программирования Go
Это совершенно отвратительная бездарная книга.
и просмотрел оглавление русскоязычной книги:
- М. Саммерфильд - Программирование на языке Go
Хотя я её не читал, но беглый просмотр её оглавления создаёт самое негативное впечатление о книге. Такое ощущение, что это целенаправленная диверсия против изучающего golang, с целью развести его на время (прочтения) и деньги (при покупке). Марк Саммерфилд - это профессиональный графоман, посмотрите сами на его карьерный путь: https://www.linkedin.com/in/qtrac/

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

М. Батчер, М. Фарина - Go на практике - на русском языке - эта книга вроде бы достаточно неплохая, но она для опытного разработчика - и она не излагает системно - а отрывисто.

Пытаться читать спецификацию языка также не рекомендую - ничего не поймёте:
https://golang.org/ref/spec

Заключение

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

Англоязычных книг по Golang в электронном виде бесплатно - много, более 30 (а то и под 50). Многие написаны индусами, или оторванными от жизни вузовскими преподами, или какими-то левыми любителями Go (у таких "книг" даже нет ISBN). Есть даже книги, написанные неграми! Все такие книги требуют осторожного выбора. Почему именно Go вызвал у окружающих непреодолимые позывы к графоманству? Такое впечатление, что многие авантюристы решили "срубить баблишка" на "хайповой" теме. Действительно, найти хотя бы нормальную книгу (не говоря уже о хорошей) - оказывается по факту крайне непросто - почему-то именно к Go примазались многочисленные негодяи и бездари - как ни в каком ином языке программирования.

Всё, о чём я рассказал в этом посте, доступно бесплатно онлайн в электронном виде (Либген, к примеру).

В общем-то, основное внимание при изучении Go следует уделить его возможностям по многопоточности (concurrency), которые включают низкоуровневые механизмы (как в C++) типа мьютекса и высокоуровневые механизмы типа каналов. Собственно, это как раз то самое, зачем Go вообще понадобился. Вторая по значимости тема в Go, как мне кажется, это микросервисы.

Я лично думаю, что тесты - это образчик типично западного лицемерия - как в сказке Андерсена "Голый король". Тесты - это чушь собачья (точнее, чушь свинячья). Полезность тестов - вымышленна. Тесты были изобретены на Западе - и они чужды по духу русскому человеку - ввиду своего чудовищного (типично Западного) лицемерия. Сторонники тестов пытаются что-то там такое невразумительное говорить (в защиту тестов) - но никто им не торопится верить - отсюда, собственно, и появился данный вопрос на данном форуме - если бы полезность тестов была реальна - люди бы не спрашивали, зачем они нужны - а просто пользовались бы ими. Все, кто выступает в защиту тестов - я думаю, лишь послушно повторяют цитаты из западных учебников - вместо изложения своих собственных мыслей. Конечно, ведь так хотят работодатели - так как же можно выступить против них?

Где, скажите, убедительно-неопровержимые доказательства нужности тестов как таковых? Их нет. Взамен предлагается просто поверить на слово в "полезность" тестов. Кроме того, написание тестов отнимает уйму времени и само по себе является источником ошибок. Намного быстрее и эффективнее просто проверить руками тот или иной функционал - чем писать для этого тест - как правило, на чрезвычайно неудобном, корявом и глючном тестировочном языке.

Писать же тесты ДО написания кода - это вообще ВЕРХ абсурда. Неужели непонятно, НАСКОЛЬКО противоестественно это занятие? Это просто дичь какая-то. Даже сами западные авторы учебников по тестированию об этом пишут - я прочёл несколько западных учебников по тестированию, пытаясь найти хоть какой-то смысл в тестах - они пишут, что BDD хорошо не более чем в 20% случаев.

Использовать тесты как защиту на будущее - "если что-то поломается при новых правках"? Ну извините, а не слишком ли дорогая цена - для 90% проектов? Да, может быть, на каком-нибудь миллионно-посещаемом сайте это и оправдано экономически - но на подавляющем большинстве сайтов - едва ли.

И вообще - даже если и идея автоматизирования тестирования и носит разумное зерно - почему нужно СПЕЦИАЛЬНО вручную писать тесты? В лучшем случае, это должно быть сделано так: ты тестируешь РУКАМИ какую-то фичу - а программа при этом АВТОМАТИЧЕСКИ запоминает всю последовательность ручных тестировочных действий (и потом воспроизводит при нужде). Только так это имеет право выглядеть. Я немного утрирую, конечно - но суть в том, что это безумный абсурд - писать тесты руками - тратя на это уйму времени и генерируя тем самым новые ошибки.

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

Так что я действительно искренне не понимаю - зачем нужны тесты - и считаю, что они и не нужны на самом деле - а нужны исключительно для введения в заблуждение западных заказчиков - и больше ни для чего. Во всяком случае, в том (нелепом) виде, в котором они (тесты) существуют сейчас. Я же свой код тестирую руками - и это намного лучше и эффективней тестов. Да, я не говорю, что я не тестирую свой код - тестирую обязательно (а как же без этого) - но только руками. Может быть, и есть в отдельных случаях смысл написать именно тест - если руками тяжело и долго воспроизводить тестировочно-проверочную последовательность действий - но это как исключительный случай. Западное же требование покрытия кода тестами под 80-90% - вообще полная чушь - бездумная и шаблонно-тупая. Они ведь там тоже не семи пядей во лбу - а главное, что на Западе категорически запрещено думать своей головой - это только в России пока позволено (и то не каждому, как очевидно).

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

Излагайте свои доводы - но только СВОИ, а не где-то вычитанные.

Моё личное ИМХО:
1. Для того, чтобы выносить мозг нормальным людям при собеседованиях. Это их основная и главная область применения.
А ещё для динамического хранения данных. Смысловой аналог функции malloc в языке СИ, только более извращённо-вывернутый - "недовернувшаяся функция" (т.е. зависшая в памяти по сути). Человек, подвешенный за кишки. Отличие от malloc в том, что malloc просто выделяет кусок памяти под данные - а тут кусок памяти выделен под "данные + их некий обработчик" в одном флаконе.
2. Если говорить о веб-разработке - то на фронтэнде. Если не могут или не хотят хранить данные по-человечески - в куках, локальном хранилище, БД.

Насколько мне известно, бэкэндеру это вообще не нужно - только фронтэндеру. Ведь на бэкэнде всегда есть БД - и эти извраты ни к чему.