Комментарии 16
В целом, жду отзывы, дополнения, замечания. Есть мысли сделать серию небольших заметок про Julia: по созданию скриптов (акцент на обработку аргументов), веб-сервисов, построению отчётов. Возможно, надо пояснить модель системы типов Julia. Поскольку язык новый, не думаю, эти вопросы совсем очевидны.
Спасибо за статью. Было бы очень интересно прочитать сравнение с классическими тулзами (pandas, numpy) и на каких юзкейзах переключение на джулию даёт ощутимые преимущества.
Вопрос про сравнение с pandas я уже слышал… Но главный вопрос — критерии сравнения. Если вопрос про производительность — это сделать можно. Только надо подобрать наборы данных и операции, на которых сравнивать. Если же вопрос про языки запросов типа
x = @from i in df begin
@where i.age>50
@select {i.name, i.children}
@collect DataFrame
endто это отдельный разговор. См. https://juliadata.github.io/DataFrames.jl/stable/man/querying_frameworks.html
Касаемо сравнения производительности, почти уверен, что у pandas будет провал в том случае, когда добавляются сложные условия выборки, требующие выполнения питон-кода. У Julia всегда будет выполняться родной код.
Касаемо сравнения с numpy, тот же вопрос о критериях. Если сравнивать производительность прямо, то см. https://julialang.org/benchmarks/ Но вопрос, на сколько это реалистично отражает практические задачи. Если сравнивать чистые вычисления внутри Julia и внутри numpy, думаю, что для numpy не всё плохо. Если же появляются задачи, где данные надо использовать в нескольких библиотеках, которые не понимают numpy, или просто требуется их перепаковка из numpy-объектов в питон-объекты и обратно, получаются точки провала производительности. У Julia их нет, поскольку везде используется native-код.
Касаемо синтаксиса с numpy и Matlab, рекомендую посмотреть сравнительную таблицу https://cheatsheets.quantecon.org/
И компактно представленные средства из Julia — https://juliadocs.github.io/Julia-Cheat-Sheet/
То есть ответ касаемо случаев использования Julia такой. Если нет унаследованного кода на Питоне, то следует писать на Julia.....
Благодарю за отзыв! Ваши предыдущие статьи, откровенно говоря, и спровоцировали меня на создание учетной записи здесь и на написание этой статьи. Описание по примерам — это хорошо, но только для тех, кому примеры понятны. Для тех же, кому предметная область далека, весь текст может показаться слишком абстрактным, а возможности языка — какими-то надуманными "фичами", которые нужны только тем, кто понимает эту непонятную предметную область. Имено поэтому я и решил изменить контекст изложения и начать делать его в отрыве от предметной области, но с акцентом на то, как программировать. Впрочем, всего должно быть в меру, потому, безусловно, статьи с конкретными примерами тоже нужны и важны.
Julia — новый язык. На данный момент вряд ли ошибусь, если скажу, что специалистов по ней пока ещё просто нет. Сам я погрузился в Julia в августе, как раз под версию 1.0. До этого только читал обзоры. В следущем году специалисты уже точно будут. Технологии на Julia имеют явный потенциал. Впрочем, как раз сейчас, пытаемся делать сервисы обработки данных именно на Julia.
Кроме того, мы задумались о создании учебного курса для студентов 1-го курса технического университета, где Julia станет первым языком программирования. Она видится хорошим языком для изучения принципов алгоритмизации, а также в качестве языка для решения текущих студенческих задач.
По работе я портировал свою библиотеку на жулию ради скорости работы. Однако с релиза 1 версии они много что поломали. Например мне так и не получилось нормально подключить Plots. Пробовал использовать gadfly но он слишком заморочен.
Интересно было бы прочитать про то как рисовать графики.
Сейчас уже большинство популярных библиотек перенесли на 1.0. К слову, в Julia очень удобно проверять библиотеки при помощи встроенных тестов. Когда устанавливаете новый пакет, надо всего лишь набрать команду test ИмяПакета. Если всё в порядке, то можно использовать.
Касаемо графиков. Я использую Plots / GR. Каких-либо проблем сейчас не замечаю. Из прочих бакендов, см. http://docs.juliaplots.org/latest/examples/plotlyjs/ — интерактивные диаграммы для jupyter notebook. Из известных мне проблем, в plotlyjs поломаны полярные координаты. В остальном, работает.
И относительно того, как рисовать, Yermack написал серию статей, где, как раз, акцент на графику. Собственно, см. хаб https://habr.com/hub/julia/
Julia из года в год всё интересней.
Несколько лет назад в фирме в которой тогда работал рассматривали постепенный перенос большого Matlab проекта и Julia была одной из альтернатив.
Предпочли python по нескольким причинам, одна из которых относительная зрелость библиотек, другая — то что публикации по ML тогда часто шли с кодом на python. Код можно брать и запускать на своих данных с минимумом усилий.
Проблема курицы и яйца.
Если (когда) наберётся критическая масса публикаций перспективы весьма хороши.
К сожалению мне в работе Julia никак не может пригодиться не могу представить DevOps задач где бы было выгодно.
По-моему Julia уже достигла зрелости. Именно потому, для задач ML и обработки данных мы решили её использовать. Пару лет назад, вероятно, я бы согласился с python, но сейчас смысла его использования уже нет. Да и примеров уже достаточно. Хотя, в большинстве случаев, их надо искать. Иногда, чтобы понять, как сделать что-то для себя, надо смотреть код библиотек. Но тут — лишь вопрос программистской квалификации и способности быстро понять как оно должно работать. В целом, Julia не является каким-то принципиально новым языком программирования. Это просто переосмысление существующих моделей. Потому начать программировать на ней довольно просто.
В DevOps, не знаю где использовать… Но если есть задачи типа конвертировать какие-либо json, csv, прочие данные в другой формат, откуда-то прочитать, что-то куда-то загрузить, то она вполне может пригодиться. По крайней мере подобные скриптики мы тоже пытаемся делать.
Насчет зрелости согласен, следующий логичный этап — массовость.
Для Devops python очень хорош.
Ключевой момент — взаимодействие с реальным миром и внешними сервисами.
Причём обычно решение требуется уже вчера.
Тут решаюшим становится огромное количество готовых библиотек, лёгкость с которой они комбинируются в достаточно хорошее решение.
Развитый механизм работы с исключениями и утиная типизация облегчают работу в нестабильном окружении.
Так что питон мой выбор по умолчанию в небольших проектах.
А вот для игр с числами и ML однозначно буду Julia пытать.
Откровенно говоря, пошаговый отладчик — это вопрос привычки. Отладочная печать типа "@show" и "@debug" доступна в любом случае. А если разрабатываете в Atom/Juno, то есть возможность запустить выделенный фрагмент кода. Когда разрабатываете плоский скрипт, где используется минимум вложенных функций, то проблем нет вообще. Просто выделяете кусок кода и запускаете. Или вбиваете код в REPL, который находится тут же в среде разработки. Сессия со всеми переменными сохраняется до тех пор, пока её явно не перезапустите. То есть работает всё очень быстро. Плюс Juno отображает все выставленные переменные. Сложнее, когда надо отлаживать модули с большим количеством функций. Но и тут, вопрос лишь в стиле написания кода и его адаптации под отладку без пошагового отладчика. Например та самая рекомендация, что функции должны быть короткими. А их запуск в любом случае будет прописан из юнит-теста (в норме, все модули обязаны их иметь), который можно запускать из Juno.
pkg.julialang.org — в списке пакетов можно поискать еще подобного (Ctrl+F и ввести gui)
docs.juliaplots.org/latest/examples/plotlyjs, plot.ly/julia, randyzwitch.com/ECharts.jl/box
У графиков Plotly будут скроллеры, зум и пр. Также DataFrame при выводе в Notebook отображается со скроллерами. Но только первые и последние строки.
На счет статьи по интерактивному интерфейсу, до нового года взяться не готов. У меня по плану в этом году — генераторы статических отчетов и веб-сервисы. Думаю, нам надо заводить клуб джулиистов и распределять интересные темы по авторам :)
Julia. Работа с таблицами