пятница, 18 июня 2010 г.

[prog] Обалденная презентация Роба Пайка о языке Go

Another Go at Language Design – 56-ти страничные слайды одноименного доклада Роба Пайка от 28 апреля 2010.

Роб Пайк очень умный мужик. Презентация сделана что надо. Читаешь и просто ощущаешь в себе растущее желание попрограммировать на языке Go. Спасает только то, что его пока еще не зарелизили :)

Потом, правда, очень быстро вспоминаются слова Страуструпа о том, что практически каждый новый язык разрабатывается его авторами для того, чтобы получить новый, современный, простой, компактный, непротиворечивый и более удобный в использовании, чем уже существующие языки. Однако, если новому языку удается выжить и его начинают использовать, то довольно быстро он превращается в огромного монстра, отпугивающего программистов своей сложностью и неоднозначностью. Имхо, либо язык Go станет нишевым языком (вроде Erlang) и останется компактным и простым, либо и его не минёт чаша сия.

…Просмотрел презентацию, впечатлился. Потом полез в старый C++ный исходник чтобы продумать добавление в него новой функциональности. А там и STL-левские контейнеры, и мой шаблонный код, и использование сторонних библиотек, и всего этого до фига, и все это работает… Да, подумалось мне, каким бы хорошим и продвинутым Go не стал со временем, вряд ли мне придется это код когда-нибудь на Go портировать :)

PS. Еще один прикольный момент из презентации. Сейчас апологеты новых языков любят приводить примеры того, как кусок проекта переписали, скажем, на Scala и код получился в N раз короче, чем на Java. Ну это понятно – новички против старичков. А вот в презентации озвучен отзыв одного из пользователей Go: он переписал программку из 6K строк на Scala на Go и получил аналогичный результат всего 3K строк на Go. Вот так вот! Новички против новичков! :) Запасаемся попкорном ;)

PPS. Ссылка на презентацию была найдена здесь: http://blog.golang.org/2010/05/new-talk-and-tutorials.html

34 комментария:

Krasin комментирует...

Поправка: Go зарелизили. На Google I/O было объявлено следующее:

How suitable is Go for production systems?
Go is ready and stable now. We are pleased to report that Google is using Go for some production systems, and they are performing well. Of course there is still room for improvement - that's why we're continuing to work on the language, libraries, tools, and runtime.

Left комментирует...

Насчёт усложнения языка со временем - мне всегда вспоминается мой любимый JavaScript, который за свою долгую историю практически не изменился. А всё потому что в основе лежат удачные концепции.

Когда читаешь про Go видно что когда делали дизайн языка думали не о том как напихать туда побольше фич (луч ненависти комитету по стандартизации С++) а о том как бы оставить там поменьше концепций и при этом оставить язык удобным и одновременно расширяемым. Я после 10 лет программирования на С++ мечтаю забыть его как страшный сон и когда-нибудь всё-таки попрограммировать на Go :)

eao197 комментирует...

Это я читал, но по мне, пока язык официально не будет поддерживать Windows, его не зарелизили :)))

eao197 комментирует...

2Left: а я JavaScript отношу к тем же нишевым языкам, что и Erlang. Как ни крути, но на C++ и Java написано столько больших и очень больших систем в самых разных областях, что ни JavaScript-у, ни Erlang-у, ни кому-то еще (кроме C разве что) и не снилось.

От C++ я тоже уже устал, и давно. Но дешевле продолжать развивать имеющиеся проекты на C++, чем переползать на что-то другое. Тем более, что что-то другое в наших условиях -- это все та же Java :(

Left комментирует...

Да я ж не призываю "давайте всё нафиг перепишем на Go". Просто когда встанет выбор на чём писАть новую систему, или новый компонент для старой системы - Go у меня будет на вершине списка претендентов. Если посмотреть на историю, то все языки пробивались к вершинам популярности именно таким образом :)

eao197 комментирует...

>Просто когда встанет выбор на чём писАть новую систему, или новый компонент для старой системы - Go у меня будет на вершине списка претендентов. Если посмотреть на историю, то все языки пробивались к вершинам популярности именно таким образом :)

Ну это да, с этим я солидарен. Только добавил бы к Go еще Scala и F#.

Хотя есть одна важная штука -- когда внутри команды используется один и тот же набор инструментов (небольшой набор), то проще передавать куски кода одного человека на развитие другому. Иногда это сильно спасает.

Krasin комментирует...

>пока язык официально не будет поддерживать Windows, его не зарелизили

так а что писать на Go под винду? Это нишевый язык, который очень комфортно будет чувствовать себя на серверах или внутри каких-нить утилит командной строки, но я совершенно не представляю, зачем его использовать для gui. Это просто неудобно!

eao197 комментирует...

>так а что писать на Go под винду?

Да утилиты командной строки разных форм и расцветок :) Тот же svn, например, хороший проект для языков вроде Go.

У нас есть ряд задач по обработке больших текстовых файлов с данными. Как раз под Windows. Ранее эта обработка велась на Ruby, сейчас объемы выросли, требования к скорости и ресурсоемкости так же. Сейчас делаем версию на C++. Хотя для этого Go подошел бы не хуже (не знаю правда на счет его быстродействия).

Krasin комментирует...

Со скоростью все весьма терпимо (если верить shootout). Сильно быстрее, чем Python и Ruby, но все еще тормознее C++. И отдельным минусом -- очень медленные регулярные выражения. Что-то они перемудрили там.

Кстати, а что хочется от "официальной поддержки Windows"? Условно говоря, какие вещи должен уметь Go для Windows, чтобы считаться приемлемым для разработки под нее?

Quaker комментирует...

Цитата:
There is no "public" or "private" label. Instead, items with
UpperCaseNames are visible to clients; lowerCaseNames are
not.

Убило наповал. Почему возможность экспорта клиентам должна зависеть от стиля именования?

Krasin комментирует...

Так у них политика простая:

1. минимизировать количество сущностей в языке

2. унифицировать вид Go программ, чтобы избежать зоопарка.

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

Кстати, они еще и утилиту специальную написали, gofmt, которая сама форматирует код по каноническому style guide. Ровно для тех же целей -- уменьшить число холиворов на ровном месте, упростить использование стороннего кода.

eao197 комментирует...

>И отдельным минусом -- очень медленные регулярные выражения. Что-то они перемудрили там.

А у них там свои? Странно, можно было бы взять PCRE и не париться.

Кстати, как я понимаю, интеграция с C-шными проектами в Go не должна быть сильно сложной. Так что можно было бы для конкретных проектов использовать зарекомендовавшие себя вещи (вроде PCRE, libcurl и пр.).

>Кстати, а что хочется от "официальной поддержки Windows"?

Ну в иделе на golang.org хотелось бы видеть .zip файл с бинарниками последней актуальной версии под Windows (как это на ruby-lang.org, к примеру). Чтобы распаковать куда-нибудь, прописать в PATH и всех делов.

Подойдет и вариант, когда распространяются архивы исходников, но с готовыми makefile для VC++. Чтобы не бабахаться с cygwin-ом, msys-ом и пр.

eao197 комментирует...

>Убило наповал. Почему возможность экспорта клиентам должна зависеть от стиля именования?

После Ruby, где язык налагает органичения на правила именования классов, констант и атрибутов класса это воспринимается вполне нормально. Не будет повода создавать такой же зоопарк стилей, как в C++.

Krasin комментирует...

Регулярные выражения у них не pcre, а re2.

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

Про zip файл или инсталлятор под windows -- да, согласен. Это то, чего им точно не хватает.

Quaker комментирует...

Ранее эта обработка велась на Ruby, сейчас объемы выросли, требования к скорости и ресурсоемкости так же.
Есть неплохой язык Lua:
http://en.wikipedia.org/wiki/Lua_%28programming_language%29
Для него есть хороший компилятор LuaJIT: http://luajit.org/

eao197 комментирует...

>Про zip файл или инсталлятор под windows -- да, согласен. Это то, чего им точно не хватает.

Угу. Если я сам в молодые годы еще был готов самостоятельно делать сборки инструментов, то сейчас уже нет :) Да и командная разработка проще, когда можно брать из Интернета готовые сборки, а не искать их в корпоративных репозиториях. Особенно при вводе в работу новых людей.

eao197 комментирует...

>Есть неплохой язык Lua

Есть. Только помнится мне, что это не столько самостоятельный язык, сколько scripting engine. Т.е. сначала для прикладной задачи нужно будет обертку на C/C++ написать, а потом в ней уже Lua-скрипты гонять.

Quaker комментирует...

Т.е. сначала для прикладной задачи нужно будет обертку на C/C++ написать, а потом в ней уже Lua-скрипты
Необязательно. Как оригинальный Lua, так и LuaJIT могут быть использованы для исполнения приложений, полностью написанных на Lua:
http://www.lua.org/pil/1.html
http://luajit.org/running.html
Но если требуется, то можно встраивать и в C++ приложения:
http://csl.sublevel3.org/lua/

Rustam комментирует...

Ну судя по политике гугла который недавно совсем отказался от внутреннего использования windows инсталлятор вообще может никогда не появится.

Rustam комментирует...

Насчет уменьшения размера кода, так получилось что я два раза переписывал небольшую утилитку с С++ на С++, каждый раз размер уменьшался почти в два раза :)

Quaker комментирует...

Забыл добавить к своему предыдущему сообщению про Lua. Для него существуют немало библиотек, есть специальная сборка под windows:
http://code.google.com/p/luaforwindows/
(на странице перечислены библиотеки с кратким описанием)

eao197 комментирует...

2Quaker: я когда-то экспериментировал с интеграцией Lua в C++. Но сам язык мне, помнится, не понравился.

eao197 комментирует...

>Ну судя по политике гугла который недавно совсем отказался от внутреннего использования windows инсталлятор вообще может никогда не появится.

Угу, может и так. Только для языка программирования отсутствие родной поддержки Windows смерти подобно. Поскольку игнорировать более 95+% компьютеров в мире черевато тем, что их владельцы будут игнорировать тебя самого :)

Rustam комментирует...

Ну если за языком стоит монстр типа гугля можно и игнорировать, не смертельно :)
Например тот же Objective-C без Apple наверно давно бы сдох, а так жив и здоров и даже растет.

eao197 комментирует...

>Например тот же Objective-C без Apple наверно давно бы сдох, а так жив и здоров и даже растет.

Ну так в том-то и дело. Не пищу я под MacOS -- и нафиг мне не нужен ObjC. Но жалко будет, если в такой же ситуации я окажусь и с Go. Нужно программу под Win написать и забудь про Go :(

Quaker комментирует...

Но сам язык мне, помнится, не понравился.
Можно поинтересоваться: что конкретно не понравилось?

eao197 комментирует...

>Можно поинтересоваться: что конкретно не понравилось?

Я уже толком не помню, дело было года 3.5 назад. Кажется, там любой объект мог рассматриваться как хэш-таблица. Из-за этого обращения к его атрибутам/методам можно было записать в нескольких форматах. Мне тогда нужен был предметно-ориентированный скриптовый язык для непрофессионалов в программировании. И я подумал, что Lua для них будет не очень понятным.

Quaker комментирует...

Мне тогда нужен был предметно-ориентированный скриптовый язык для непрофессионалов в программировании. И я подумал, что Lua для них будет не очень понятным.
Какой язык Вы советуете для непрофессионалов? Что Вы тогда выбрали?

eao197 комментирует...

>Какой язык Вы советуете для непрофессионалов?

Вот чесно скажу -- не знаю. Будь передо мной сейчас такой выбор, то долго бы я репу чесал. Выбирал бы из чего-нибудь Python или Ruby, или JavaScript, или Visual Basic подобного. Может быть на Falcon бы пристальнее посмотрел, его ведь так же для скриптования делали.

По степени простоты встраивания в C++ я бы смотрел в сторону Ruby, того же Lua (имхо, его было даже проще встраивать), Falcon.

>Что Вы тогда выбрали?

Как любой нормальный хакер ;) написал свой собственный :)))

На самом деле там должны были быть некоторые правила маршрутизации записаны, которые в определенных местах должны были уточняться отдельными if-ами и switch-ами. Вот я и сделал что-то вроде продвинутого конфига на основе Curl-синтаксиса. Так что сейчас люди пишут инструкции вида {if {src_addr_regex "bla-bla-bla"} {then {accept}} {else {reject}}} ;)

night beast комментирует...

Евгений Охотников>Вот чесно скажу -- не знаю. Будь передо мной сейчас такой выбор, то долго бы я репу чесал. Выбирал бы из чего-нибудь Python или Ruby, или JavaScript, или Visual Basic подобного. Может быть на Falcon бы пристальнее посмотрел, его ведь так же для скриптования делали.

скорость сильно критична? если нет, то tcl очень хорош для таких целей.

Quaker комментирует...

Еще раз посмотрел презентацию. Скажу честно, есть пару моментов, которые я не знал до этого.
1) - C: #include
reads 360 lines from 9 files
- C++: #include
reads 25,326 lines from 131 files
- Objective-C: #include reads 112,047 lines from 689 files
But we haven't done any real work yet!
In Go, import "fmt" reads one file:
195 lines summarizing 6 dependent packages.
Компиляция C/С++ - процесс не быстрый, но я даже представить не мог, что в случае C++ и особенно Objective-C все настолько тяжело
2) A byte[20] in Java will cost an *additional* 16 bytes of memory, and be slower to access because the bytes themselves are in a different area of memory from the container object.
Видимо, вот откуда берется тормрзнутость Java.

eao197 комментирует...

2Quaker:

По поводу ObjC -- я так понял, что там еще и заголовочные файлы Cocoa загружались. Это почти тоже самое, что windows.h подгрузить.

По поводу тормознутости Java -- там все-таки главные тормоза -- в головах разработчиков, которым думать лень. Имхо, конечно.

eao197 комментирует...

2night beast: для скриптинга можно применить очень много вариантов. И все будут хорошо работать. Самый важный критерий здесь -- это личные предпочтения разработчиков ;)

night beast комментирует...

Евгений Охотников>2night beast: для скриптинга можно применить очень много вариантов. И все будут хорошо работать.

просто tcl как раз для этого и создавался. легко расширяется. применять его совместно с си очень просто. к сожалению, есть и свои недостатки :)

питон имхо более тяжеловесный и навязывает свой стиль.

с руби не работал.

с луа/сквирел не слишком много опята, то тоже имхо не дает такой свободы как tcl.

Евгений Охотников>:Самый важный критерий здесь -- это личные предпочтения разработчиков ;)

это да :)