Сможет ли Julia занять место рядом с Python

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 станет целесообразной.

Источник: m.vk.com

Комментарии: