Почему Go — это хорошо продуманный язык программирования

Если я не ошибаюсь дока должна еще начинаться с названия метода?

// это просто коммент

// DoCool а это информация о работе функции, она пойдет в godoc
func DoCool() {
}

Почему Go — это хорошо продуманный язык программирования

В таком случае придется применить очень длинную строку

a = append(a[:pos], append([]T{x}, a[pos:]...)...)

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

Почему Go — это плохо продуманный язык программирования

Я уже таких выше наплодил) Им нужно с проверками типов во время компиляции)

Почему Go — это плохо продуманный язык программирования

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

Может. Но есть обратная сторона медали, как описали ниже. Невозможно проверить тип во время компиляции, например.

Почему Go — это плохо продуманный язык программирования

Точно, не заметил.

Задача слишком быстро начала обрастать дополнительными условиями) Началось все с «невозможности» обернуть код вставки выше в метод. Дальше понадобилась одна ф-я для нескольких типов, чтобы не «копипастить» метод, потом строгая типизация, далее произвольные типы и типобезопасность.

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

Почему Go — это плохо продуманный язык программирования

Функция не идеальна, но я без малого три дня как начал вникать в go, может более опытные могут сделать лучше? То же можно сделать и в обертке, которую я приводил выше, там был ваш вопрос о типизации.

func insert(s interface{}, pos int, x interface{}) {
	switch a := s.(type) {
	case *[]int:
		*a = append((*a)[:pos], append([]int{x.(int)}, (*a)[pos:]...)...)
	case *[]byte:
		*a = append((*a)[:pos], append([]byte{x.(byte)}, (*a)[pos:]...)...)
	case *[]string:
		*a = append((*a)[:pos], append([]string{x.(string)}, (*a)[pos:]...)...)
	// case ...
	}
	return
}

Почему Go — это плохо продуманный язык программирования

Еще упрощает задачу программисту в поиске мест объявления переменных, всего-то var и :=

Почему Go — это плохо продуманный язык программирования

Я об []interface.

Если существует такая частая необходимость вставки в вашей структуре данных, да еще со множеством различных типов, то почему не сделать тип-обертку над []interface{}

Как-то так

package main

import (
	"fmt"
)

type arr []interface{}

func (a *arr) insert(pos int, x interface{}) {
	*a = append((*a)[:pos], append([]interface{}{x}, (*a)[pos:]...)...)
}

func main() {
	a := arr{1, 2, 3, 4, 5}
	a.insert(2, 77)

	fmt.Println(a) 
 	// out: [1 2 77 3 4 5]
}

Если же планируется применять в паре типов, то сойдет и так:

func insert(a *[]int, pos int, x int) {
	*a = append((*a)[:pos], append([]int{x}, (*a)[pos:]...)...)
}

Почему Go — это плохо продуманный язык программирования

А что мешает использовать интерфейсы?

Почему Go — это плохо продуманный язык программирования

Я не совсем в теме, почему нельзя?

Почему Go — это плохо продуманный язык программирования

И чем оно читаемее, чем код ниже?

a = append(a[:position], append([]T{x}, a[position:]...)...)

С чего начать новичку в Go

Плагин для Sublime — заброшен, но пользоваться можно. Я не советую;

Частично пользовать можно, автокомплиты, автоформатирование при сохранении, быстрое добавление пакетов в импорт, встроенный линтер (лучше заменить на gometalinter) и подсветка синтаксиса.
Сборка в нем вообще никак, пришлось писать свою, ну сборщики всегда пишу свои…

Создаём REST-сервис на PostgreSQL и Rust. Часть 1: прототип

Ну не я разработчик линтера.

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

Создаём REST-сервис на PostgreSQL и Rust. Часть 1: прототип

Анализирует код проекта и выдает список проблем с указанием файлов, номеров строк. В моем случае подсвечивает строки в редакторе (sublime), в которых есть необработанные ошибки.

Создаём REST-сервис на PostgreSQL и Rust. Часть 1: прототип

Go линтеры, вроде errcheck отлично справляются с этой задачей

Уменьшение накладных расходов для утилит на golang

Там же и решение приведено: «Хороший пакетный менеджер».

Уменьшение накладных расходов для утилит на golang

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

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

Уменьшение накладных расходов для утилит на golang

К сожалению не знаком с windows

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

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

Уменьшение накладных расходов для утилит на golang

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

По поводу второго вопроса, попробуйте сделать так (нагуглил):

go build -ldflags "-linkmode external -extldflags -static" hello.go