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

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

То что ссылка на стабильный релиз не доступна, отлично иллюстрирует перспективы языка: убийцей Python и Matlab он так и не стал, что впрочем связанно с объективными недостатками.

Хотел было объяснить недоступность ссылки халатностью переводчика или автора статьи, но оказалось, что всё работает — зато мы вот так запросто судим о перспективах технологий

Потому что автор перевода обновил её и теперь она работает, однако ведет на релиз 1.3, супротив указанного 1.2. Но это так зануда mode on.
У меня работала с самого начала ссылка.
Ну с учетом того что мой комментарий был первый, то я один из первых читателей статьи и могу засвидетельствовать что ссылка изменилась, сначала она вела на неработающую страницу релиза 1.2, сейчас на работающую для 1.3
НЛО прилетело и опубликовало эту надпись здесь
Еще пара недель есть же!
В то время как Julia специально создана для решения задач, связанных с высокопроизводительными вычислениями

Для этого уже существует C++ и пока что никто не смог подвинуть его с королевского места. Какие преимущества есть у Julia над плюсами?

Наверное простота и скорость разработки. Не испошьзовал julia никогда, просто предположение.
Питон действительно иногда выбешивает своей производительностью. Когда хочется быстро сразу и на pure python 3.8, а нельзя или можно с хаками и numpyами. Не, numpy хорош, но те, кто работал с векторами, например, в матлаб, наверняка помнят, насколько разработка в matlab была удобнее)

Интересный комментарий, но я интересовался преимуществами над С++, т.к. Julia (исходя из статьи) претендует на роль языка для высокопроизводительных вычислений.
В статье по ссылке динамическая типизация преподносится как плюс, хотя даже питон уже хочет отказаться от этого. Дальше читать не вижу смысла.

p.s. Нет смысла измерять что-либо если вы не измеряете при этом погрешность. График некорректный.

Я бы по другому вопрос поставил, какие преимущества есть у C++ перед современными (и не очень) языками программирования, особенно теми, которые заточены для решения конкретных задач? С каждым новым стандартом он становится всё монстроузнее и сложнее.


В Julia вы напишете гораздо меньше более понятного и высокоуровневого кода для решения той же задачи. При этом вы сможете гораздо быстрее отладить этот код, потому что язык динамический с опциональной типизацией, что позволяет запускать и отлаживать программы интерактивно. При этом код компилируется в нативный с использованием LLVM, поэтому производительность сопоставима с C++. Плюс из коробки удобное распараллеливание, векторизация для матричных вычислений и другие удобства языка, заточенного для scientific computing. И да, вам не нужно учить его 5 лет, чтобы не отстреливать себе ноги. :)

Судя по тому же benchmarks game, результаты реализаций предлагаемых там алгоритмов на Julia весьма далеки от реализаций на C, во многих случаях в разы (в 2-3 раза, на задаче binary-trees в 6 раз). Это не называется "сопоставима".

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


Все эти бенчмаркинги такое себе мерило — нужно смотреть по конкретным задачам. Если мне для расчета спектров вдруг понадобились полиномы Эрмита, то на питоне можно запросто найти нужную библиотеку, а вот остальную прогу уже собирать самому, где в узких местах будут кошмарные потери производительности. На плюсах расчет проходит считанные минуты, но вот реализовать там эти несчастные полиномы, а затем включить в общую логику та еще головная боль.
На джулии же, не найдя нужную библиотеку, мы запросто реализуем все что нужно, поэкспериментируем, оптимизируем и скорость будет может и ни как на сях, но вполне приемлемой. Так что Джулия — язык исследователя.
P. S. Я б так и за вольфрамовскую математику топил бы если б она была бесплатной

НЛО прилетело и опубликовало эту надпись здесь

А в чём именно удобство работы с матрицами и векторами в 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 над плюсами?

У Юли низкий порог вхождения при той же производительности (в большинстве требуемых для целевой юзергруппы языка случаев). Быстрый и простой язык для научного моделирования/макетирования.
Корректнее её сравнивать всё таки с Питоном, у них ЦА в некоторой степени пересекаются, только Юля производительнее и удобнее для непрограммистов (особенно в многопоточности), а Питон зрелее как язык (особенно библиотек касается).
По крайней мере с С++ они точно несравнимы, совершенно разные, противостоящие даже области приложения и этапы разработки.
В анализе данных великолепие Питона не в самом Питоне, а в огромном количестве библиотек. Библиотек вылизанных, больших, некоторые из которых даже можно называть полноценными инструментами. И пока критическая масса таких библиотек не будет доступна в похожем виде на любом другом языке X — никто в анализе данных не пересядет на этот язык X. Как только это случится, то думаю не ошибусь, если скажу, что многие будут рады покинуть территорию Питона.
Что интересно, думаю, большинство этих крупных библиотек для анализа данных и машинного обучения развиваются не благодаря Питону, а вопреки — вынося по сути весь свой core-функционал в код на C/C++, либо даже на Fortran'е.
В том, что касается корпоративной разработки, новый язык программирования Go от Google представляет реальную угрозу для Java.
Мне кажется, авторы не слишком знакомы с корпоративной разработкой. Go еще вчера в модульность толком не умел, это же смешно говорить про альфа-версию ЯП рядом со словом «корпоративный». Видимо, перспективы Julia такие же.
НЛО прилетело и опубликовало эту надпись здесь
А для эмбеддед задачь, кроме СИ, что-нибудь маячит на горизонте хотя бы в перспективе? Ассемблер не всчёт.
НЛО прилетело и опубликовало эту надпись здесь

Rust. У него целая команда занимается оптимизацией языка под микроконтроллеры. И целую книгу написали.

С Рустом не знаю даже… В С (и отчасти С++ если без заумных библиотек), я более всего ценю его прозрачность. Т.е. смотря на сишный код, довольно легко понять во что он развернётся. Если Вы пишете приложение для бухгалтерии, это не очень важно. Но если пытаетесь управлять коробкой скоростей автомобиля, то сами понимаете… Так вот, не знаю дело тут в моих кривых руках или в принципе, но с Рустом я и на десятую долю не ощутил такой прозрачности. Так что игрушку написать на Русте я бы наверно согласился. Но брать его в проект реального времени наверно побоялся бы. Впрочем спасибо за ссылку. Обязательно почитаю. Возможно это я чего-то не понял. С наступающим! Удачных проектов в новом году!

Ещё раз хочу поблагодарить за книгу. Глянул сейчас — ёлы-палы, да там же моя любимая 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 уже.

Про Julia ничего не знаю, но есть ощущение, что вторая производная популярности питона поменяла знак.
Еще недавно почти в любом проекте последний коммит вчера, или на прошлой неделе. Сейчас чаще год назад. Или пару. Или шесть лет назад. Для совместимости с Python 3 приходится править. И.т.д.
НЛО прилетело и опубликовало эту надпись здесь
Из того, что я вижу — Julia сейчас вытесняет «научный» Python из физики и химии. Связано это действительно с нативной JIT-компиляцией и многопоточностью, которая позволяет людям без сторонних костылей (типа numba, которые не очень стабильны и не очень удобны) писать действительно быстрый код. Многие библиотеки для квантовой оптики, химии, квантовой механики и т.д. сейчас переписаны на Julia и активно поддерживаются. Julia это язык, созданный физиками для физиков. Даже индексация с единицы пришла из близкого физикам Fortran. Почему не C++? Потому что на Julia проще и быстрее прототипировать. В машинном обучении и Deep Learning сейчас Julia практически не используется. Преимущества JIT теряются, так как все «строительные блоки» уже написаны, а уровень готовых библиотек Julia проигрывает значимо. Сравните тот же Flux с Tensorflow или PyTorch и все сразу станет ясно. Нет никаких аргументов в пользу перехода с Python на Julia в промышленном машинном обучении или в исследовательских задачах Deep Learning. Скорее всего Julia так и останется языком научной среды.
Julia — интересный язык с понятным синтаксисом и удобной многопоточностью (привет пайтоновскому GIL). Позле ознакомления с туториалом возник вопрос: что они натворили со строками?

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.
Объясняет Карпински
Объясняет документация Раста

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

Вот тут согласен. Потому как я недавно попробовал реализовать 2 похожих сценария и там и там и результаты меня удивили.
Я даже статью написал по этому поводу.

аналитика примитивного уровня. питон занял нишу там где нужен был интерактивный шел и разросся дальше через библиотеки. точно так же и ценность джавы не в джаве а jvm и фреймворках и всё это даже не за 7-10 лет с нуля делается
Судя по всему, главное тут не столько сам язык, сколько стабильность его сообщества. Наличие «великодушных диктаторов» обычно очень помогает выжить языку.
Добавлю немного от себя. Matlab это коммерческий софт с запредельной стоимостью. Работаю с ним с 1999 года. В Matlab'е меня просто выбешивают две вещи. Первое, за все более менее работающие коды в реальном мире (тулбоксы), нужно так же платить бешеные деньги. Или писать все с нуля, используя базисный функционал (не ахти какой). Один компилятор сколько стоит. Второе, если мне не изменяет память, Matlab реализован на java, что уже по определению не совместимо ни с какими высоко-производительными вычислениями! Замечаю, что от релиза к релизу тормознутность и глючность растут в экспоненциальной прогрессии. Поэтому, как глобальный трэнд, все больше и больше компаний и университетов отказываются от коммерческого Matlabа и переходят на open source. Предполагаю, что Julia и взлетела из-за чрезмерной коммерциализации Matlabа. Также, думаю, нет особо смысла сравнивать проприетарный Matlab и СПО, типо Julia / Python. Сравнивать надо, например, Octave, как СПО версию Matlabа =).
А 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.


Странная статья.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий