Julia и Python —языки программирования, которыми я очень дорожу. Использование Julia вместо Python обладает множеством преимуществ, таких как меньшее время написания кода и более быстрая компиляция. Однако на данный момент Julia проигрывает Python в популярности. В отличие от Python в Julia отсутствует критическая инфраструктура машинного обучения и выполнения скриптов, необходимых для того, чтобы стать отраслевым стандартом, особенно в машинном обучении.
Контейнеры в Julia как правило запутаны, излишне модулированы и плохо документированы в отличие от доступных контейнеров Python, зачастую разрабатываемых более крупными организациями, а не инженерами, занимающимися разработкой из дома. Scikit-Learn — одна из наиболее популярных библиотек Python — разработана на конкурсе “Google Summer of Code”, а Tensorflow был создан непосредственно в Google.
Незаслуженно низкая популярность Julia ставит очень интересный вопрос:
Где уместен язык Julia?
Является ли Julia просто подручным Python, не имеющим собственной базы кода, или же она, возможно, напарник Python, используемый скорее как Scala для управления воркерами и развёртывания алгоритмов машинного обучения корпоративного уровня? Scala — язык, который большинство учёных боится использовать, даже несмотря на его длинную историю и обширную библиотеку контейнеров. Всё потому, что Scala является существенно более сложным языком для выполнения трудоёмких задач, и зачастую требуется немалое время для реализации того, что можно сделать на Python в четыре раза быстрее.
Несмотря на эти недостатки, сейчас Scala является важным языком для многих учёных, работающих с данными. Подливает масла в огонь то, что Scala — производный от Java и содержит все ошибки вычисления и манипуляций над числами с плавающей точкой. В Julia нет этих проблем, и, в отличие от Scala, на нём легко писать. Он прост в запуске и при этом поддерживает скорость, необходимую для языка, обрабатывающего большие данные.
Я считаю это отличным направлением для развития языка, поскольку маловероятно, что Python в ближайшее время окажется невостребованным. Хотя на данный момент не похоже, что разработчики языка выбрали это направление, учитывая, что контейнеры в Julia в большинстве своём испорчены PyCalls, который делает Julia невероятно медленным из-за его интерпретации Python.
Это ужасный дефект и упущенная возможность, потому что, хотя Python безусловно медленнее Julia, его место в машинном обучении гораздо прочнее, чем у Scala. Я знаю гораздо больше инженеров, использующих Python, а не Scala.
Поэтому легко предположить, что цель Julia не в том, чтобы заменить Scala, а в том, чтобы заменить Python. Отсюда и девиз:
“Выглядит как Python, летает как C”
(Не уверен, что они всё ещё используют этот старый девиз).
Для чего же стоит использовать Julia?
Как я подчеркнул выше, Julia безусловно мог бы заполнить довольно значительный разрыв между Python и Scala. Во-первых, используя PyCall.jl для импорта модулей Python, во-вторых, обрабатывая большие данные аналогично Scala. Нельзя сказать, что использование Julia в качестве предпочтительного языка для машинного обучения и статистики не целесообразно, но с точки зрения замены Python довольно маловероятно. Python — великолепный язык, который позиционирует себя как самый популярный язык в мире.
Julia действительно сложнее, чем Python
Распространено заблуждение, отчасти из-за этого девиза, что Julia и Python по сути один и тот же язык, что весьма далеко от истины. Важно помнить, что у людей, не знакомых с R, Lisp, Nimrod или подобными языками, могут возникнуть трудности с соблюдением и пониманием функциональной парадигмы, особенно исходящей из Python.
Хотя синтаксис Julia безусловно очень похож на синтаксис Python, уже в конструкторе видны различия:
# Julia
mutable struct my_type
data
end
class my_type:
data
Хотя на первый взгляд они и кажутся похожими, важно помнить, что структура — это совершенно другой тип данных, нежели класс. Важное отличие между структурой и классом заключается в том, как функции применяются к типам. Чтобы использовать функцию с диспетчеризацией или параметрическим полиморфизмом в структуре, данные нужно передавать через метод, а в классе функцию можно задать как дочернюю этого типа. Это довольно существенное структурное различие, и понятно, почему оно может слегка раздражать тех, кто работал с Python.
Кроме того, Julia в целом сложнее, чем Python, и содержит много синтаксиса, просто не имеющего смысла для обычного программиста на Python.
То есть у нас есть язык, который немного сложнее Python, но ощутимо быстрее. Отсутствие чёткого направления, думаю, может стать наибольшей проблемой, с которой столкнётся такой язык, и именно от этого в целом страдает Julia. В нём есть пакеты, ориентированные на оптимизацию, а также порты для SDL2 и GTK3+, но в то же время нет компилируемых исполняемых файлов, что делает эти пакеты почти бесполезными для всего, кроме программирования для развлечения. В Julia также есть множество пакетов машинного обучения, но зачастую они используют PyCall.jl, поэтому я задался вопросом:
Почему бы просто не использовать Python?
Для меня не имеет большого смысла использование более медленной версии того же пакета на другом языке только ради использования конкретно этого языка.
Люди, которых я знаю
Из сотен специалистов по данным, которых я знаю, постоянно используют Julia только двое. Я спросил их, что они думают о текущем состоянии этого языка, в каком направление он был бы полезен, и они в унисон ответили:
“Я бы хотел видеть меньше PyCall, больше пакетов машинного обучения и более чёткое направление для языка.”
Безусловно, это основные проблемы Julia, так как недавно я узнал, что они оба используют PyCall Pandas.py вместо Julia’s DataFrames.jl, что иллюстрирует необходимость лучшего модуля для облегчения задач.
Бэкенд
Сейчас я вижу максимальное использование Julia в выполнении скриптов бэкенда, что является неудачным применением этого фантастического языка, на котором я пишу каждый день. Julia определённо стоит использовать для запросов и конечных точек для перемещения больших объёмов данных для применения в Python. Проблема с этим назначением заключается в том, что HTTP.jl package в Julia недостаточно хорош для выполнения этой работы. Вдобавок Genie.jl довольно часто глючит, а в Python того же самого можно добиться значительно проще. Когда я сталкиваюсь с таймаутами, я думаю, что Julia определённо мог бы сделать что-то получше, чтобы вытащить меня из
“крупной неприятности с получением запроса.”
Заключение
Хотя я определённо люблю язык Julia, на данный момент существуют проблемы, которые необходимо решить, чтобы язык мог двигаться дальше. Во-первых, я был бы рад видеть пакеты, не испорченные PyCall. Я работал над этим некоторое время, с примерами вы можете ознакомиться в моём Github.
Julia способен делать действительно интересные вещи и полностью изменить наш подход к машинному обучению, но для того, чтобы это сработало, нужно сделать некоторые изменения в направлении, базе и доступных внутри языка модулях. Вот довольно простые вещи, которые могли бы сделать Julia гораздо более конкурентоспособным:
- Компилируемые выполняемые файлы.
- Единообразный пакет SkLearn, написанный на чистом Julia.
- Статистическое и визуальное построение графиков, объединённые в один модуль, написанный на чистом Julia (и никаких PyCall вроде Plots.jl).
- Улучшенные ресурсы для обработки и перемещения данных в различных форматах.
- Лучшая поддержка Javascript в целом.
- Улучшения и в запросах, и в API, хоть мне и нравится Genie.jl от Essenciary.
В целом, без этих базовых улучшений и изменений Julia останется менее полезным языком, чем Python. Целевым направлением Julia не должно быть изобретение колеса и потеря всех замечательных вещей, построенных на низком уровне из-за отсутствия модулей. Остаётся только надеться, что со временем язык и его библиотеки будут становиться только лучше, и работа с Julia без Python станет целесообразной.
Читайте также:
- Изучаем Python: генераторы, стримы и yield
- Потоковые и многопроцессорные модули на Python
- Автоматизация скриптов на Python при помощи AWS Lightsail
Перевод статьи Emmett Boudreau: Is Julia’s Place Co-Existence With Python?
