Отложенное освобождение ресурсов хорошее. panic и recover как-то удивительно сделали, я не совсем понимаю преимущества относительно работающей во многих языках идиомы try / catch.
Роб Пайк недолюбливает эту идиому как раз из-за того, что наличие управляющей структуры try/catch/finally приводит к злоупотреблению исключениями и смешению с ошибками.
Поэтому чтобы уменьшить это злоупотребление повышена гранулярность: с блока до функции.
Есть много споров на тему, нужно ли обязывать пользователя контролировать исключения try-catch блоком, или же делать это по усмотрению. Преимущество первых даже не в том, что обязует пользователя сразу писать безопасный код, а в том, что пользователь видит сразу все типы исключений, выбрасываемых всей цепочкой функций.
Не знаю как для Пайка, но для меня try-catch-finally блок имеет гораздо более понятную и логичную структуру, чем defer: код, который идет ниже, выполняется всегда позже; тогда как выполнение defer скачет. Вообще в Go создает впечатление некоего компилируемого скриптового языка, нежели современногоязыка программирования.
У меня друг так говорит. Но это как-то не по-русски. Есть, кстати, очень похожий русский термин — волокно (поток, переключаемый приложением, у волокон в одном потоке общий TLS). Так что можно называть их go-волокнами.
Я не совсем понял вопрос, потому отвечу в рамках своего разумения:
у функции одно возвращаемое значение, оно именованное.
Когда пишем return 1; компилятор догадывается, что мы возвращаем именованный возврат в i;
И при выходе из функции значение с именем i равно 1;
Обработка ошибок в Go: Defer, Panic и Recover