Насколько зрел проект научного языка «Юлия»?

55

Я рассматриваю возможность изучения нового языка для использования в проектах численного / имитационного моделирования в качестве (частичной) замены для C ++ и Python, которые я сейчас использую. Я столкнулся с Джулией , которая звучит как-то идеально. Если он выполняет все свои требования, я мог бы использовать его для замены как C ++, так и Python во всех моих проектах, поскольку он может получить доступ к высокоуровневому коду библиотеки научных вычислений (включая PyPlot), а также запускать циклы с такой же скоростью, что и C. Я также выиграл бы от таких вещей, как правильные сопрограммы, которых нет ни на одном из других языков.

Тем не менее, это относительно новый проект, в настоящее время в версии 0.x, и я обнаружил различные предупреждения (опубликованные в разные даты в прошлом), что он не совсем готов для повседневного использования. Следовательно, я хотел бы получить некоторую информацию о состоянии проекта прямо сейчас (февраль 2014 года или всякий раз, когда публикуется ответ), чтобы помочь мне оценить, стоит ли мне лично уделять время для изучения этого языка на данном этапе.

Я был бы признателен за ответы, которые сосредоточены на конкретных фактах о проекте Юлия ; Меня меньше интересуют мнения, основанные на опыте других проектов.

В частности, комментарий Джеффа Оксберри говорит о том, что API Julia все еще находится в состоянии изменения и требует обновления кода при его изменении. Я хотел бы получить представление о степени, в которой это происходит: какие области API стабильны, а какие могут измениться?

Я предполагаю, что обычно я в основном занимался бы линейной алгеброй (например, решением собственных задач), численной интеграцией ODE со многими переменными и построением графиков с использованием PyPlot и / или OpenGL, а также низкоуровневым вычислением чисел в стиле C (например, для моделирования методом Монте-Карло). ). Полностью ли развита библиотечная система Юлии в этих областях? В частности, является ли API более или менее стабильным для этих видов деятельности, или я обнаружу, что мой старый код будет иметь тенденцию ломаться после обновления до новой версии Julia?

Наконец, есть ли другие вопросы, которые стоит рассмотреть, решая, использовать ли Джулию для серьезной работы в настоящее время?

Натаниель
источник
2
Этот вопрос выглядит так, как будто он не очень подходит для формата Stack Exchange, потому что он субъективен. Я знаю некоторых людей, которые активно развиваются в Julia, любят его и думают, что он полностью готов к работе в прайм-тайм (если вы готовы обновить свою кодовую базу в ответ на изменения в Julia API). Есть другие люди, которые не чувствуют необходимости использовать Джулию прямо сейчас (как я).
Джефф Оксберри
1
Субъективность сама по себе не делает вопрос неподходящим для формата Stack Exchange - см. Blog.stackoverflow.com/2010/09/good-subjective-bad-subjective . Если у вас есть политика сайта против субъективных вопросов, тогда я прошу прощения. Тем не менее, я думаю, что это только немного субъективно: уже ваш комментарий дает мне лучшее представление о ситуации, чем я задавал вопрос. Для постороннего может быть очень трудно получить даже грубое представление о том, насколько зрел проект.
Натаниэль
Ваше замечание об изменениях API кажется мне очень важным, поэтому я добавил параграф к вопросу, в котором специально уточняются детали. Если обновление Джулии, как правило, нарушит мой старый код, на данном этапе это может немного нарушить условия сделки.
Натаниэль
Вы абсолютно правы в отношении «хорошего субъективного против плохого субъективного» (одно из моих любимых сообщений в блоге Stack Exchange); Я разместил комментарий, потому что я жду ответа. С этим "что вы думаете о _____?" вопросы, ответы могут быть ограничены парой очень хорошо продуманных постов, или они могут быть растянутыми, повсеместными, повторяющимися "я тоже!" сообщения. Первый великолепен; последнее не так, поэтому я вежливо говорю вам: давайте посмотрим, как это закончится.
Джефф Оксберри
3
Спасибо за публикацию награды, @AntonMenshov. Хочу заметить, что сейчас Юлия прошла версию 1.0 (чего не было в 2014 году, когда я ее опубликовал), так что было бы очень полезно получить актуальный ответ.
Натаниэль

Ответы:

44

Джулия, на данный момент (май 2019, Джулия v1.1 с v1.2 скоро выйдет) вполне готова для научных вычислений. Релиз v1.0 означал конец ежегодной поломки кода . При этом многие научные вычислительные библиотеки успели просто расти без сбоев. Широкий обзор пакетов Julia можно найти на pkg.julialang.org .

Для основных научных вычислений, то DifferentialEquations.jl библиотека для дифференциальных уравнений (ОДУ, сдесь, ДАЕС, DDEs, Gillespie моделирования и т.д.), Flux.jl для нейронных сетей, а JuMP библиотека для математического программирования (оптимизации: линейная, квадратичная, смешанное целое и т. д. программирование) - три краеугольных камня научной вычислительной экосистемы. В частности, библиотека дифференциальных уравнений гораздо более развита, чем то, что вы видели бы на других языках, с большой группой разработчиков, реализующей такие функции, как интеграторы EPIRK , Рунге-Кутта-Нистром , дифференциальное уравнение с жесткой / дифференциально-алгебраической задержкой иИнтеграторы адаптивных стохастических дифференциальных уравнений с адаптивным по времени , наряду с кучей других полезностей, таких как анализ сопряженной чувствительности , DSL химических реакций, безматричный матрица Ньютона-Крылова и полная совместимость с GPU (без передачи данных), с обучением нейронных дифференциальных уравнений , все с фантастические результаты тестов (отказ от ответственности: я ведущий разработчик).

То, что немного ошеломляет в зрелой экосистеме Джулии, - это ее сочетаемость. По сути, когда кто-то создает универсальную библиотечную функцию, подобную тем, которые используются в DifferentialEquations.jl, вы можете использовать любой тип AbstractArray / Number для генерации нового кода на лету. Так, например, есть библиотека для распространения ошибок ( Measurements.jl ), и когда вы вставляете ее в решатель ODE, она автоматически компилирует новую версию решателя ODE, которая выполняет распространение ошибок без выборки параметров . Из-за этого вы можете не найти некоторые документированные функции, потому что код для функций генерирует сам себя, и поэтому вам нужно больше думать о компоновке библиотеки.

Одним из способов, где композиция наиболее полезна, является линейная алгебра. Решатели ODE, например, позволяют вам указывать jac_prototype, давая вам возможность указать тип якобиана, который будет использоваться для внутренних целей. Конечно , есть вещи , в стандартной библиотеке LineraAlgebra , как Symmetricи Tridiagonalвы можете использовать здесь, но , учитывая полезность composibility в общих алгоритмах типа, люди теперь пошли и построили целые библиотеки типа массива. BandedMatrices.jl и BlockBandedMatrices.jl являются библиотеками, которые определяют ( блочные ) типы полосовых матриц, которые имеют быстрые luперегрузки, что делает их хорошим способом ускорить решение жестких MOL-дискретизаций систем уравнений в частных производных. PDMats.jlпозволяет задавать положительно определенные матрицы. Elemental.jl позволяет вам определять распределенный разреженный якобиан. CuArrays.jl определяет массивы на GPU. И т.п.

Тогда у вас есть все ваши типы чисел. Unitful.jl выполняет проверку модулей во время компиляции, поэтому это библиотека модулей без лишних затрат. DoubleFloats.jl - это быстрая библиотека с более высокой точностью, наряду с Quadmath.jl и ArbFloats.jl . ForwardDiff.jl - это библиотека для автоматического дифференцирования в прямом режиме, использующая арифметику двойных чисел. И я могу продолжать перечислять их. И да, вы можете добавить их в достаточно универсальные библиотеки Julia, такие как DifferentialEquations.jl, чтобы скомпилировать версию, специально оптимизированную для этих числовых типов. Даже что-то вроде ApproxFun.jlкоторая функционирует как алгебраические объекты (например, Chebfun) работает с этой общей системой, позволяя задавать PDE как ODE на скалярах в функциональном пространстве.

Учитывая преимущества компоновки и то, как типы могут использоваться для генерации нового и эффективного кода на универсальных функциях Julia, было проделано много работы, чтобы внедрить основные функциональные возможности научных вычислений в чистую Julia. Optim.jl для нелинейной оптимизации, NLsolve.jl для решения нелинейных систем, IterativeSolvers.jl для итерационных решателей линейных систем и собственных систем, BlackBoxOptim.jl для оптимизации черного ящика и т. Д. Даже библиотека нейронных сетей Flux.jl просто использует CuArrays. jl - автоматическая компиляция кода в GPU для его возможностей GPU. Эта совместимость была основой того, что создавало такие вещи, как нейронные дифференциальные уравнения в DiffEqFlux.jl, Вероятностные языки программирования, такие как Turing.jl , также достаточно развиты и используют те же базовые инструменты.

Поскольку библиотеки Джулии основаны на инструментах генерации кода, неудивительно, что существует множество инструментов для генерации кода. Система вещания Джулии генерирует слитые ядра на лету, которые перегружены типами массивов, чтобы предоставить множество функций, упомянутых выше. CUDAnative.jl позволяет компилировать код Julia для ядер GPU. ModelingToolkit.jl автоматически удаляет сахара из AST в символическую систему для преобразования математического кода. Cassette.jlпозволяет вам «перезаписать» чужую существующую функцию, используя правила, чтобы изменить их функцию перед временем компиляции (например: изменить все их распределения массива на статические распределения массива и перенести операции в графический процессор). Это более продвинутый инструментарий (я не ожидаю, что все, кто занимается научными вычислениями, получат прямой контроль над компилятором), но именно так строится множество инструментов следующего поколения (или, скорее, как сами функции пишут).

Что касается параллелизма, я упомянул графические процессоры, а у Юлии встроены многопоточность и распределенные вычисления . Многопоточность Julia очень скоро будет использовать архитектуру выполнения параллельных задач (PARTR), которая позволяет автоматизировать планирование вложенной многопоточности . Если вы хотите использовать MPI, вы можете просто использовать MPI.jl . И, конечно же, самый простой способ использовать все это - просто использовать настройку типа AbstractArray для использования параллелизма в своих операциях.

У Джулии также есть базовая экосистема, которую можно ожидать от языка общего назначения, используемого для научных приложений. Он имеет Juno IDE со встроенным отладчиком с точками останова , имеет Plots.jl для создания всевозможных графиков. Многие специальные инструменты также хороши, например, Revise.jl автоматически обновляет ваши функции / библиотеку при сохранении файла. У вас есть DataFrames.jl , библиотеки статистики и т. Д. На самом деле одна из самых хороших библиотек - это Distributions.jl, которая позволяет вам писать алгоритмы, общие для дистрибутива (например:rand(dist)принимает случайное число независимо от того, какой дистрибутив был передан), и существует целая масса одномерных и многомерных распределений (и, конечно, диспетчеризация происходит во время компиляции, что делает все это так же быстро, как жесткое кодирование функции, специфичной для данного распределения). Существует множество инструментов обработки данных , веб-серверов и т. Д. Вы называете это. На данный момент он достаточно зрел, чтобы, если есть фундаментальная научная вещь, и вы ожидаете, что она будет существовать, вы просто отправите ее в Google с помощью .jl или Джулии, и она появится.

Тогда есть несколько вещей, которые нужно иметь в виду на горизонте. PackageCompiler ищет сборки двоичных файлов из библиотек Julia, и он уже имеет некоторые успехи, но нуждается в доработке. Makie.jl - это целая библиотека для графического ускорения с интерактивностью, и ей все еще нужно немного поработать, но она действительно стремится стать главной библиотекой для графиков в Юлии. Zygote.jl - это библиотека автоматического разграничения от источника к источнику, в которой нет проблем с производительностью AD на основе трассировки (Flux's Tracker, PyTorch, Jax) и которая работает со всеми чистыми кодами Julia. И т.п.

В заключение, вы можете найти много движений во многих местах, но в большинстве областей уже есть солидная зрелая библиотека. Это больше не в том месте, где вы спрашиваете «будет ли это принято?»: Юлия была усыновлена ​​достаточным количеством людей (миллионы загрузок), что у нее есть импульс, чтобы остаться навсегда. У него действительно приятное сообщество, так что если вы когда-нибудь захотите просто попутаться и поговорить о параллельных вычислениях или численных дифференциальных уравнениях, некоторые из лучших чатов для этого находятся в Julialang Slack . Является ли это языком, который вы должны выучить, это личный вопрос, и является ли это правильным языком для вашего проекта, это технический вопрос, и это разные. Но разве это язык, который созрел и пользуется поддержкой большой последовательной группы разработчиков? Это кажется утвердительным да.

Крис Ракауцкас
источник
2
Отличный ответ. Один вопрос: допускает ли Джулия постепенную эволюцию из исследовательского кода в производственные системы? Или это больше похоже на матлаб, где нет надежды?
user14717
6
Многие пакеты, такие как DifferentialEquations.jl, начинались как код для исследовательского проекта . Система упаковки Julia позволяет довольно просто преобразовать рабочий код в пакет с CI и модульными тестами для будущего обслуживания. А тот факт, что большая часть кода написана исключительно на языке Julia, значительно упрощает развертывание, поскольку вам не нужно поддерживать кучу сборочных систем / двоичных файлов. Так что я бы определенно сказал да. У нас есть несколько проприетарных кодов, которые скоро будут выпущены. Единственное, что до сих пор не хватает, это сборка двоичных файлов (PackageCompiler).
Крис Ракауцкас
28

Если нет, то можно ли дать приблизительную оценку по порядку величины, как долго я должен ждать, прежде чем снова рассмотреть ее?

Моя грубая оценка по порядку величины того, сколько времени требуется языкам вычислительной науки, - около десяти лет.

Пример 1: SciPy началась в 2001 году или около того. В 2009 году был выпущен Scipy 0.7.0, и у интегратора ODE был интерфейс к VODE (что ode15sпримерно эквивалентно ; ode15sоснован на NDF, VODE - BDF / Adams-Bashforth, в зависимости от). В SciPy 0.10.0, интерфейсе dopri5, который примерно эквивалентен MATLAB ode45, метод 4-го порядка Рунге-Кутты обычно вводится в качестве первого практического метода численного интегрирования для студентов. SciPy 0.10.0 был выпущен в декабре 2011 года, и им потребовалось около 10 лет, чтобы включить функцию MATLAB, представленную каждому знакомому мне инженеру.

Пример 2: Mathworks был основан в 1984 году. В своем первом выпуске они использовали порт LAPACK для C с именем JACKPAC (после Джека Литтла, инженера MathWorks, который написал его). Они не заменили его на LAPACK до 2000 года.

Джулия может занять меньше времени, но я бы оценил около 10 лет с момента основания, чтобы стать мейнстримом. (Уже прошел год или около того; может быть, 9-10 лет, тогда?)

Полностью ли развита библиотечная система Юлии в этих областях? В частности, является ли API более или менее стабильным для этих видов деятельности, или я обнаружу, что мой старый код будет иметь тенденцию ломаться после обновления до новой версии Julia?

Я не использую Джулию, поэтому возьмите то, что я говорю, с крошкой соли, так как я только видел, как Джефф Безансон делал презентации о Джулии. Они наклонились назад, чтобы было проще связывать и использовать библиотеки из C, Python и Fortran. Если вы не можете найти библиотеку Julia, которая делает то, что вы хотите, напишите прокладку Julia для библиотеки на более устоявшемся языке. Следовательно, я не думаю, что нехватка библиотек будет проблемой. Я думаю, что проблема будет заключаться в том, чтобы изменения в основных функциях языка не кусали вас в задницу. Если вы посмотрите на вехи в репозитории Julia Git, то увидите, что тег «Breaking» используется довольно редко (12 раз в версии 0.2, 5 раз в версии 0.3). Для меня это говорит о том, что базовый язык все еще развивается, поэтому я не решаюсь использовать этот язык прямо сейчас.

РЕДАКТИРОВАТЬ: Аврелий поднимает хороший вопрос:

С чего вы взяли, что Джулия когда-нибудь станет мейнстримом, а не просто умрет в безвестности, как многие другие языки? У SciPy / numpy была / есть поддержка постоянно растущего сообщества питонов, которого нет у Джулии.

В первоначальном ответе я решил избежать вопроса: "Успеет ли Джулия стать мейнстримом?" насколько это возможно. Сбой легко; успех это сложно. Я думаю, что лучшее сравнение Юлии с техническими языками вычислений, такими как MATLAB, R и Octave. Языки HPC (Chapel, Fortress, UPC и т. Д.) Имеют более узкую аудиторию, чем языки технических вычислений, а языки общего назначения (C, Python, C ++ и т. Д.) Имеют более широкую аудиторию, чем языки технических вычислений.

Что-то, что, как мне кажется, помогает Юлии, это дизайн для исполнения без ущерба для выразительности. Джулия намного более конкурентоспособна с такими компилируемыми языками, как C, чем MATLAB, R или даже Python. Эта цель разработки также является функцией, которая может привлечь людей из существующих языков, таких как:

  • Люди, которые очень заботятся о производительности и приходят из таких языков, как C и Fortran, но готовы пожертвовать крошечной производительностью (возможно, в 2 раза), чтобы перейти от скомпилированного языка к меньшему количеству строк интерпретируемого языка (вместе с REPL для более быстрое развитие и тестирование).
  • Люди, которые заботятся о высокой производительности и приходят из таких языков, как Python, R и MATLAB, но хотят большей производительности. Когда дело доходит до исполнения, чистый Python, чистый MATLAB и чистый R работают медленно. Разработчики на этих языках изо всех сил стараются обернуть библиотеки в скомпилированные языки, но вы не можете обернуть все, и в какой-то момент базовый язык замедлит вас. Ядро Джулии быстрее, что позволяет быстрее заниматься наукой.
  • Люди, которые заботятся о свободном программном обеспечении. Юлия интерпретируется и свободна (как и Питон, Октава и т. Д.); MATLAB нет.

Юлия также пытается облегчить параллелизм; Я не чувствую себя достаточно квалифицированным, чтобы углубляться в этот вопрос, и я не думаю, что это основная черта языка, но я думаю, что это точка продажи, над которой они работают, и я надеюсь, что другие могут пролить свет на это.

Тем не менее, даже с технической заслугой на их стороне, создатели языка должны сделать работу по продвижению языка и евангелизации. Джефф Безансон, Алан Эдельман, Стивен Карпински и Вирал Шах очень стараются, чтобы язык стал успешным. Алан Эдельман имеет тесные связи с сообществом вычислительных наук, и раньше он работал над проектами на уровне языка (особенно над расширением Star-P для MATLAB). Джефф Безансон некоторое время проводил конференцию, чтобы представить Джулию ученым и инженерам в области вычислительной техники. В Массачусетском технологическом институте они проделали хорошую работу по набору студентов и сотрудников (в частности, Стивена Джонсона), чтобы внести свой вклад, добавив библиотеки к Джулии. У них есть статья в Wired, и им удалось получить статью для Википедии всего за год. Их Git репо имеет тысячи звезд, сотни вилок, и сотни часов, так что по стандартам с открытым исходным кодом их проект был успешным. Я думаю, что они уже сделали все правильно, так что это вопрос поддержки этих усилий и создания сообщества. Они все еще могут потерпеть неудачу, но если я пойду далеко, это говорит о том, что у них есть разумный шанс на успех.

Джефф Оксберри
источник
С чего вы взяли, что Джулия когда-нибудь станет мейнстримом, а не просто умрет в безвестности, как многие другие языки? У SciPy / numpy была / есть поддержка постоянно растущего сообщества питонов, которого нет у Джулии. Не поймите меня неправильно, я бы хотел иметь лучший инструмент, чем C ++ / Python / Fortran / Matlab (и я ничего не знаю о Юлии), но было много попыток новых языков HPC, которые потерпели неудачу.
Аврелий
3
Что касается критических изменений, на самом деле было очень мало критических изменений языка (то есть синтаксиса, семантики) с тех пор, как до 0.1, более года назад - фактически, я не могу думать ни о каком - базовый язык достаточно стабилен. Проблемы, помеченные как «ломающиеся», являются изменениями в стандартных библиотечных API. С ними довольно легко справиться, оставив методы устаревания такими, которые позволят вашему старому коду работать, но выдают предупреждение. Пакеты находятся в гораздо более динамичном состоянии, поэтому я подозреваю, что в настоящий момент реальная проблема заключается в том, что обновление ваших пакетов может нарушить ваш код, даже если сам язык ничего не нарушает.
StefanKarpinski
Спасибо за редактирование, Джефф, хороший вклад. Я надеюсь, что что-то получится лучше. Немного извращенно думать, что еженедельно я использую Matlab для быстрого прототипирования алгоритмов, python для автоматизации / создания сценариев, а также C ++ и / или Fortran для «серьезной» работы, но это мир, в котором мы живем. м, к сожалению, пессимистично. 5-10-летняя тенденция в HPC - это разнородное программирование и массовый параллелизм, и для него сложно создать простой язык. Их тяжелый бой - очень крутой уклон по многим причинам.
Аврелий
Отличный анализ. Я действительно хотел сказать, что все, что вы делаете для HPC, всегда слегка сломано. Это инновационное пространство, где создание / ломка является нормой для курса. У Джулии много хорошего, но я думаю, что многие хитрости связаны с интеграцией LLVM, опять же, очень подвижной целью. Я бы изучил это немного, но уделил бы ему несколько лет, пока вы не собираетесь использовать его изо дня в день.
Meawoppl
21

Я верю, что Юля стоит учиться. Я использовал его для создания нескольких кодов конечных элементов исследований и очень быстрого их создания. Я был очень доволен своим опытом.

Юлия включила для меня рабочий процесс, который мне было трудно достичь с другими языками. Вы можете использовать его в качестве языка прототипирования, такого как MATLAB, но в отличие от MATLAB, когда у вас есть рабочий код и вы проходите через профилирующие итерации, чтобы ускорить его, замена горячих точек кодом C безболезненна. Они сделали взаимодействие с C (и Python) приоритетом в дизайне.

Таким образом, язык позволил мне очень быстро перейти от моих математических формулировок к функциональному коду, а затем от функционального кода к высокопроизводительному коду. Я думаю, что эта особенность Юлии недооценена, но она добавляет огромную ценность.

Во многих случаях я получил производительность C (по сравнению с моим собственным C-кодом) в течение нескольких часов после создания функционального кода конечных элементов. До сих пор, если я использую только функции Julia, я обычно получаю в ~ 3 раза медленнее, чем C. После этого я заменяю «горячие точки» функциями C (Julia поставляется с профилировщиком выборки из стека, чтобы помочь идентифицировать их). Зачастую для этого требуется только заменить строки кода «горячей точки», вызывающие проблемы, на «ccall», при этом Джулия обрабатывает любые сортировки.

Я думаю, что главное, чего сейчас не хватает Джулии, хотя и заставляет меня колебаться, рассматривая это для больших проектов, - это отсутствие полностью поддерживаемого отладчика и плохая поддержка построения графиков (сейчас ваша лучшая ставка в построении графиков - это на самом деле просто интерфейс к matplotlib). что у меня были перерывы чаще, чем нет). Немедленная обратная связь по коду действительно важна. Я также не знаю, как выжить без интерактивной отладки, и в этом отношении я очень избалован MATLAB и GDB.

Reid.Atcheson
источник
Спасибо, это очень полезный ответ. У меня есть несколько дополнительных вопросов. Во-первых, вы используете выпущенную версию или не отставаете от источника? Если последнее, вы сталкиваетесь с множеством проблем, связанных с нарушением работы вашего кода из-за обновлений? Во-вторых, как точно «ломается» интерфейс к matplotlib? На самом деле я был очень рад услышать, что прорисовка проходила через matplotlib, потому что он может отображать LaTeX в метках оси (фактический LaTeX, используя установку TeX), и для меня это убийственная особенность. Но если интерфейс ненадежный, то это не так уж хорошо ...
Натаниэль
Я держу в курсе источника, потому что я также пытаюсь внести свой вклад в проект. До сих пор у меня не было никаких перерывов, но у меня был большой опыт написания и теории, и теперь я возвращаюсь к своему коду, и мы посмотрим, как это будет происходить. Числовые массивы по умолчанию имеют индекс 0 и ряд строк. а Юлия по умолчанию 1-индексированная и главная-колонка, обычно это не создает проблем, но построение неструктурированных данных требует передачи индексных массивов, поэтому мне пришлось делать странные вещи, такие как передача p'-1 в неструктурированную треугольную сетку подпрограммы, где р - индексная карта.
Reid.Atcheson
9

По моему опыту, Юлия еще не готова к (научному) повседневному использованию (я говорю о стабильной версии 0.4 от марта 2016 года). Сам язык хороший, многофункциональный и последовательный; освежающий шаг вперед как от matlab, так и от python. Конечно, есть случаи, когда Юлия - хороший выбор даже на этой ранней стадии. Но если вам нужны надежные и зрелые научные библиотеки, я не могу рекомендовать сделать это сейчас. Основные проблемы, с которыми я столкнулся:

  • Пакеты вне ядра Джулии не надежны. Они ломаются с обновлениями, меняются, заменяются, иногда являются неполными или просто сломаны.
  • Функции Джулии по параллелизму (по моему мнению, наиболее многообещающие потенциальные возможности убийцы Matlab) являются незрелыми. Вы столкнетесь с ошибками сегментации, утечками памяти, сбоями и неутешительной производительностью. Иногда они не очень хорошо играют с другими частями julia, например, с некоторыми из решателей для линейных систем или пакетов вне ядра. Хотя эти функции звучат многообещающе, для меня они часто оказываются неудачными. Почти никогда не было достаточно просто написать @parallelперед циклом for, где в теории это должно быть.
  • Множество мелочей, мелких ошибок и проблем, с которыми можно было бы смириться: не очень приятные, а иногда и ошибочные следы стека вызовов, небольшая история ошибок интерпретатора, медленная загрузка пакетов, плохая производительность того или иного пакета / функции и т. Д. Что меня раздражало большая часть - это пакет PyPlot, оболочка для matplotlib, в настоящее время альтернативы ему нет. Это действительно здорово, что он есть и в основном работает. Но если вам нужно построить данные, будьте готовы к очень медленной работе и проблемам.

Это все станет лучше. Я уверен, что когда-нибудь Джулия превзойдет Matlab и Python практически во всех аспектах. Велика вероятность, что для него будут разработаны инновационные пакеты. Кажется, что уже есть большое сообщество. Даже сейчас существует множество пакетов с вариантами использования от opencl до веб-серверов. Использовать библиотеки Python или C очень просто, так что вы, вероятно, не столкнетесь с проблемой доступности библиотек. Сильной стороной Julia будет легкость, с которой можно склеить высокопроизводительную функциональность из различных источников на современном и последовательном языке высокого уровня (см. Ответы выше). Но в целом я обнаружил, что он не является ни зрелым, ни достаточно стабильным для продуктивного использования.

johannes_lalala
источник