[comp.prog.thoughts] Так вот о языке Go

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

Язык Go производит впечатление добротно сделанного, практичного и минималистичного языка, уровнем повыше C – за счет сборки мусора, встроенных в язык хэш-таблиц и каналов, поддержки лямбда функций и goroutines, а так же за счет интерфейсов.

Язык приятно удивляет повторным использованием одних и тех же идиом. Я был поражен тем, как выполняются: проверка наличия элемента в хэш-таблице, неблокирующее чтение из канала и проверка типа объекта:

func demo( m map[string]int, ch chan int, err os.Error ) {
  v, present := m[ 'key' ];
  i, isRead := <-ch;
  e, isCastSuccessful := err.(*os.PathError);
  ...
}

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

Язык оставляет впечатление, что очень умные и опытные люди пробуют создать удобный для себя инструмент. Заточенный под конкретную нишу – разработку околосистемных вещей, которые сейчас пишутся на C. Я думаю, что Subversion или Apache от переписывания на Go только выиграл бы.

Однако лично меня язык Go оставил равнодушным, не захотелось мне на нем программировать. Наверное, из-за отсутствия в нем нормального ООП, шаблонов, исключений, константности для объектов. Если не сравнивать Go с C++ (поскольку в C++ нет сборки мусора), то язык D выглядит предпочтительнее, чем Go. Ведь за счет средств D можно повторить все, что есть в Go (включая goroutines и каналы).

Т.е. моя главная претензия к Go – это его ограниченные возможности по сравнению с другими современными языками. Пока ты пишешь какую-нибудь несложную утилиту командной строки или жестко ориентированный под конкретную задачу сервер, языка Go может и хватит. Но стоит ступить чуть в сторону – и что? Например, можно ли на Go эффективно написать аналог Boost.MultiIndex? Я сомневаюсь.

Что в истории с Go интересно, так это шум вокруг его появления. Имя Google – это сильно, это внушаить! ;)

Такое впечатление, что все, что выбрасываетсявыбирается из Google на свет божий, просто обречено на известность. Анонсировал Google свой Protocol Buffers – все “Вау!” Опубликовали альфа-версию Go – по всему миру “Go! Go! Go!” Ну а что этот Go? Пока ничего. Ну да ладно, жизнь не совершенна, и не стоит искать справедливости в информационных технологиях ;)

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

Во-первых, явно демонстрируется, что managed-платформы не подходят для целого ряда задач. Начиная от написания мелких системных утилит и текстовых редакторов вроде ViM, заканчивая высоконагруженными серверами. Безопасность, кроссплатформенность, большие библиотеки, Ынтырпрайзность и поддержка крупными корпорациями – все это хорошо. Но нафиг не упало, когда нужно написать что-то типа svn.exe.

Во-вторых, четко проявляется картина, в которой язык C не удовлетворяет современных разработчиков своей низкоуровневостью, а C++ – своей монстрообразностью и переусложненностью. Действительно, нерадостно в XXI-м веке вручную распределять память и искать библиотеки, реализующие хэш-таблицы. Равно как и нерадостно годами изучать C++ для того, чтобы быть уверенным в безопасности своего кода.

И, если поиграть в пророка, то я бы сказал, что разработчики (некоторая их часть) сейчас заинтересованы в появлении современного нативного языка. Более мощного, чем C, и менее сложного, чем C++. Более безопасного, чем каждый из них.

На его роль могли бы претендовать Eiffel, OCaml или D. Но, поезда Eiffel и OCaml уже ушли (при всем уважении к ним и к их пользователям). D так и не отправился в путь, хотя уже догнал по сложности C++ и хочет обогнать. Должен быть какой-то новый игрок. Именно новый, за которым еще не тянется след обманутых ожиданий :) Может быть это будет Zimbu. Может быть Go. Может быть еще кто-то.

Но я сомневаюсь. Поскольку практически все современные мейнстримовые языки (C++, Java, C#) начинались более простыми, чем есть сейчас. И эта сложность не случайна. Она возникла как следствие попыток решения реальных задач. Ведь любой успешный инструмент начинает применяться совсем не так, как это предполагал его автор. Как следствие, инструмент обрастает фишечками и рюшечками, без которых никак. Но которые превращают язык в неповоротливого монстра типа C++.

Это неизбежный процесс. Очень хорошо он виден именно на примере языка D. Он в начале 2000-х был почти как Zimbu сейчас. Вальтер Брайт был даже против поддержки шаблонов в языке. Сначала. Но потом появились и шаблоны, и замыкания, и константность, а на горизонте маячат еще и макросы. А ведь на D еще ничего толкового и не написали! Так что уже говорить о C++, Java или C#, на которых народ клепает чуть ли не миллионы строк в сутки, в самых разных прикладных областях.

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

Такие вот пироги. И кажется мне, что если в нишу C/C++ и ворвется какой-то молодой C++киллер, то он изначально должен быть не слабее C++ по своим выразительным возможностям, а напротив – гораздо, многократно мощнее. Но при этом он должен быть простым в изучении, а так же обеспечивать отличную интеграцию с уже написанным C/C++ кодом. Такой, что осваивается за один вечер, а потом рвет C++ как тузик грелку! :)

Появится ли что-нибудь такое? Будем посмотреть. Но вряд ли это будет Zimbu или Go.