Честный взгляд на Go: сильные стороны и болезненные ограничения

Хуже того, Go даже не понимает, что в switch вы хотите исчерпывающую проверку.

Чем default не угодил?

var st State
switch st {
case On: ...
case Off: ...
default: panic("Алярм, всё пропало!!!")
}

Вот про тип error соглашусь, что мешало туда добавить хотя бы код ошибки?

Торчу в Go уже много лет, и я в восторге от него. Тут надо понимать, что много заточено под специфическое серверное мышление.
1. Const/Var местами смешит, но это из-за аллокации в памяти - какие-то "простые" map вообще ни разу не простые. И вообще глобальные значения рекомендованы для точечного осознанного применения, так как создают неявные ошибки.
2. Enum'ов нет, но как их хранить в базе (мы же сервера программируем обычно!)? не в строках же! А в байтах отлично типизированные константы работают. Обработка - тут надо включить параноидальность - придет что угодно, в том числе ошибка. Потому программу пишешь под даже еще не известные значения. В общем, я живу без enum'сов норм, когда завезут - будем жевать. Когда-то и дженериков и итераторов не было.
3. Ошибки в Go нужны для раннего выхода - почти везде return. Если пришла не-nil err, то просто нельзя пользоваться значением, и точка! И пофиг почему. Для пакетов, которые копаются в ошибках, есть структурирование и функции. И если модуль разбирается в сортах ошибки вызываемой функции (конечно, много случаев когда ошибка равна какой-то константе типа "файл не найден"), то что-то не так с разделением логики модулей.
И мне очень нравится императивное программирование в Go. Можно писать просто, и дешевые изменения логики. И видел неудачные фреймворки, которые делают магию - вот это моветон.

var data = map[string]int { ... }func Data() map[string]int { return data }

миль пардон, но как это здесь поможет? Значения map можно поменять точно так же как если бы он был создан через обычный var. Да, само значение data не поменяешь но хрен редьки не слаще. Пример неудачен, имхо - вместо map лучше сделать структуру и копировать ее целиком.

Конструкторы забыли. Вернее их отсутствие.

И невозможность сделать поля структуры обязательными/нет. Это прям ужас. Либо у тебя отдельная функция-конструктор на все случаи жизни, либо рано или поздно забудешь добавить новое поле во все инициализации структуры.

Обработку ошибок в Go ругают, но приведенный пример мне кажется притянут за уши

info, err := os.Stat(root + "/" + path)

if errors.Is(err, os.ErrNotExist) {return false, false, nil}

if err != nil && strings.HasSuffix(err.Error(), "not a directory") {

//^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

//Manually checking if the error is a certain type of error

return false, false, nil }

os.Stat() возвращает вполне информативные типы fs.FileInfo и fs.PathError. Go имеет механизм квалификации стека ошибок который и применен автором errors.Is(err, os.ErrNotExist)
"not a directory" вроде не ошибка для stat а квалификатор, который можно извлечь из fs.FileInfo
Парсить в коде текстовое сообщение ошибки, по моему, дурной тон -- оно нужно для логов и отладки. Как правило, можно обойтись без этого.

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