Есть очень неплохая книга: Гедель, Эшер, Бах. Там, в частности, рассматривается доказательство теоремы Геделя.
Не скажу, что очень просто, но, если захотеть, то, думаю, можно разобраться без математического образования.
Если у вас не возникает проблем с вычислительными задачами, то вам повезло. Если под ваши задачи хватает языка и текущих библиотек, то никто и не говорит, что нужно куда-то переходить)
На моей практике как раз постоянно возникали проблемы из-за языка, когда того же python совершенно не хватало, ни по скорости, ни по выразительности в некоторых случаях, ни по библиотекам. И дело же не только в фичах языка, а еще и в экосистеме, которая вокруг него складывается. Если попробовать делать что-то сложное на .net, например, то сразу упираешься в необходимость покупки специальных численных библиотек. В python и плюсах с этим все намного лучше, но как ни странно на Julia я перешел именно из-за экосистемы, которая позволила мне делать то, что мне нужно, а не писать велосипеды. Хотя до сих пор некоторых вещей не хватает, но для моих применений это не критично, есть FFI.
Безотносительно качества статьи, Julia годится не только для узкой группы счетоводов, не все пишут библиотеки, многие ими пользуются. И не все библиотеки вычислительные, можно прекрасно писать и веб-сервисы и гуевины, очень удобно, когда в проекте один язык.
В итоге-то, если есть инструмент, который решает нужную задачу, то люди будут им пользоваться. Те, кому и текущих средств хватает, переходить не будут, но у языка уже достаточно большое сообщество, которое сформировалось из тех, кому не хватало, далеко не узкая группа счетоводов. Те же биологи на западе по моим ощущениям массово смотрят в сторону языка, потому что им не хватает чего-то в устоявшихся.
Я писал алгоритмы автоматического управления для нефтедобычи, обработку финансовых данных и оценку всяких деривативов и GUI к этому. Весь код, к сожалению, проприетарный, так что показать не смогу.
JVM мир немного про другой контингент, основная аудитория, для которой может быть интересна Julia сидит в python, R, C/C++, Fortran, как мне кажется.
В SciPy/numpy далеко не все есть, и не все алгоритмы векторизуемы. Те же дифференциальные уравнения в python оставляют желать лучшего, а в Julia же одна из лучших библиотек по ним из всех существующих.
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 не менее удобно, чем везде, со скидкой на относительную незрелость библиотек.
Не совсем так, язык не ориентирован на тех, кто не слышал о векторизации. Чтобы просто предоставить им достаточно быстрый дефолтный вариант.
Если кому-то достаточно numpy/numba/cython и в целом python устраивает, то прекрасно. В таком случае Julia и не нужен.
Проблема как раз в том, что не все алгоритмы можно векторизовать, numba не работает всегда так, как хочется, ее может и можно приготовить лучше, но не хочется, в Julia для меня получается лучше и легче.
К тому же большинство библиотек написаны на одном языке, я всегда могу залезть в дебри, посмотреть как все устроено, в случае необходимости поправить. Для правки решения диффуров в python мне бы пришлось лезть в плюсы или фортран, я уж лучше сразу на них тогда писать буду.
Ну и последнее) В языке очень удобная для научных вычислений парадигма — multiple dispatch, сильно упрощает жизнь. Иногда вообще переносит некоторые вещи из разряда неподдерживаемых костылей в разряд доступных на практике.
Есть очень неплохая книга: Гедель, Эшер, Бах. Там, в частности, рассматривается доказательство теоремы Геделя.
Не скажу, что очень просто, но, если захотеть, то, думаю, можно разобраться без математического образования.
На моей практике как раз постоянно возникали проблемы из-за языка, когда того же python совершенно не хватало, ни по скорости, ни по выразительности в некоторых случаях, ни по библиотекам. И дело же не только в фичах языка, а еще и в экосистеме, которая вокруг него складывается. Если попробовать делать что-то сложное на .net, например, то сразу упираешься в необходимость покупки специальных численных библиотек. В python и плюсах с этим все намного лучше, но как ни странно на Julia я перешел именно из-за экосистемы, которая позволила мне делать то, что мне нужно, а не писать велосипеды. Хотя до сих пор некоторых вещей не хватает, но для моих применений это не критично, есть FFI.
Безотносительно качества статьи, Julia годится не только для узкой группы счетоводов, не все пишут библиотеки, многие ими пользуются. И не все библиотеки вычислительные, можно прекрасно писать и веб-сервисы и гуевины, очень удобно, когда в проекте один язык.
В итоге-то, если есть инструмент, который решает нужную задачу, то люди будут им пользоваться. Те, кому и текущих средств хватает, переходить не будут, но у языка уже достаточно большое сообщество, которое сформировалось из тех, кому не хватало, далеко не узкая группа счетоводов. Те же биологи на западе по моим ощущениям массово смотрят в сторону языка, потому что им не хватает чего-то в устоявшихся.
JVM мир немного про другой контингент, основная аудитория, для которой может быть интересна Julia сидит в python, R, C/C++, Fortran, как мне кажется.
Язык относительно быстро развивается, самая актуальная информация в официальной документации: https://docs.julialang.org/. Довольно понятная, кстати.
Ещё интересные статьи бывают на https://www.stochasticlifestyle.com/.
Агрегатор: https://www.juliabloggers.com/.
Ну и https://www.youtube.com/user/JuliaLanguage.
И как раз в научных вычислениях часто появляются задачи, на которые этот 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
Не совсем так, язык не ориентирован на тех, кто не слышал о векторизации. Чтобы просто предоставить им достаточно быстрый дефолтный вариант.
Если кому-то достаточно numpy/numba/cython и в целом python устраивает, то прекрасно. В таком случае Julia и не нужен.
Проблема как раз в том, что не все алгоритмы можно векторизовать, numba не работает всегда так, как хочется, ее может и можно приготовить лучше, но не хочется, в Julia для меня получается лучше и легче.
К тому же большинство библиотек написаны на одном языке, я всегда могу залезть в дебри, посмотреть как все устроено, в случае необходимости поправить. Для правки решения диффуров в python мне бы пришлось лезть в плюсы или фортран, я уж лучше сразу на них тогда писать буду.
Ну и последнее) В языке очень удобная для научных вычислений парадигма — multiple dispatch, сильно упрощает жизнь. Иногда вообще переносит некоторые вещи из разряда неподдерживаемых костылей в разряд доступных на практике.
1. Убрать аннотации типов
2. на
3. на
Не знаю почему последний пункт влияет, компилятор почему то не до конца оптимизирует.