Как стать автором
Обновить

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

Какое-то дежавю, только вчера наткнулся на эту статью; ещё подумал, ничего себе, сколько смелости и здорового оптимизма, а сегодня уже перевод на хабре. Ну, вы шустрые! :)

Звучит многообещающе. Язык уже включает много любимых мною плюшек из других языков и надеюсь он продолжит в том же духе.
Но жадность бывает губительной и в данном случае это может аукнуться сложностью поддержки и дальнейшего развития языка.
Пожалуй зарублюсь в него вечерком

Похоже изначально статью писал какой-то журналист — много разных слов вокруг да около, но конкретика отсутствует напрочь.

Возможно это от того, что даже на сайте julialang.org в резделе Examples есть всего один пример тривиального кода с функцией и элементарными вложенными циклами.

Ну как бы это не то, чем можно заинтересовать программистов в 2020-м году…

Оно похоже создаётся не для профессиональных программистов, а для широкого сообщества пользователей, прежде всего околонаучных, которые двумерные массивы в питоне вложенными циклами обсчитывают и ругаются, что медленно. Видел реализацию людьми не особо сложной проблемы включавшей систему из около 100 диффуров решавшуюся примерно так. Конечно же, авторы скорбели о медлительности питона, в остальном будучии его горячими поклонниками.

Не совсем так, язык не ориентирован на тех, кто не слышал о векторизации. Чтобы просто предоставить им достаточно быстрый дефолтный вариант.


Если кому-то достаточно numpy/numba/cython и в целом python устраивает, то прекрасно. В таком случае Julia и не нужен.


Проблема как раз в том, что не все алгоритмы можно векторизовать, numba не работает всегда так, как хочется, ее может и можно приготовить лучше, но не хочется, в Julia для меня получается лучше и легче.


К тому же большинство библиотек написаны на одном языке, я всегда могу залезть в дебри, посмотреть как все устроено, в случае необходимости поправить. Для правки решения диффуров в python мне бы пришлось лезть в плюсы или фортран, я уж лучше сразу на них тогда писать буду.


Ну и последнее) В языке очень удобная для научных вычислений парадигма — multiple dispatch, сильно упрощает жизнь. Иногда вообще переносит некоторые вещи из разряда неподдерживаемых костылей в разряд доступных на практике.

" В языке очень удобная для научных вычислений парадигма — multiple dispatch, сильно упрощает жизнь." —
это о чем речь? можно в двух словах?

И я правильно понимаю вышесказанную мысль, что Juila хорош для тех кому надо писать некие специфичные «программы на фортране», но делать это на Си не позволяют какие-то субъективные причины?

multiple dispatch это когда по-быстрому накидал функцию, скормил компилятору, и оно нагенерировало методов на все случаи жизни. За примером далеко ходить не нужно: с утра занят оживлением формул из одной статьи, и там вдруг говорится, что дифуру считали численно. Я вспоминаю, что у меня завалялась Рунге-Кутта:


function rk4(f, x, y, h)
    k1 = h * f(x       , y        )
    k2 = h * f(x + 0.5h, y + 0.5k1)
    k3 = h * f(x + 0.5h, y + 0.5k2)
    k4 = h * f(x +    h, y +    k3)

    return y + (k1 + 2*(k2 + k3) + k4)/6.0
end

В качестве аргумента f я могу закинуть какую-нибудь функцию (произвольная правая часть дифуры), прогнать по циклу, получить ответ. Функция может принимать и возвращать хоть вещественные хоть комплексные числа. А можно и вообще передавать массивы:


A = [0. 0. 1. 0.;
        0. 0. 0. 1.;
        0. 0. 0. B;
        0. 0. -B 0.]

    syst(t, u) = A * u + [0.; 0.; 0.; E] # ODE system

    u0 = [0.0; 0.0; vel; 0.0] # start cond-ns
    tspan = [0:0.5:6pi;] # time period

    Y = fill(zeros(4), length(tspan))
    Y[1] .= u0

    for i in 2:length(tspan)
        Y[i] = rk4(syst, tspan[i], Y[i-1], 0.5)
    end

Теперь оно решает систему 4 дифуров, при том, что солвер никак не пришлось изменять. Короче, это нереально круто, это вам как человек считающий денно и нощно говорю. Плюс тут подвезли символьные вычисления и оболочку для Гнуплота — так что имеем полнейший восторг и благолепие

Кстати, интересный признак — если индексы начинаются с 1 — то это язык для тех кто много считает :)
multiple dispatch позволяет специализировать функцию не по одному аргументу, во многих языках `this`, а по всем сразу. Грубой аналогией можно назвать шаблоны в плюсах, которые имеют возможность (но не обязаны) инстанцироваться в рантайме, либо та же перегрузка методов, которая может работать в рантайме. Какой-нибудь double dispatch реализуют часто с помощью паттерна visitor, в Julia же это встроено в язык. Если вам нужен triple dispatch и далее, то тут уже с visitor все становится сильно сложнее, а в Julia все так же удобно. Еще эта парадигма решает expression problem. На самом деле многие приходят в язык за скоростью, а остаются из-за парадигмы.

И как раз в научных вычислениях часто появляются задачи, на которые этот multiple dispatch хорошо ложиться. Простой пример — перемножение матриц. Мы хотим, чтобы для всех матриц работало умножение, будь это обычные плотные матрицы, разреженные, banded и так далее, а еще хочется, чтобы новые типы матриц легко интегрировались в текущий набор типов матриц и операций над ними. Парадигма языка и система типов позволяют такие проблемы решать практично и поддерживаемо. И в заключение, такое можно использовать не только для «научки», я использую язык и для общих задач, вместо python.

«И я правильно понимаю вышесказанную мысль, что Juila хорош для тех кому надо писать некие специфичные «программы на фортране», но делать это на Си не позволяют какие-то субъективные причины?» —
Для многих Julia хорош как основной язык, с чем я согласен.
Насчет причин не писать на Си/Фортран/плюсы/подставьте другой язык. Тут не только субъективные причины, те же Си и плюсы довольно тяжелые: ручное управление памятью, отстрел ног, где ни попадя, 20 способов инициализации… С python/R/SAS проблема в скорости: если вам нужно написать что-то, для чего не написана быстрая либа (под которой те же плюсы), то либо пишите на «быстром» языке, либо пишите медленный прототип, а потом переписывайте. Two language problem во всей красе. Под этим сидит еще тысяча мелких и не очень деталей, которые не дают жить спокойно. И опять же, если хватает cython или numba, то все прекрасно, но так случается далеко не всегда.
В итоге ребятам из MIT надоело, и они создали язык, на котором могли бы проводить весь цикл разработки от прототипа до продакшена. И который был бы удобен для научных задач, но при этом был языком общего назначения. Я бы сказал, что стоит смотреть на Julia, если то, что нужно сделать, не покрыто либами в python или других языках, при этом хочется писать на языке высокого уровня без необходимости подключать другие для скорости. Написание того же веб сервиса на Julia не менее удобно, чем везде, со скидкой на относительную незрелость библиотек.

Как итог: создавался для научных вычислений, но не только для них удобен. На русском есть хороший материал: habr.com/ru/company/oleg-bunin/blog/476114
Интересно посмотреть на то, что пишут те, для кого Julia основной язык. На гитхабе видно только околовычислительные задачи.

И почему, кстати, в сравнениях Julia vs… как-то стороной обходится Java мир? Всякие там Kotlin'ы или Clojure.
Я писал алгоритмы автоматического управления для нефтедобычи, обработку финансовых данных и оценку всяких деривативов и GUI к этому. Весь код, к сожалению, проприетарный, так что показать не смогу.

JVM мир немного про другой контингент, основная аудитория, для которой может быть интересна Julia сидит в python, R, C/C++, Fortran, как мне кажется.
А вот как раз насчёт GUI вопрос: к нему вообще Qt прикрутить хоть как-то можно? Не QML, виджеты?
Можно вызывать Julia из плюсов (либо по API рантайма, либо собрав бинарник), можно плюсы из Julia (Cxx.jl, CxxWrap.jl).
Есть какое-то ощущеие, что люди пытающиеся на питоновых циклах писать большие счетные объемы следуюет в первую очередь посмотреть в сторону SciPy / numpy, а не на какой-то другой язык, где их циклы будут на сколько-то быстрее.

Вот если бы Julia в свое время запихнули в ту нишу, куда запихнулся Golang, то это было бы интересно. Но куда сейчас девать его совершенно не понятно.

Маркетинг и тулинг предопределили судьбу, как это ни печально.
В SciPy/numpy далеко не все есть, и не все алгоритмы векторизуемы. Те же дифференциальные уравнения в python оставляют желать лучшего, а в Julia же одна из лучших библиотек по ним из всех существующих.

Да дело не в циклах.


Numpy/scipy — это как бы матлаб. Из типов данных есть только числа и массивы из чисел, они работают быстро. По сути, оттуда убрали всю абстракцию и "питоничность", а то что они так популярны показывает, что "производительность не важна, важна продуктивность" — это булшит (по крайней мере, в некоторых сферах).


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


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

Читал, конечно.


Всё равно же неубедительно, если пытаться реально скептика с питона перетянуть.
На самом деле, два основных аргумента от питонистов — это "намба JITит не хуже джулии" (когда код маленький и простой, так и есть) и "ну и фиг с ним, что на 5% медленнее, зато мне только декоратор @jit поставить, а вы ради этих процентов полдня код переписываете".
(Ну да, самый свежий коммент к статье:


This is all really wrong.

So a true comparison shows Julia is offering a 1.8x performance improvement to python but is far more limited in package availability, community, etc.

)


С самими бенчмарками тоже проблема, потому что код всё равно не один-в-один, и измеряется часто то, насколько проверяльщик в курсе, в каком языке как LLVM лучше ублажить.

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

Ну нет, людям нужно приносить счастье, даже когда они его не хотят, не заслуживают и сопротивляются :)
На самом деле, конечно, незачем перетягивать, надо просто ненавязчиво советовать попробовать PyJulia.

что меня добивает в юльчике, так отсутствие нормального отладчика.
Всё можно пережить, но после матлаба, например, это выводит из себя.
В остальном, язык как язык, скорее тут важно насколько он получит поддержку от
сообщества, чтобы можно было использовать другие нативные библиотеки, хотя и это тоже решается подключением других языков.
function mandelbrot(a)
    z = 0
    for i=1:50
        z = z^2 + a
    end
    return z
end


а что же они begin не ввели? так и паскаль переизобретут.
зачем тут end если табуляцией подпрограмма обосабливается
а что же они begin не ввели?

Да пожалуйста:


z = begin
    r = 0
    a = 0.5
    for i=1:50
        global r ^= 2
        global r += a
    end
    r
end

так и паскаль переизобретут.

Синтаксис создавался с оглядкой на Фортран и матлабово семейство. По мне end избавляет от питонских страданий с табуляциями пробелами, да и для извращенцев любителей однострочников раздолье


z = begin r = 0; a = 0.5; for i=1:5 global r ^= 2; global r += a; end; r end
По мне end избавляет от питонских страданий с табуляциями пробелами

Вот тут согласен на 146%. По-моему пробелы с табуляциями это вообще самое отвратительное что есть в питоне. Блин, когда отлаживаешь какую-то хрень, что-то закомментируешь, что-то раскомментируешь, и при этом получается что у здоровенного куска неверный идент, материться хочется! О чём Ван Россум думал (и каким местом) когда такой синтаксис вводил — для меня загадка.

Однострочники кстати при разумном применении рулят. Я люблю на С так писать, после условного оператора, если код по условию невелик. Читаемость резко улучшается.
По-моему пробелы с табуляциями это вообще самое отвратительное что есть в питоне.
«На вкус и цвет все фломастеры разные».
Лично я обожаю эту особенность Python, она делает даже чужой код наглядным и структурированным и бьет по пальцам любителям намешать все в не читаемый клубок кода.
Блин, когда отлаживаешь какую-то хрень, что-то закомментируешь, что-то раскомментируешь, и при этом получается что у здоровенного куска неверный идент, материться хочется!
Это решается хорошей IDE, которая позволяет коректно комментировать/раскомментировать выделенный кусок кода одной клавиатурной командой и сразу подсвечивает неправильные отступы.

А я вот из тех, кто тоже сначала тащился от обязательности отступов, но быстро охладел.


Охладел именно из-за того, что хорошая IDE сейчас автоматически расставляет отступы для кода на любом языке, и проблема нечитаемости особо нигде уже не стоит. Но в питоне расставить отступы, не зная, где они должны быть, фундаментально нельзя, а в языках с явными символами начала и конца блока — можно.


Сейчас считаю, что такой дизайн языка — это интересный эксперимент, но на самом деле ни серьёзных плюсов, ни серьёзных минусов не даёт. Пока код небольшой и не особо заумный — помогает, когда код становится большой и сложный — мешает. Но в этом весь Python, в принципе.

Для Julia здесь очень много кода… Варианты, которые более вероятно встретятся:


mandelbrot(a) = reduce((z, _) -> z^2 + a, 1:50 )

function mandelbrot(a)
    reduce((z, _) -> z^2 + a, 1:50 )
end

И даже вариант с блоком do..end в рубийном стиле:


mandelbrot(a) = reduce(1:50) do z,_
    z^2 + a
end

Julia тяготеет к функциональному стилю программирования. Поэтому конструкции map/filter/reduce и производные от них здесь используются очень широко. Плюс векторизация вычислений везде где можно. Всё это позволяет писать код очень компактно.


а что же они begin не ввели? так и паскаль переизобретут.

Касаемо do, begin, end. Эти конструкции позволяют сохранять человечность языка программирования. Естественно, можно даже переменные как в Perl называть именами $', $`, $_ и пр. И наделать каких-нибудь специальных знаков для разделения блоков. Но программа, хотя и пишется для работы машины, в первую очередь должна быть написана так, чтобы люди легко могли понять этот код. К слову, как и в Ruby, у Julia слово return является опциональным, поскольку любой метод всегда возвращает результат последней операции. И поэтому, слово return пишется тогда, когда без него не обойтись, либо для улучшения читаемости. Добавлю, что и тип аргументов в Julia пишется почти как и в Паскале.


mandelbrot(a::Number) = reduce((z, _) -> z^2 + a, 1:50 )

зачем тут end если табуляцией подпрограмма обосабливается

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

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

https://habr.com/ru/hub/julia/ — пройдитесь по хабу, уже набралось приличное количество материала, и в большинстве статей есть ссылки на множество источников и вспомогательных ресурсов

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

Язык относительно быстро развивается, самая актуальная информация в официальной документации: https://docs.julialang.org/. Довольно понятная, кстати.


Ещё интересные статьи бывают на https://www.stochasticlifestyle.com/.


Агрегатор: https://www.juliabloggers.com/.


Ну и https://www.youtube.com/user/JuliaLanguage.

На Шпрингере временно открыт доступ ко многим книгам.
По Julia есть Quick Syntax Reference.


Совсем для начинающих введение Think Julia.


Из менее открытого мне показались годными Julia High Performance от одного из разработчиков языка (не надо смотреть на High Performance, про него там немного, в основном тоже краткое руководство) и Hands-On Design Patterns and Best Practices with Julia (глава в свободном доступе).

Python — язык общего назначения. Julia — язык, создававшийся для вычислений. Любой язык для вычислений обязан быть быстрее языка общего назначения, иначе зачем он тогда создавался. И это для него будет норма, а не победа. Но там, где есть упор на одно, есть просадка в другом.


Не все программисты — гики. Это значит, что у большинства нет потребности решая 10 разных задач использовать 10 разных языков, каждый из которых делает своё дело идеально. Всё сводится к использованию 2-3 языков.


Я занимаюсь и вебом и (консольным) софтом для пк на каком-то своём, не очень высоком уровне. Моим задачам до сих пор не нужен объектно-ориентированный подход, не нужна работа с указателями и много других типов задач. Я выполняю задачи, которые не требуют каких-то особых возможностей языка. Тем не менее это не означает, что я решаю простые задачи. Одна из них — аппроксимация кривых Безье и генерация G-кода для ЧПУ-станка. Мне сложно представить, чтобы «язык стал меня сдерживать». Я сам сдерживаю язык. Он говорит мне: «Чувак, смотри, у меня есть куча крутых фич!», а я ему: «Воу, полегче! Мне и старых пока хватает.».


Подобные статьи — это попытка переманить часть питонистов, которые что-то где-то вычисляют. Ни о какой замене Python на Julia даже речи нет, разве что для узкой группы счетоводов.

Если у вас не возникает проблем с вычислительными задачами, то вам повезло. Если под ваши задачи хватает языка и текущих библиотек, то никто и не говорит, что нужно куда-то переходить)

На моей практике как раз постоянно возникали проблемы из-за языка, когда того же python совершенно не хватало, ни по скорости, ни по выразительности в некоторых случаях, ни по библиотекам. И дело же не только в фичах языка, а еще и в экосистеме, которая вокруг него складывается. Если попробовать делать что-то сложное на .net, например, то сразу упираешься в необходимость покупки специальных численных библиотек. В python и плюсах с этим все намного лучше, но как ни странно на Julia я перешел именно из-за экосистемы, которая позволила мне делать то, что мне нужно, а не писать велосипеды. Хотя до сих пор некоторых вещей не хватает, но для моих применений это не критично, есть FFI.

Безотносительно качества статьи, Julia годится не только для узкой группы счетоводов, не все пишут библиотеки, многие ими пользуются. И не все библиотеки вычислительные, можно прекрасно писать и веб-сервисы и гуевины, очень удобно, когда в проекте один язык.

В итоге-то, если есть инструмент, который решает нужную задачу, то люди будут им пользоваться. Те, кому и текущих средств хватает, переходить не будут, но у языка уже достаточно большое сообщество, которое сформировалось из тех, кому не хватало, далеко не узкая группа счетоводов. Те же биологи на западе по моим ощущениям массово смотрят в сторону языка, потому что им не хватает чего-то в устоявшихся.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий