О языке программирования Julia

Автор: Дмитрий Беляев.

Что это:

Выборочное описание языка программировая Julia на русском языке. Состоит частично - из далеко неполного вольного перевода официальной документации по языку, расположенной на http://julialang.org/ в разделе "Документация"(Docs) , частично - из собственных практических примеров.

Основное внимание уделено рассмотрению языка лишь с точки зрения программиста, а не аналитика или математика.

Текст преследует две цели:

Cистематизировать собственные знания и поделиться опытом использования языка.

Когда-то это была только моя шпаргалка, в которую я копировал примеры кода. Потом текста порядком прибавилось, и я дописал слова "Не очень" к названию. Теперь это моя шпаргалка и еще - ваша. Буду рад, если она кому-то поможет.

Стоит ли изучать Julia

В научном мире (математика, анализ данных) язык Julia был замечен сразу после появления и с интересом опробован. Потому что: он похож на R, он нацелен на эффективные математические операции, он динамический с простым синтаксисом и продвинутой качественной REPL. Позволяет рисовать графики (используются устанавливаемые пакеты). Он с привязкой к Python и C. Он с приличной производительностью, которая позволяет остаться в рамках одного языка "насовсем". Он со встроенным кластер-менеджером для запуска распараллеливаемых задач на нескольких узлах и при этом имеет довольно низкий порог вхождения. На Julia уже портировано много кода (библиотеки, фреймворки), связанного с машинным обучением. На английском языке активно выходят книги по языку.

У нас же, если не брать в расчет компании-гиганты, бизнес не интересуется "не мейнстримовыми" языками. То ли желание максимально исключить риски не дает возможности широко мыслить, то ли мыслить - не в моде, в общем, как следствие, программисты общих направлений, отнеслись прохладно "к еще одному языку похожему на Python и R": "Будут вакансии - тогда и выучим". (Кто-то называет это проблемой курицы и яйца). А еще потому что: язык Julia пока молод, не стабилен. От версии к версии происходят изменения синтаксиса, с каждым разом все меньшие, но все же. Он использует LLVM: виртуальная машина - это хорошо, но не подходит для некоторых типов задач. Время старта "Hello world!" - от 0.15 сек - пока многовато, чтобы писать на нем часто вызываемые мелкие программы (а-ля shell-скрипт). Потребляемая память: в районе от 110 Mb (на моем домашнем компьютере) до 190 Mb (на сервере) - для начала, просто для того, чтобы загрузить LLVM, и все библиотеки. Это похоже на JVM (та, конечно, отъедает больше), но у Java, все, что нужно, уже есть (у нее другая проблема - избавиться от лишнего), а в Julia все еще только начинается: много разработанных пакетов сторонних разработчиков устаревает, не поспевая за версиями языка.

Новички ходят вокруг да около с вопросами: "Стоит ли изучать Julia? Какие у него преимущества, например, перед Python?" Они не получают качественного ответа, потому что (см. выше.) программисты общих направлений не сложили еще о нем своего личного мнения, основанного на опыте. Потому что: мало литературы на русском языке. Книги быстро устаревают. Потому, что у языка нет одной-единственной килл-фичи: его преимущества складываются из многих моментов. Они не лежат на поверхности. Но в сумме они набирают некую критическую массу, которая в какой-то момент перевешивает отдельные преимущества многих. Но говоря, о преимуществах, надо помнить, что это слово имеет смысл лишь в контексте решаемых задач. Думаю, у хорошего программиста есть несколько любимых языков, каждый из которых проявляет себя лучше других в зависимости от обстоятельств и целей.

Существенный минус языка для меня - он слишком динамический для некоторых задач, как и многие динамические языки. В нем нет статической проверки типов. Он выдает ошибку только когда натолкнется на нее в рантайме. По степени динамичности Julia напоминает Ruby: даже Perl с включенным use strict находит больше ошибок на этапе компиляции. Это ведет к тому, что по началу сложно написать много кода и, чтоб он работал. Хотя, перечитывая эти строки, я замечаю, что, со временем, все меньше жалуюсь: когда мне нужно написать большую программу на Julia, наряду с главной программой, я пишу много маленьких функций, в которых сложно сделать ошибку и раскладываю их по файлам-модулям. На этом этапе для модулей я не создаю всю структуру папок как для пакета: это всего-лишь файлы с именем, например, MyModule.jl, которые лежат в текущем каталоге. Такой код легко тестировать, находить и исправлять в нем ошибки. Можно импортировать модуль в сессии REPL и протестировать все его функции. Основная программа использует нужные модули. Единожды написанные и отлаженные функции в модулях более не нуждаются в проверке - позже они могут быть вынесены в пакеты и использованы в других программах. Суть сводится к тому что на каждой итерации "написал код", "запустил", "исправил ошибки" добавляется небольшое количество кода.

Если меня не устраивает такой сценарий работы, я использую другой язык. Поэтому, я не советую искать идеальный язык на все случаи. Если вам нужен современный, мультипарадигменный, выразительный и производительный язык, такой же как Julia, но со статической проверкой ошибок, обратите внимание на язык D (Искать по слову Dlang). Почему бы тогда сразу не выбрать статически типизированный компилируемый язык? По тем же причинам, почему многие выбирают Python против C++: продуктивность программиста, человечность синтаксиса, нацеленность на конечный результат. Динамические языки позволяют решить задачу без необходимости становиться опытным программистом. Julia же добавляет сверху на свою чашу весов еще и высокую производительность.

Итак, возвращаясь к вопросу "стоит ли?" Не хочу вводить никого в заблуждение: если вы школьник, который хочет выигрывать олимпиады по программированию - узнайте, а примут ли ваш код написанный на Julia? Если нет - пока вы можете использовать Julia только в личных проектах. Если вы студент, у которого на носу сдача курсовой - узнайте у своего преподавателя, как он отнесется к этой идее. Если вы молодой специалист без работы - то сначала найдите работу, за которую вам заплатят. Если вы решили переквалифицироваться в программиста - вам нужно попробовать несколько языков: в каком дело пойдет легче - тот и учите. Бросьте читать хвалебные статьи и пробуйте языки на практике. Только так. Если вы хотите язык, как инструмент для себя, то Julia - отличный выбор. Вы ничем не рискуете. Я тоже начинал использовать его, как язык "для себя". А потом это "для себя", немного расширило границы, став "для себя на работе". Позже оно превратилось в "один из языков, который я использую на работе". Оглянуться не успел - и Julia стал основным моим языком, на котором я пишу сложные программы по обработке данных. И вот он уже денно и ночно крутится на серверах, выполняя долгие расчеты.

Почему меня заинтересовал этот язык

Мне нужен был язык, который хорошо приспособлен для обработки данных. Чтобы можно было писать быстро (как на Perl), работать в удобной среде (как Bash), иметь широкий выбор готовых решений по анализу, рассчетам, доступу к базам данных и веб, (как в Python), и чтобы все это не тормозило на гигабайтах данных (как это в Perl и Python), не стремилось превратиться в свалку непонятных скриптов (как это в Bash), чтобы вместо того, чтобы передавая поток данных из программы в программу не приходилось каждый раз сплитить каждую строку на поля, а иметь возможность собрать систему, оперирующую структурами, в идеале - с готовой сериализацией объектов, для передачи по сети, и если уж на то пошло, чтоб без головной боли работать распределенно (примерно, как в Erlang) но, в то же время, имеющую легкий и удобный для запуска доступ ко всем shell-командам и скриптам, уже написанным и работающим, и, наоборот, чтоб запускалось из других скриптов, и чтобы это все было легко сопровождать. Многие языки предлагают разные преимущества, я пробовал многие, но везде находилось какое-то "но", мешающее мне работать так, как хотелось бы.

Так, будучи в хроническом состоянии неудовлетворенности, однажды, поздно ночью я наткнулся на язык Julia. Две вещи, упомянутые в краткой статейке: место рождения языка (MIT), и LLVM сразу обострили мой интерес.

Первое, что бросилось в глаза - прекрасная документация. Второе - простота установки. На Linux этапа установки просто нет, если пользоваться готовой сборкой для своей системы. Скачал, распаковал и запустил. Никаких отсутствующих зависимостей, ненайденных библиотек и прочего. Положил на общий сетевой ресурс - запускай с любого компьютера (той же архитектуры и ОС). Третье - красивый и удобный REPL (интерактивная среда командной строки).

Удобная система справки: поставил знак вопроса в начале строки - ты в справке. Автодополнение ввода для любых имен в области видимости, имен пакетов. Автодополнение для путей файловой системы внутри строк. Подсказки для функций по TAB после открывающей скобки. Многострочный ввод alt+enter. История по стрелке вверх. Легкий способ заглянуть в исходники, не покидая REPL: @less, @edit - хоть собственные пакеты, хоть в стандартной библиотеке. Понятные исходники! Режим shell: поставил в начале строки точку с запятой - вводи команду shell. Этого достаточно, чтобы тянуло возвращаться снова и снова ( я почти не вылезаю из REPL). А когда распробуете все эти вкусности, вы обнаружите, что можно посмотреть, что происходит с вашим кодом в процессе компиляции на разных этапах. И вам захочется поближе познакомиться с LLVM.

Однострочники: ключ -e. Цветной вывод в терминал: --color=yes. Запустить на нескольких компах, так чтобы с одного можно было отдавать команды, а остальные слушались? - Из коробки! Только настройте беспарольный ssh-доступ. Можно ограничиться параллельным использованием нескольких процессоров на одной машине. В подавляющем количестве случаев, код переписывать не придется. Это тоже весомый плюс языку, как платформе - технологический.

Математики, конечно, спросили бы: а произвольная точность, рациональные, комплексные, линейная алгебра... есть? Я бы не спросил. Но они есть: операции с комплексными числами:(1 + 2im)*(2 - 3im), рациональные: 2//3. Векторные операции. Матрицы и операции с ними. Всегда под рукой у математика есть pi, golden, e и всякие другие умные буквы. А если у вас есть переменная x, то запись 2x будет обозначать 2*x.

В самом языке привлекает простой дизайн и простой, "незашумленный" синтаксис: школьников бери и пересаживай с Python на Julia. Хороший баланс между функциональной и императивной парадигмой. К примеру, вот синтаксис анонимных функций: x->x+1 или (x,y)->x+y. Язык поощряет писать в функциональном стиле, и, тем самым, мягко подталкивает к написанию "чистого" кода. Современный подход к системе типов и ее ненавязчивость. Функции и множественная диспетчеризация: с ними удобно. Вспомнил приятную мелочь: индексация массивов по умолчанию начинается с единицы. Уж совсем для любителей: в именах переменных и функций можно использовать Unicode и, само собой - кириллицу. Кто любит Lisp? Операторы в Julia - это функции, и можно делать так: +(2, 3, 4) (запятые, все же, нужны). И, раз уж затронул тему: можно писать макросы.

Инфраструктура: низкий порог вхождения, однозначность с версиями, библиотеками, инструментами и прочим. Не нужно изучать Maven, не нужно собирать проект, упаковывать в jar, прописывать манифест и это - не потому, что за вас все сделает IDE с кучей настроек ( которая, непонятно что делает, когда нажимаешь зеленую кнопочку ). IDE тоже не нужна.

Система пакетов основана на git и, благодаря этому, она позволяет не только устанавливать пакеты, но и вносить в них изменения, а также разрабатывать и публиковать собственные. Установка пакета происходит из REPL явно или как зависимость другого пакета. По умолчанию пакеты ставятся в home пользователя, root-права не требуются.

В исполнительной системе: производительность. Она не бросается в глаза сразу: она прячется за временем компиляции, которая часто происходит по необходимости, в перемежку с рантаймом. При работе в REPL, создается ощущение, что все происходит как-то неспешно. Это из-за того, что введенные выражения должны пройти компиляцию. При первом использовании функции, компилируется версия этой функции с данными типами аргументами. Второй и последующие вызовы происходят уже быстро. Не зная этого, можно подумать, что язык не обладает достаточной производительностью, однако, это неверно. Имеется способ указать на необходимость предкомпиляции своего модуля, тогда он компилируется, и скомпилированная версия кэшируется. Даже не имея опыта на Julia, не зная его особенностей, просто руководствуясь справкой и здравым смыслом, вы с большой долей вероятности напишете более производительный код чем такой же на другом динамическом языке. В отношении же математических операций - Julia неоспоримо быстрее. Это видно невооруженным глазом.

Удобно вызывать внешние программы и обмениваться с ними данными через потоки ввода-вывода.
Сейчас уже кажется странно, когда язык не поддерживает из коробки безглючную работу с unicode-строками, но такое встречается. В Julia вы не столнетесь с этими проблемами. Работая с Julia, я забыл о существовании "encode()/decode()", и костылях, вроде: "use utf8" или это страшное: "# -- coding: utf-8 --".

Я уже успел поработать над парочкой небольших проектов на Julia. Пережил переход с v0.4.6 на v0.5.0. Оказалось - не страшно. Код, как правило, разложен по полочкам в виде отдельных функций, модулей, и рефакторинг проходит на удивление легко, хотя Julia не проверяет код статически.

Разработка языка ведется в режиме открытого обсуждения: любой заинтересованный человек может предложить идею (лучше - pull request) на включение ее в язык (в синтаксис или стандартную библиотеку). Самые серьезные обсуждения ведутся в разделе Issues на github.com в репозитории https://github.com/JuliaLang/julia. Есть форум discourse.julialang.org, где с удовольствием отвечают на любые, даже глупые вопросы, знаю точно - сам пробовал.

Теперь, каждый раз, читая код Perl/Python, я ощущаю, что это - как шаг назад. Сознавая все недостатки Julia, я уже не хочу возвращаться к ним. Конечно, они делают свою работу, и я буду их использовать, но, при первой же возможности, буду убегать обратно. Кстати, авторы Julia любят и Perl и Python (вы это почувствуете) - из этих языков они позаимствовали много плюшек.

Как читать эту книгу

Эта книга - набор отдельных глав-статей. Ее не требуется читать от начала до конца в том же порядке, как она написана. Начинайте с того, что интересно. Возможно, этим все и кончится. Но, по мере роста количества текста, я все-таки начал сортировать главы в порядке, с моей точки зрения, предпочтительном для прочтения. И помните: самое важное вы найдете в официальной документации. Не знаете английского - вооружайтесь переводчиком и - вперед, к собственным открытиям!

Черновой вариант!

Текст содержит ошибки. Стиль изложения непостоянен, как и стиль форматирования. В главах, которые состоят в основном из перевода документации, собственные соображения я оформил курсивом. В остальных главах, полностью моих, я оставляю текст обычным. Изложенный материал неполон. Бывало такое, что через некоторое время я обнаруживал, что приведенный мною пример содержит баг. Я исправляю обнаруженные ошибки, как можно быстрее. Gitbook предоставляет несколько способов обратной связи. Можно даже это делать с привязкой к конкретному фрагменту текста (справа от текста знак плюсика). Но когда уже книга выйдет из активной фазы редактирования, я могу их долго не увидеть, так что, не ручаюсь. Так же не гарантировано, что она останется в открытом доступе или не будет перемещена на другой адрес.