Где находиться типу: справа или слева?

Для C++ еще есть известный пазл: константный указатель/указатель на константу

int *const p1
int const* p2
const int* p3

Сорри за оффтоп, но плиз, добавьте мягкий знак в слово «находитЬся» в заголовке.

Синтаксис объявления переменных в Си меня вполне устраивает, и я не вижу в нем ничего непонятного; то, что объявление совмещено с выражениями тоже очень удачно.
А вот для функций я бы предпочел ключевое слово func вначале, а возвращаемый тип после агрументов

func foo(int x) int 

принцип очень простой: сначала пишем существующее, затем новое. То есть сначала пишем имя сущности, которая нам известна (ключевое слово или имя типа), а затем вводим новый идентификатор. Лично мне так гораздо понятнее.
Ключевые слова var и let, повсеместно используемые в новых языках (и не только в Go) для объявления переменных, очень удобны для компилятора. Они снимают любые неоднозачности, связанные с разбором: после них может быть только объявление переменных.
Удобны ли они для человека? Думаю, кому как, мне не очень. Но это дело привычки.
А вот объявление функций с ключевого слова было бы действительно удобно — по общему принципу с объявлением структур, классов, перечислений и т.д. Решалась бы путаница с указателями на функции. Упростилась бы работа компиляторов и IDE. Искать объявления функций в коде стало бы легче. Упростилась бы реализация объявления вложенных функций (напомню, еще в Паскале они были, а в современном С++ есть только частный случай в виде лямбд). Появились бы интересные дополнительные возможности: введение имен возвращаемых значений, введение специальных ключевых слов для специальных функций, удобный синтаксис для возврата сразу нескольких возвращаемых значений и т.д.

f func(func(int,int) int, int) int

Вот зачем было в go изобретать велосипед, если уже давно в ML-образных языках используется синтаксис вроде

f : ((int, int) -> int, int) -> int

ИМХО, если хотелось сделать как привычнее, надо было брать синтаксис C. А тут хотели как лучше, явно посмотрели в сторону функциональных языков (да и не только их, любая статья по теории типов пестрит подобной нотацией), но почему-то не захотели вводить двоеточие и стрелочку.

Перепишем вашу сложную функцию на Go

f func(func(int,int) int, int) int

с указанием типа слева

int f func(int func(int,int), int)

и увидим, что и так нет сложностей с прочтением.

Даже если взять более сложную функцию из той же статьи.

f func(func(int,int) int, int) func(int, int) int

(int func(int, int)) f func(int func(int,int), int) 

Так что дело не в бобине.

Вот такие имеет отличия определение переменных в языках семейства C и Go. Очевидно, Go явно в этом выигрывает. Но если теперь вспомнить, какие языки выросли из старого доброго С – это С++, C#, Java — все они используют определение переменных такого типа.

Очень «тонкий» намек на преимущества Go, по сути бред.
Сложность типов в C вызвана тремя компонентами:
1) Указателями и повсеместным их использованием
2) Отсутствием нормального описания функционального типа
3) const

В C# и Java всего этого нет, поэтому и проблем с описанием типов нет. В С++ только const иногда мешает, да и то не часто. Так что никакого разительного преимущества Go перед современными языками нету.

Кстати писать тип после придумали в ML, лет за 40 до изобретения Go. Там даже еще дальше пошли — аннотации типов применяются не только к объявлениям, но и в выражениями. Это в сочетании с автоматическим выводом типов добавляет удобства в разы.

Написание типа после имени — это необходимость, которую осознали слишком поздно. Такой подход, к примеру, позволяет компилятору выводить тип возвращаемого значения из типа аргументов функции. В C++11 даже (в очередной раз) ввели специальный синтаксис для этого:

template <class U, class V>
auto add(U const& u, V const& v) -> decltype(u + v) {
    return u + v;
}

Написать decltype(u+v) вместо auto нет возможности — там компилятору ещё не видны имена (и соответствующие типы) u и v.

Кроме того, как уже упоминалось, такой подход существенно упрощает как компилятор, так и разработку инструментов. Вспомним ключевое слово typename из C++:

template <class Iterator>
void doSomething(Iterator it) {
    // Тут необходимо слово typename, чтобы компилятор мог понять, что вы хотите:
    // 1) объявить переменную v с типом указателя на Iterator::value_type;
    // 2) вызвать Itarator::value_type.operator*(v), где v нужно взять из окружающего контекста.
    typename Iterator::value_type * v;
}

Если бы было ключевое слово для объявления переменных, такой проблемы бы не возникло:

var v: *Iterator::value_type; // объявление переменной
Iterator::value_type * v;     // умножение

Языку 30 лет, а мой текстовый редактор, к примеру, зачастую не может распознать объявления переменных. Если бы было слово var, риск ошибки был бы практически нулевой.

Ну и мне лично кажется, что подход с объявлением типа после имени делает опциональный вывод типов более логичным.

// Если тип опустить, то компилятор его выводит, логично.
// К тому же, имена всегда выровнены по левому краю.
var x = 5;
var y: int = 5;
var z: MyType = init();

// Хм... Ок...
auto x = 5;
int y = 5;
MyType z = init();

Спасибо за статью. Ещё, когда тип пишется справа, для меня это удачно укладывается в математическое представление типа как множества принадлежащих ему объектов.

var x int // x принадлежит множеству целых чисел
var p *int // p принадлежит множеству указателей на объекты, принадлежащие множеству целых чисел
var a [3]int // a принадлежит множеству трёхэлементных массивов объектов, принадлежащих множеству целых чисел

Это очень субъективно. Мне например намного привычнее Сишный способ, первое время я вообще не понимал что там за мешанина в Go-коде.

Понятие удобства в данном случае очень сильно зависит от того, какой у человека бэкграунд. Единственный объективный способ сравнения — это посадить 100 программистов, которые никогда не писали на языках со строгой типизацией, и замерить сколько времени их мозг тратит на разбор си-образного и го-образного способов объявления типов. Все остальное — субъективщина и холиворы.