Релиз языка программирования Julia 1.3

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

Кстати «умеет то же самое что и С, смотри вот код» - это не ответ. Это наоборот больше аргумент за С, который уже больше распространен. Молодому инженеру, как и ученному, изучать скорее специально прийдется фортран, чем С.

Я так понял там упор на MPI. Хорошо, если упор на MPI и вообще multiprocessing, то все же, в чем преимущество?

Единственное что я слышал - большинство математических операций принимают векторы и матрицы на вход так же, как и примитивы. Звучит как проблема, которая просто решается библиотекой

Вроде же был ответ: матричная арифметика и слайсы из коробки. Плюс для простых случаев более компактное I/O. Наличие модулей, отсутствие необходимости использования багогенного препроцессора. parfor из коробки и давно (на С++17 там можно что-то изобразить, но это будет более многословно). Библиотеки на С++ зачастую обильно смазаны шаблонами, а если еще всякие новомодные 17+ трейты и TMP, то это круто просаживает скорость компиляции.

Молодому инженеру, как и ученному, изучать скорее специально прийдется фортран, чем С.

Ага, я это делал. Поверь, время потратил не зря. Молодые инженеры и учёные пишут ужасный код, даже на фортране. К си их близко подпускать нельзя, т.к. будет в 5 раз длиннее портянок и в 10 раз больше багов.

в чем преимущество?

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

Короче всякие нефундаментальные удобности, которым легко противопоставить 100500 других удобностей С/C++.

у ЯП для математических вычислений (на секундочку, "FORmula TRANSlator) не так много требований, и на ЯП общего назначения его не натягивают, а вот С++ - наоборот, ЯП околосистемного назначения, стремящийся заменить в т.ч. и Фортран. Так что некоторые киллер-фичи С++ для программ на фортране могут быть как собаке пятая нога. А с образовательной т.з. С++ на лабах по всяким матметодам неподходит по понятным причинам. Везде либо матлаб, либо R либо еще что-то специфическое, но не С++. С++ нужен только программистам и только в небольшом множестве областей.

у ЯП для математических вычислений

Отлично, не будем о С++. Я вот в R, тоже похожем ЯП (только немного для других вычислений) могу качнуть в любой момент датасет или библиотеку через встроеный пакетный менеджер из центрального репозитория.

Что с этим у Fortran?

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

parfor из коробки и давно (на С++17 там можно что-то изобразить, но это будет более многословно)

openmp лучшее что есть в многопоточности на текущий момент, какой убогий parfor, о чём ты?

Вроде openmp и в fortran поддерживается…

#pragma omp parallel for
for (int i = 0; i < 10; ++i) {
    // do work
}

очень многословно, прям вообще…

О боже, мы синус по элементам матрицы можем, во прогресс!

Так он это давно может, как и поддержку распараллеливания из коробки (как обёртка над mpi правда).

Чего все так текут по пакетным менеджерам? Вот сидишь ты, например, в изолированной сети и что? Много накачаешь?

Они похоже там варятся в своем и не оч поглядывают направо или налево.

Не похоже, а так и есть: сейчас основной упор делается на фичи распараллеливания и взаимодействия с другими (C, C++ то есть) языками. И основные изменения крайних двух стандартов в основном этого и касаются.

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

А теперь, в таком простом случае, берём

do concurrent (i = 1:n)
   ! do work
end do

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

О боже, мы синус по элементам матрицы можем, во прогресс!!!

btw, многие подобные операции уже векторизованы

Чего все так текут по пакетным менеджерам? Вот сидишь ты, например, в изолированной сети и что? Много накачаешь?

Пишу допустим на фортране. Хочу hash map. Или что посложнее. Ручками писать? Ждать когда то что какой-то дед выложил на помойку вроде Sourceforge (как я понял, пристанище разного антиквариата вроде либ для фортрана) опакетят в Дебиан? Бежать самому оппкечивать? Копипастиить тот сорц в свое дерево?

могу качнуть в любой момент датасет Они похоже там варятся в своем

Ну вот, а началось все с того, что вы (некоторые) набросились на довольно случайный кусок кода на фортране, стали критиковать, что в нем ничего особенного нет. А теперь речь про «качнуть пакет» завели. С этим у фортрана не может быть хорошо по определению, и на это он и не претендует. Я так понимаю, что этот R интерпретируемый, что позволяет REPL, графики, IDE, пыщь-пыщь скачал опенсорс пакетик. Фортран не про это. Он из мира waterfall, Cray, проприетарных компиляторов и библиотек. Но справедливости ради, сейчас нет ни одного компилируемого ЯП, который шел бы со средой типа Rstudio. В той же Julia есть блокноты и atom’ный говноредактор с графиками. А чтобы скомпилировать в standalone, какой-то нереальный траходром. На каждый импорт пакета он его качает и собирает, как будто это гента какая-то.

Ну допустим пишешь. Допустим в изолированной сети. Стой, у нас ж все HPC сервера доступ свободный в инет имеют?

Копипастиить тот сорц в свое дерево?

А то! Можно подумать, что пакетный менеджер тебе не с помойки притащит.

Ждать когда то что какой-то дед выложил на помойку

Тебе существующих реализаций мало?

Речь о автоматизации этого. Даже о автоматизации вендоринга если надо. Чтобы помойка была одна и с поисковиком

Ещё раз, там где его используют часто нет прямого доступа наружу и для сборки «на месте» пакетный менеджер будет бесполезен.

На «помойке» пакет окажется только если автор того пожелает.

И самое важное: не факт, что пакет будет собираться в используемой тобой реализации языка.

я смотрю, с чем тока julia не сравнивают в этом треде... Rust, C++, R, Octave, pypy, Fortran... Что самое забавное, не то, чтобы кто то не прав:

• Rust, C++, Fortran, потому что julia, если расставлять типы, генерит высокопроизводительный код. Плюс в julia из коробки фичи для многонитевости и распределенности... Ориентированность на высокие вычисления как никак... Суперкомпьютеры, кластеры, все дела...
• Octave и R, потому что из коробки векторно-матричный синтаксис и прочий синтаксический сахар. Плюс язык позиционируется в т.ч. «для ученых». На R у меня мало опыта, но на octavе разработка на julia совсем не похажа. По фичастости в octave, на самом деле, много чего есть, но разрабатывать на нем больно, особенно это касается отладки. У julia таких проблем нет - она ближе к python.
• Python и Fortran, навероно, потому что без типов juila по использованию больше всего походит на python. Всем: repl, отладка, динамическая типизация.... Но когда в python все начинает тормозить, вы переписываете код на более шустрый язык(Fortran?) и появляется две версии кода, котрые надо поддерживать. A julia разрывает этот порочный круг: на ней вы просто расставляете типы, обычно, в критичных местах(массивы, циклы) и код начинает работать намного быстрее. В этом смысле julia похожа на python + numba + jit + аннотация типов. Хотя, в итоге, решение на julia все равно выглядит намного чище, естественней, чем этот комбайн... просто, видимо, python изначально для этого не предназначен.

Еще аргумент в пользу Python - это то, что современные языки паразитируют на экосистеме существующих. Иначе они не могут быть успешными. И для julia это, в первую очередь, экосистема python. Вот PyCall:

using PyCall

@pyimport math
math.sin(math.pi / 4)

Очень органично. Если читаете, что это не работает - не правда! Я использую - работает отлично в т.ч. с питоновыми либами, которые используют C или Fortran, вроде pandas, numpy, scipy. Не работает у тех, кто использует нестандартные python-дистрибутивы, вроде anaconda или у кого путаница с версиями python... я ставлю все через pip и все работает прекрасно.

Я бы еще хотел чтобы они умели легко и просто делать полную AOT прекомпиляцию.

PackageCompiler - не оно? Не быстро, но, вроде и не очень сложно.

Батареек нема

см выше про PyCall

Она тормоз. Невозможный тормоз. Никакая интерактивная сессия в ней невозможна.

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

Про производительность, можете сами убедиться, что julia генерит отличный llvm-код, по крайней мере там, где компилятор может вывести типы:

@code_llvm your_code еще можно @code_typed your_code чтобы посмотреть, какие оно типы выводит

и не забывайте, что когда вы делаете замеры с помощью @time your_code что его нужно повторят дважды т.к. компиляция метода для конкретного набора типов аргументов происходит пре его первом вызове и включается во время вызова.

По бенчмаркам в среднем быстродейстиве julia(без полной аннотации типов) где то на уровне Java. Хотя, если задаться целью, уверен, что можно быстрей C написать, потому что julia более высокого уровня и там больше инфорамции доступно в т.ч. для ручной оптимизации! а на низком - там тот же самый llvm

потому что julia, если расставлять типы, генерит высокопроизводительный код

Расстановка типов в джулии никак не влияет на производительность. Это по словам самих разработчиков. Компилятор отлично выводит типы без помощи пользователя (за исключением нескольких паталогических случаев). Аннотация типов нужна для множественной диспетчеризации и для проверки типов.

Расстановка типов в джулии никак не влияет на производительность. Это по словам самих разработчиков. Компилятор отлично выводит типы без помощи пользователя (за исключением нескольких паталогических случаев). Аннотация типов нужна для множественной диспетчеризации и для проверки типов.

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

Поскольку julia - строго типизированнйы, то, что вы написали, наверно, справедливо для рантайма. Но самый главный способ оптимизации - это протаскивать информацию из рантайма на уровень компиляции. И вы, как разработчик, как правило обладаете значительно большей информацией, чем способен вывести компилятор.

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

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

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

Если ссылочка под рукой, я бы с удовольствием почитал

Это обсуждалось неоднократно на https://discourse.julialang.org Можешь сам вопрос задать.

особенно перечень паталогических случаев…

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

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

Насчёт отладки: видел, что в документации что-то появилось о ней. До этого, то ли авторы julia или ещё кто-то из причастных к разработке, искренне делали вид, что не понимали, зачем нужно взаимодействие с дебаггером. То есть это взаимодействие наконец-то добавили?

Нормальные люди давно заменили в числодробилках Фортран связкой плюсы-питон.

Это зависит от задачи и дизайна.

А кому он нужен? Хайп утихает. А вместе с ним и язык

Уже давно заменили плюсами практически везде.

А с образовательной т.з. С++ на лабах по всяким матметодам неподходит по понятным причинам.

И же что это за причины? А то дцать лет ведем именно такие лабы именно на плюсах именно для НРС и не знаем почему так низя…

И чуть более развернуто.

матричная арифметика и слайсы из коробки.

apt-get install eigen - и вот у нас матричная арифметика в С++. Или вообще берем что то вроде вот этого

https://keldysh.ru/e-biblio/krasnov/

и пишем разностную схему на С++ в одну строчку. Так что если задача быстро написать компактный код с приемлемой производительностью, то фортран сливает плюсам в чистую.

Если задача сделать код с пиковой производительностью для стенсил-вычислений, то в любом случае придется много думать и много кодить (гуглите LRnLA). В этом случае фортран вообще не при делах, это однозначно С++/CUDA и скорее всего питон для кодогенерации.

За 20+ лет работы в этой области лично я сталкивался с двумя боевыми кодами на фортране. Первый, по газодинамике горения, написанный еще в 90е, я тупо конвертнул в С, выкинул из него половину связанную с парсингом конфиг-файла и работал с комфортом. Второй, по сейсмической миграции, мы патчили на плюсах.

Никто из моих знакомых активно работающих коллег моложе 50ти не юзает фортран. На последней RSCD я не помню ни одного доклада про код на фортране, хотя возможно была парочка - можно посмотреть программу http://russianscdays.org/

Хотя кое кто из старших коллег иногда говорит что фортран ого-го-го а плюсы ваши фигня. И ЕМНИП был какой то метеорологический код на фортране…

Используй Jupyter lab с IJulia

Фортран какой-то обсуждают в 21 веке. Лор такой лор

По моим наблюдениям да и согласно индексу TIOBE, происходит ровно обратное. А ЛОР - не показатель. Здесь свои законы ;)

Да я шуткой =)

Я про суперкомпьютеры не скажу. Я реальные задачи дальше выч. сервера о 40 ядрах не считал, причём параллелизацию делал по-старинке через OpenMP, хотя есть механизм coarrays. Для меня Фортран остаётся привычным, высоконадёжным и высокопроизводительным инструментом, имеющим богатый встроенный инструментарий и большое число библиотек. Я знаю ещё пару человек моложе 50-ти, одному 30, кажется, другому 42 на днях стукнуло, которые пишут только на Фортране, а графики делают PLPlot'ом (по крайней мере один из них). Но для повседневного программирования и для студентов Фортран не годится, как и плюсы: слишком длинная семантика кода, большое число сложно устанавливаемых библиотек, много сложных конструкций и специфики. Гораздо проще всё сделать на Питоне, Скилабе/Матлабе/Октаве или той же Юлии. А уже если действительно не хватает производительности, что бывает весьма редко, тогда переписываем на Фортране.

Я последнее время всё на многомерные массивы в D поглядываю. Сам язык существенно удобнее как Си++, так и Фортрана. Пока времени нет, но собираюсь осваивать весною, когда пар будет поменьше.

знаю ещё пару человек моложе 80-ти, одному 60, кажется, другому 72 на днях стукнуло, которые пишут только на Фортране

Держитесь там, всего вам доброго, хорошего настроения и здоровья!

Это следующий R. C++ из другой оперы

Нет, маня, это потуги на R с эффективностью близкой к C++. Бездарные конечно как всегда у адептов скриптухи. Вопрос анона совершенно корректен: зачем вся эта дристня когда есть кресты и для совсем старых чмырей еще и фортран.

Удивляет суждения многих типа - «Алгол 60 устарел».
Разработчик ни когда не выскажет такое и подобное суждение.
Почему?
Разработчики обычно не «пальцы веером гнут», а стараются понять и использовать все хорошее в своих проектах.

Да и нынешние языки программирования не намного лучше «Алгол 60» или иных языков программирования 60-х.
Ведь лет пятьдесят все «топчатся на месте» и как зомби используют
для разработки компиляторов грамматики.
Не хочу сказать, что грамматики это плохо, но «пластинка заела» и пятьдесят лет говорит: «Грамматика, грамматика, …».

Владимир

Я реальные задачи дальше выч. сервера о 40 ядрах не считал, причём параллелизацию делал по-старинке через OpenMP

Как правило этого достаточно.

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

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

Но для повседневного программирования и для студентов Фортран не годится, как и плюсы

У нас студенты вполне спокойно пишут на плюсах после полугодового курса молодого бойца.

Гораздо проще всё сделать на Питоне, Скилабе/Матлабе/Октаве или той же Юлии. А уже если действительно не хватает производительности, что бывает весьма редко, тогда переписываем на Фортране.

Гораздо проще сразу писать на связке плюсов и питона например;-)

Я последнее время всё на многомерные массивы в D поглядываю.

Мнэ… плюсы конечно ужасный ЯП, но под него самые лучшие компиляторы, библиотеки он везде есть и его все понимают. Когда D станет менйстримом (если станет) - наверное я подумаю что бы на него перейти. А пока что у меня свои многомерные массивы и пр. на плюсах, лучше сделать наверное невозможно;-)

Ведь лет пятьдесят все «топчатся на месте» и как зомби используют для разработки компиляторов грамматики.

Я понятия не имею что такое эти Ваши грамматики, но С++-11 таки гораздо удобнее в работе чем С++-98.

У нас студенты вполне спокойно пишут на плюсах после полугодового курса молодого бойца.

Наверное, у вас очень талантливые студенты, внимательные и времени у вас/них много. Обычно даже на профильном факультете учить плюсам приходится 2-3 года, чтобы они могли писать эффективно и при этом не отстрелили себе всё, что можно. А физиков или, тем более, биологов научить плюсам совсем не удаётся в большинстве случаев.

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

Наверное, у вас очень талантливые студенты…

ФУПМ МФТИ, когда они приходят к нам то знают немного С. Просто в моделировании повседневщины вся мощщщь плюсов ненужна - хватает простых приемов. Этому и учим, а дальше человек сам прогрессирует ежели хочет.

Но я например заканчивал каф. низких температур физфака МГУ, нас на первых двух курсах как то поучили немного плюсам и все. Дальше сам…

ФУПМ МФТИ

Зависит от того, насколько ещё эти навыки востребованы в дальнейшем процессе обучения. На ФАЛТ МФТИ похоже сейчас 1 курс - c++, потом, в лучшем случае, навыки программирования могут понадобиться курсе на 4. Дальше зависит от собственных желаний это изучать, в том числе чтобы устроиться после окончания на работу.

Но бывают и отдельные студенты, которые на 4 курсе не знают, что такое цикл и для чего он нужен.

каф. низких температур физфака МГУ, нас на первых двух курсах как то поучили немного плюсам

Во, целых 2 года. У меня лет 20 назад был год паскаля + полгода Си++ (которого скорее на было, а от «+» только cout, до указателей, кажется, даже не дошли - они были на паскале).

CFD не числодробилка. и плюсы в процедурном виде ничем не лучше.

а в ООП виде оно как правило сильно накладывает ограничения.

у нас на ФАЛТ был С, С++, Ассемблер бегло) в рамках одного спецкурса вскользь упоминался фортран77

CFD числодробилка ничем не хуже других числодробилок. ООП одна из парадигм (не обязательных к использованию даже если ты пишешь на плюсах) и никаких ограничений по сравнением с фортраном/паскалем «оно» не накладывает.

Во, целых 2 года.

ЕМНИП пара-две в неделю. На втором курсе учились писать форточки под винду. Второй поток учили паскалю, им не повезло…

Реально кодить что то серьезное я начал курсе на четвертом, использовал в основном книжку Дж.Лукаса «C++ под рукой».

ну тем не менее все что я видел на плюсах производительного и не жрущего память( Overture ) смотрелось как фортран перенесенный на C++ ) SU2 жрет память как не в себя.

ООП одна из парадигм (не обязательных к использованию даже если ты пишешь на плюсах) и никаких ограничений по сравнением с фортраном/паскалем «оно» не накладывает.

Дело не в Фортране или Паскале. ООП противопоказано при массовом параллелизме в силу своих фундаментальных принципов, не важно реализовано оно на Паскале, Питоне или Си++. Массовый параллелизм должен работать с чистыми функциями и неизменяемыми данными. В случае ООП всё инкапсулировано, методы имеют доступ к полям, наследники могут не знать, что и как в предках.

В случае Си++ с его дружественными функциями и специфическими const, которые по умолчанию позволяют иметь неизменяемые указатели вместо данных, с его множественным наследованием, а также в силу отсутствия нормальных модулей и вложенных функций, в нелокальные переменные которых можно было бы вынести результаты, если алгоритм предполагает складывать их из разных потоков в общее хранилище типа большого массива, так вот в случае Си++ реализовать нормально неизменяемость становится нетривиально как только вы хоть чуть-чуть затронули ООП. Это всё, кстати, причина, почему там не могут сделать нормальный сборщик мусора: слишком сложно и все реализации ненадёжны.

ФУПМ МФТИ, когда они приходят к нам то знают немного С.

Ну вам очень везёт. Столичные вузы собирают все сливки со страны. Из наших 110 человек как-то программировать на уровне посчитать сумму чисел, введённых с клавиатуры, пока не введён 0, могут от силы 5-7 человек, а у 2/3 программирования на информатике вообще не было, только рисовали в Пэинте.

В 90-ые было получше. Я помню, что сносно писал на Паскале после школы, даже в качестве выпускного проекта забахал трейсер пучка лучей, отражавшихся от произвольной поверхности 4-го порядка. При том, что олимпиады по программирования никогда не выигрывал даже близко.

Ассемблер был, кажется, на втором курсе, настолько бегло, что ничё не помню, но он был аж на unix системе, на которую заходили удалённо. Mathematica тогда же чуть была.

Всё равно гораздо больше занятий. А насчёт не повезло - нет ничего сложного, чтобы быстро освоить C++ для своих целей, если там не что-то узко-специализированное.

А я не упоминал HPC. Линал там всякий, статистика, ТАУ.

И чем же для всего этого плохи плюсы?!