Комментарии 48
Хотел было объяснить недоступность ссылки халатностью переводчика или автора статьи, но оказалось, что всё работает — зато мы вот так запросто судим о перспективах технологий
В то время как Julia специально создана для решения задач, связанных с высокопроизводительными вычислениями
Для этого уже существует C++ и пока что никто не смог подвинуть его с королевского места. Какие преимущества есть у Julia над плюсами?
Наверное простота и скорость разработки. Не испошьзовал julia никогда, просто предположение.
Питон действительно иногда выбешивает своей производительностью. Когда хочется быстро сразу и на pure python 3.8, а нельзя или можно с хаками и numpyами. Не, numpy хорош, но те, кто работал с векторами, например, в матлаб, наверняка помнят, насколько разработка в matlab была удобнее)
- Comparing Python, Julia, and C++
- Performance comparison with C++
- comparing C++ vs Julia
- Comparing simple simulations in Julia, Nim, C++ and R
- STL Benchmark Comparison: C++ vs. Julia
- Is it possible for Julia to perform as fast as C++? What would be necessary for Julia to be a suitable alternative to C++?
Я бы по другому вопрос поставил, какие преимущества есть у C++ перед современными (и не очень) языками программирования, особенно теми, которые заточены для решения конкретных задач? С каждым новым стандартом он становится всё монстроузнее и сложнее.
В Julia вы напишете гораздо меньше более понятного и высокоуровневого кода для решения той же задачи. При этом вы сможете гораздо быстрее отладить этот код, потому что язык динамический с опциональной типизацией, что позволяет запускать и отлаживать программы интерактивно. При этом код компилируется в нативный с использованием LLVM, поэтому производительность сопоставима с C++. Плюс из коробки удобное распараллеливание, векторизация для матричных вычислений и другие удобства языка, заточенного для scientific computing. И да, вам не нужно учить его 5 лет, чтобы не отстреливать себе ноги. :)
Судя по тому же benchmarks game, результаты реализаций предлагаемых там алгоритмов на Julia весьма далеки от реализаций на C, во многих случаях в разы (в 2-3 раза, на задаче binary-trees в 6 раз). Это не называется "сопоставима".
Там если коды посмотреть, можно заметить, что имплементации отличаются. Плюс на производительность у сей и плюсов влияет то с какими флагами вы собирали прогу, релиз или дебаг ли это, использовались ли библиотеки, а в случае с джулией использовались ли ванильные циклы или векторизованные операции, а это уже простите, сравнение с фортранновскими солверами, а также могут оказать влияние подключенные пакеты и использование средствами макросов всяких примочек типа fastmath и inbounds.
Все эти бенчмаркинги такое себе мерило — нужно смотреть по конкретным задачам. Если мне для расчета спектров вдруг понадобились полиномы Эрмита, то на питоне можно запросто найти нужную библиотеку, а вот остальную прогу уже собирать самому, где в узких местах будут кошмарные потери производительности. На плюсах расчет проходит считанные минуты, но вот реализовать там эти несчастные полиномы, а затем включить в общую логику та еще головная боль.
На джулии же, не найдя нужную библиотеку, мы запросто реализуем все что нужно, поэкспериментируем, оптимизируем и скорость будет может и ни как на сях, но вполне приемлемой. Так что Джулия — язык исследователя.
P. S. Я б так и за вольфрамовскую математику топил бы если б она была бесплатной
https://habr.com/ru/post/445134/#comment_19943428 хотя в некоторых случаях получается быстрее плюсов
А в чём именно удобство работы с матрицами и векторами в Matlab и неудобство в NumPy? NumPy спроектирован более правильно, во-первых, универсальные итераторы, которые позволяют делать срезы, транспонирование, reshape и различные views над одними и теми же данными в памяти, тогда как в Matlab всё по значению и чуть что, создаётся копия. В NumPy по возможности копия данных не создаётся. Плюс по возможности автоматическая векторизация там где в Matlab нужно делать repmat чтобы сопоставить размерности массивов (в последних версиях Matlab с этим вроде стало лучше, но не всегда).
Ну и вообще, Python как язык общего назначения значительно удобнее и богаче чем Matlab. Для Python написано огромное количество пакетов, статические анализаторы, линтеры, вокруг языка сформировалась огромная экосистема. Это сразу чувствуется при решении любой задачи программирования. Matlab очень бедный, невыразительный язык, полный костылей, с убогой stdlib, который при том ещё более медленный чем Python (попробуйте использовать классы в Matlab и почувствуете разницу). В Matlab вы не можете сделать, например, так:
function b = a()
b = zeros(1, 10)
c = b()(1:5)
Вы получите ошибку: ()-indexing must appear last in an index expression.
. То есть нарушается цепочка вызовов, тогда как в Python вы всегда можете сделать любую цепочку вызовов в любом месте.
В Matlab вы не можете определить функцию в консоли, потому что там функции — это не объекты первого класса:
Error: Function definition not supported in this context. Create functions in code file.
Matlab — убогий язык, который к тому же располагает писать лапшеобразный говнокод, потому что большинство используют его как большой калькулятор, не задумываясь о качестве кода и его поддержке.
Какие преимущества есть у Julia над плюсами?
У Юли низкий порог вхождения при той же производительности (в большинстве требуемых для целевой юзергруппы языка случаев). Быстрый и простой язык для научного моделирования/макетирования.
Корректнее её сравнивать всё таки с Питоном, у них ЦА в некоторой степени пересекаются, только Юля производительнее и удобнее для непрограммистов (особенно в многопоточности), а Питон зрелее как язык (особенно библиотек касается).
По крайней мере с С++ они точно несравнимы, совершенно разные, противостоящие даже области приложения и этапы разработки.
Что интересно, думаю, большинство этих крупных библиотек для анализа данных и машинного обучения развиваются не благодаря Питону, а вопреки — вынося по сути весь свой core-функционал в код на C/C++, либо даже на Fortran'е.
В том, что касается корпоративной разработки, новый язык программирования Go от Google представляет реальную угрозу для Java.Мне кажется, авторы не слишком знакомы с корпоративной разработкой. Go еще вчера в модульность толком не умел, это же смешно говорить про альфа-версию ЯП рядом со словом «корпоративный». Видимо, перспективы Julia такие же.
Ещё раз хочу поблагодарить за книгу. Глянул сейчас — ёлы-палы, да там же моя любимая STM32F3DISCOVERY! Вот теперь действительно появляется отличный шанс взглянуть на Руст из области, досконально мне известной на С!
Сможет ли Julia побороть Python так же, как Python поборол JavaЯ может что-то пропустил, но разве Python поборол Java? Они, вроде, как занимали почти не пересекающиеся ниши, так и занимают. Да и другие языки он если и потеснил, то не сильно. Возросла популярность не Python как языка, а тех предметных областей, в которых он широко применяется.
Несмотря на то, что Java все еще используется для корпоративной разработки, ее актуальность в других областях близка к нулю.Я тоже так могу:
Несмотря на то, что Python широко используется для Data Science, его актуальность в других областях близка к нулю.
Есть лож и есть статистика.
Когда популярность и распространенность языка оценивают по количеству глупых (точнее примитивных вопросов от ленивых людей) на ресурсах типа stackoverflow
>широко используется для Data Science
Вы знаете, там же широко используется также и Java (и особенно scala). Обычно в виде ETL, но ведь в реальных задачах без этого ETL не бывает никакого Data Science.
А с учетом того, что есть мобильная разработка, где для андроида по большей части либо Java, либо котлин, вот эта вот фраза:
>ее актуальность в других областях близка к нулю.
на мой взгляд просто ложь. А андроид, между тем, это очень очень много разработки. И как раз актуальность питона в этой области близка к нулю реально (хотя это и возможно).
Julia несколько месяцев? Што? Я про этот язык услышал ещё в 2014, до того, как познакомился с D и Rust. Может, это версии 1.0 столько, но сам-то язык развивается минимум лет 6 уже.
Еще недавно почти в любом проекте последний коммит вчера, или на прошлой неделе. Сейчас чаще год назад. Или пару. Или шесть лет назад. Для совместимости с Python 3 приходится править. И.т.д.
julia> s = "\u2200 x \u2203 y"
"∀ x ∃ y"
julia> s[1]
'∀': Unicode U+2200 (category Sm: Symbol, math)
julia> s[2]
ERROR: StringIndexError("∀ x ∃ y", 2)
[...]
julia> s[3]
ERROR: StringIndexError("∀ x ∃ y", 3)
Stacktrace:
[...]
julia> s[4]
' ': ASCII/Unicode U+0020 (category Zs: Separator, space)
Почему операция s[i] возвращает ошибку для индексов 2 и 3? Почему программисту нужно помнить внутреннюю кодироку строки и количество байт в каждом символе? В Python 3 эту проблему давно решили раз и на всегда.
С Юникодом всё становится сложно. Лучше бить пользователя по рукам и заставлять писать код в высокоуровневых терминах (нужно найти символ, найти подстроку/регулярку, развернуть строку и т.п.), чем прятать это за внешней "простотой" прямой индексации и платить за это производительностью, как сделали в Python.
Объясняет Карпински
Объясняет документация Раста
Вот тут согласен. Потому как я недавно попробовал реализовать 2 похожих сценария и там и там и результаты меня удивили.
Я даже статью написал по этому поводу.
А Julia мне зашла, как альтернатива Matlabу и C/C++ =) Так, есть конечно, к чему стремится, но уже сейчас, можно достаточно серьезные вещи кодить.
Ядро матлаба написано на Си. На Java написана IDE и графическая подсистема (figure, GUI-виджеты и т.д). Само ядро (работа с массивами) очень хорошо оптимизировано и работает очень быстро. С Octave можно даже не сравнивать, там многие функции написаны просто в лоб без всякой оптимизации (я когда-то ковырялся в исходниках Octave, был в небольшом шоке). Для матлаба можно писать функции на Си и С++ (mex-функции), но API там очень своеобразный (mxArray и вот это всё). Также писанину на матлабе можно интегрировать через Matlab Engine или MCR (Matlab compiler runtime), или транслировать с Си через Matlab coder, но всё это всё равно медленно, криво и стоит больших денег. MCR стоил несколько лет назад $10к, а матлаб со всеми тулбоксами переваливал за $100k. Безумие.
Производительность и архитектура самого языка матлаба (m-language) оставляет желать лучшего, он просто ужасен. В Этом плане Julia, да и Python просто совершенство.
Взять хотя бы параллельные вычисления. В Julia это сделано очень хорошо, тогда как в матлабе есть Distributed computing server и parfor, по сути параллелизм на процессах как multiprocessing в Python, только накладные расходы выше раз в 10 если не больше.
Не слишком ли субъективны утверждения о каких-то абстрактных «победах» одних языков над другими?
Каждый язык подходит под определенные нужды, каждый разработчик определяет свои нужды и использует подходящий для этого стэк.
Вот что значит, что Python «победил» Java? На Java разве больше не пишут? Или на Python-е можно теперь писать приложения для Android?
Я бы понял, если бы все эти языки были взаимозаменяемыми, ну или хотя бы единственными в своём роде. А так – языков море, кто-то предпочтет для написания бэкенда Python, кто-то Java (такие люди ещё существуют), а кто — вообще напишет его на Node.js; но при этом сомневаюсь, что на Python или Node.js (мы же не говорим про React Native, верно?) можно писать приложения с такой же легкостью, как это происходит с Java.
Странная статья.
Сможет ли Julia побороть Python так же, как Python поборол Java