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

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

Рановато питон хоронят. Ещё перл не весь вымер.
Да даже Python версии 2 ещё жив :(
Не являюсь фанатом Питона. Даже по сути не знаком с ним толком.
Но по результату прочтения статьи я скорее в сторону Питона буду смотреть при необходимости, чем в сторону этого нового языка.
Интересно, что за клуб Петафлота?

Решил почитать документацию про этот язык...


Массивы индексируются с 1. Ну спасибо теперь. Удачного перехода с других языков?


Конкатенация строк через "*"? Хм..


Интерполяция (подстановка переменных внутрь строки) — в Python я не очень приветствовал f-строки, но тут вообще кивок в сторону Perl..


Похоже что они снова наступили на грабли всех новых языков когда в общий namespace включено куча функций из стандартной библиотеки: pwd, cd, mkdir, download, mktempdir — вот прямо так всегда нужны в каждом модуле? Это только я наугад выбрал. В Python они все в модуле os и если нужны — импортируй сам. Явное лучше неявного. Это ж сколько надо теперь запомнить ключевых слов и стандартных функций чтобы не переопределить ненароком? Назвал переменную mark? Напрасно — это функция такая есть.
Возможно я тут неправ и namespace настраиваются, но это просто беглый взгляд.


Зато области видимости переменных, вроде, сделали по-нормальному — переменная, которую определили внутри цикла (блока) снаружи не видна.


Первый раз посмотрел на этот язык и написал коммент только на то что сразу бросилось в глаза — кто может опровергнуть — пожалуйста.

НЛО прилетело и опубликовало эту надпись здесь
Это сделано для нормальных людей. Как человек считает яблоки: первое, второе, третье…. Вряд ли кто-то начинает с нуля. Что такое нулевое яблоко? Шиза. В Фортране кстати тоже индексирование начинается с нуля.

Здесь лучше вспомнить аналогию с возрастом: первый год жизни — это когда 0 лет.

Год продолжается, яблоки нет. Индексированная переменная — дискретная величина: первая, вторая, и т.д. Или индекс может быть real? (от такого ужаса даже в Фортране отказались полностью). И не надо рассказывать про смещение как в С, оно интуитивно понятно только программистам, да и то далеко не всем. Для физиков-статистиков-биологов-бухгалтеров и т.п. индексация с 1 интуитивно понятнее (они и слов-то таких как смещение не слышали).

Ладно, индексы — это тоже древний холивар. Я не хотел портить вам чувство прекрасного, но придется снова сходить с козырей.
Как вы думаете, что происходит в этой строке кода?


a = [1 -2; 4 -5]

А это, дорогие друзья, объявление двумерного массива! Это не один-минус-два, а, внезапно, пробел, разделяющий элементы. Помнится, многим сильно мешали отступы в Питоне? А вот прочитайте-ка пробелы в середине текста. Я не уверен, но, возможно, если после минуса поставить пробел, то это уже будет арифметическое выражение. Интуитивно понятнее? (простите за сарказм, ничего личного)

Ну это питон открыл ящик пандоры с табами. Чтобы не сломать мозг, в Julia нужно рассматривать ; как перевод строки, т.е. матрица:


| 1  -2 |
| 4  -5 |

Ну вы еще Бейсик вспомните. Простите, но вы документацию видели по этой Julia?
Человек, не знакомый с другими языками программирования ее не поймет. А знакомый — будет все время испытывать неудобства.
Синтаксис языка довольно богатый — это, скорее, плюс, но новичкам тут не место.


Индексация с нуля для программиста на, скажем, Си — интуитивно понятнее, поскольку индекс массива — это смещение относительно указателя на первый элемент. Ну а оттуда и все остальные переняли это.

С индексами особо не важно, откуда они начинаются по-умолчанию. Обычно нужно либо проитерироваться по массиву, либо взять первый/последний элемент — в этих случаях явные индексы в коде не фигурируют вообще. Если же существенно используется обращение по индексам, то часто удобнее обращаться к массиву не с 0 или 1, а совсем по другим диапазонам вроде -n/2...n/2 или даже -1 метр… 1 метр. И если первое (итерация) достаточно удобно записывается и в питоне, и в джулии, то вот во втором (произвольные индексы) джулия явно побеждает.
Человек,… знакомый [с другими языками программирования] — будет все время испытывать неудобства.

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

Спасибо за фидбэк. Очень хочется внятного сравнения, а не той воды что в статье. Кстати, поставил ей плюс, но только за то что привлекла интерес к теме, а не за содержание.
А что с библиотеками? Тут приводили уже пример что для Питона понаписали на каждую мелочь уже что-нибудь типа работы с датами (pytz, dateutil, delorian) или с сервисами типа AWS (boto3).
У Питона есть асинхронность — а есть ли что-то похожее в Julia? Или только через биндинги к C? Multithreading сравнивать смысла нет (в Питоне все понятно с GIL), интересует именно неблокирующее ожидание ввода-вывода.
Что там с тестированием? Есть ли какие-нибудь большие проекты, которые начинаются с Julia?

А что с библиотеками? Тут приводили уже пример что для Питона понаписали на каждую мелочь уже что-нибудь типа работы с датами (pytz, dateutil, delorian) или с сервисами типа AWS (boto3).

Безусловно, библиотек написанных на джулии намного меньше, чем на питоне. Иногда пользуюсь питоновскими, в том числе своими модулями написанными ранее — работает на удивление прозрачно через PyCall.jl. Особо отмечу matplotlib: постоянно использую, вообще никаких проблем.
Если же библиотека на условных сях или фортране имеет C-api (без питоновской обёртки), то оборачивать тоже удобно через ccall. При этом оверхеда нет — т.е. можно эффективно передавать джулиевскую функцию как callback в такие библиотеки.
У Питона есть асинхронность — а есть ли что-то похожее в Julia? Или только через биндинги к C?

Конечно есть, async/@sync в стандартной библиотеке. Я лично всего несколько раз пользовался этим, проблем не увидел.
Что там с тестированием?

Я только стандартным модулем Test пользуюсь, есть также всякие дополнительные пакеты — но особо не могу сказать про них. Вообще подход к тестированию весьма правильно выглядит, и они даже прогоняют тесты зарегистрированных пакетов при обновлениях языка.
Есть ли какие-нибудь большие проекты, которые начинаются с Julia?

Про это совсем не знаю, не смотрел.
И про вакансии именно по джулии понятия не имею :) У нас на чём хочешь, на том и пиши.
У нормального человека, нормальное состояние это 0 яблок, а не одно. Поэтому даже для людей правильное считать с нуля.
Нет. Ноль — это не натуральное число и как раз логично нумерацию элементов массива делать в натуральных числах.
Понятие «натурального числа» условно, в западных странах, например, 0 обычно включают в натуральные, да и у нас тоже по-разному бывает. Например, на кафедре теории чисел у нас пропагандировали натуральные числа с нуля, а на кафедре математического анализа — с единицы.
и какая аргументация теории чисел?
Натуральный ряд — ряд индукции. Для индукции необходима 1 и не нужен 0.
> Натуральный ряд — ряд индукции

Декларации такие декларации…

> Для индукции необходима 1 и не нужен 0

Для индукции номер начального элемента совершенно неважен, можно хоть с тысячного нумеровать.

Множество натуральных чисел определяется не как «ну вот чёта там естественное», а акиоматикой Пеано. Выбор начального элемента в нём — дело десятое.

Кстати, слово «ряд» в математике означает совсем другое…
Множество натуральных чисел определяется не как «ну вот чёта там естественное», а акиоматикой Пеано. Выбор начального элемента в нём — дело десятое.
Вроде не десятое… Так у Пеано ноль не является натуральным числом.
Место нуля

Существуют два подхода к определению натуральных чисел:

числа, возникающие при подсчёте (нумерации) предметов: первый, второй, третий, четвёртый, пятый…;
числа, возникающие при обозначении количества предметов: 0 предметов, 1 предмет, 2 предмета, 3 предмета, 4 предмета, 5 предметов…

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

Множество всех натуральных чисел принято обозначать символом N {\displaystyle \mathbb {N} } \mathbb {N}. Международные стандарты ISO 31-11 (1992 год) и ISO 80000-2 (2009 год) устанавливают следующие обозначения[4]:

N {\displaystyle \mathbb {N} } \mathbb {N} — натуральные числа, включая ноль: { 0, 1, 2, 3, 4 … } {\displaystyle \{0,1,2,3,4\dots \}} {\displaystyle \{0,1,2,3,4\dots \}}.
N ∗ {\displaystyle \mathbb {N^{*}} } {\displaystyle \mathbb {N^{*}} } — натуральные числа без нуля: { 1, 2, 3, 4 … } {\displaystyle \{1,2,3,4\dots \}} {\displaystyle \{1,2,3,4\dots \}}.

В русских источниках этот стандарт пока не соблюдается — в них символ N {\displaystyle \mathbb {N} } \mathbb {N} обозначает натуральные числа без нуля, а расширенный натуральный ряд обозначается N 0, Z +, Z ⩾ 0 {\displaystyle \mathbb {N} _{0},\mathbb {Z} _{+},\mathbb {Z} _{\geqslant 0}} {\displaystyle \mathbb {N} _{0},\mathbb {Z} _{+},\mathbb {Z} _{\geqslant 0}} и т. д.[3]


Для сравнения рекомендую посмотреть в англоязычную версию.

До кучи рекомендую следующий комментарий со страницы обсуждения:

Практически во всей иностранной литературе и на Википедии аксиомы Пеано начинаются с «0 есть натуральное число». Действительно в первоисточнике написано «1 есть натуральное число». Однако, в 1897 году Пеано вносит изменения, и меняет 1 на 0. Это написано в 'Formulaire de mathematiques', Tome II — №2. стр 81. Это ссылка на электронный вариант на нужной странице:

archive.org/stream/formulairedemat02peangoog#page/n84/mode/2up (фр).

Пояснения к этим изменениям даются в 'Rivista di matematica', Volume6-7, 1899, стр 76. Также ссылка на электронный вариант на нужной странице:

archive.org/stream/rivistadimatema01peangoog#page/n69/mode/2up (итал).
Сильный комментарий.
Скасиоматиа Пеано крутится вокруг индукции. По сути повторяет то что я сказал.
1 если в индукции смещение назвать «1» то это чисто должно быть в рассматриваем множестве.
2 из опеделения индукци
3 ряд начинается с единицы — потому что она есть единственное число необходимое для индукции. Поэтому ее и делают началом ряда
4 и 5 — для однозначности

И я зная что такое ряд. Натуральные числа — есть ряд по индукции
> Скасиоматиа Пеано крутится вокруг индукции

Аксиоматика Пеано не крутится вокруг индукции, в ней все аксиомы необходимы, как, впрочем, это всегда и бывает в системе логически независимых суждений. Она описывает лишь отношения между понятиями «начальный элемент» и «следующий элемент».

До кучи рекомендую следующий комментарий со страницы обсуждения в Википедии:

Практически во всей иностранной литературе и на Википедии аксиомы Пеано начинаются с «0 есть натуральное число». Действительно в первоисточнике написано «1 есть натуральное число». Однако, в 1897 году Пеано вносит изменения, и меняет 1 на 0. Это написано в 'Formulaire de mathematiques', Tome II — №2. стр 81. Это ссылка на электронный вариант на нужной странице:

archive.org/stream/formulairedemat02peangoog#page/n84/mode/2up (фр).

Пояснения к этим изменениям даются в 'Rivista di matematica', Volume6-7, 1899, стр 76. Также ссылка на электронный вариант на нужной странице:

archive.org/stream/rivistadimatema01peangoog#page/n69/mode/2up (итал).


> И я зная что такое ряд

Вынужден разочаровать. Натуральные числа, как и вообще любые счётные множества, словом «ряд» не называют. Термин этот означает совсем другое.

ru.wikipedia.org/wiki/%D0%A0%D1%8F%D0%B4_(%D0%BC%D0%B0%D1%82%D0%B5%D0%BC%D0%B0%D1%82%D0%B8%D0%BA%D0%B0)
> Она описывает лишь отношения между понятиями «начальный элемент» и «следующий элемент».

звучит как простенькое описание индукции
> звучит как простенькое описание индукции

Нет, это не так.
У нормального человека, нормальное состояние это 0 яблок, а не одно. Поэтому даже для людей правильное считать с нуля.

Вы себя вспомните, когда в первый раз столкнулись с индексацией с нуля. Вас это никак не озадачило, не возникало попервой трудностей и восклицаний «нахуа»?
А если софистику развести и подемагогить, то нуля яблок не бывает. Ноль, это ничего, то есть не яблоки. Язык писан для непрограммистов, для их научных и прикладных задач, а у нормальных людей, как уже выше писали, индексация с «1». Хотя, такая «эргономичная» фишка в программировании, всё таки, кажется излишней, и вызовет скорее путаницу и ошибки.
А так, симпатичный и относительно шустрый язык (многопоточность из коробки, не надо modin к панде прикручивать, а до этого долго искать и выяснять, что это, зачем, и как), кабы не юлина прожорливость и бедность на библиотеки

Увидел статью о новом языке программирования — с интересом пошел смотреть. Прокручиваю. Статья закончилась, пошли комментарии, кода не обнаружено. Стоит ли читать?

Стоит ли читать?

если только вам нравятся пустословные рекламные брошюрки от девочек дизайнерш с набором слоганов. Лучше посмотрите юлину ветку — habr.com/ru/hub/julia
или вот тему гляньте — habr.com/ru/post/454998

по-моему, язык очень симпатичный и заслуживает хотя бы ознакомительного внимания)
НЛО прилетело и опубликовало эту надпись здесь

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

Все — на C++? Вы серьезно? Вы думаете не-программист (физик, химик, биолог) его осилит? Julia проста как питон (никакого компилятора) и при этом быстро почти как как в C. Для вычислений самое то что надо. Для всего остального она точно не подходит. Этот язык занимает нишу R, Matlab, и т.п. Отсюда и все эти странности с точки зрения программиста.
Если еще вспомнить, что большинство питоновских ML библиотек на самом деле просто обвязки над весьма оптимизированным С-шным кодом, то вообще непонятно в чем весь пафос Julia
НЛО прилетело и опубликовало эту надпись здесь
Многофункциональность нужна далеко не всем. А пиарят его потому, что сейчас все студенты физики/математики/химики/биологи и т.п. должны обязательно учить «программирование». И что-же они учат? Не C/С++ или даже Fortran, а R и Python. Потом, когда нужно что-то посчитать (и нарисовать табличку и график), написанная абстрактным PhD студентом программка на питоне считает часами или даже днями при этом сжирая всю память и вводя модный Макбук в ступор. Вот для такой аудитории этот язык, не для общей computer science или абстрактного многофункционального «программирования.»

А вы думаете что нельзя на Julia написать код, который сожрет всю память? Плохой пример у вас.
На любом языке надо писать с оглядкой на производительность, а это получается уже после солидного опыта, а там уже не так важно какой язык.
Я часто вижу код, который пишут аналитики. У них математическое образование и они каждый день оперируют очень сложной бизнес-логикой. Но от их кода (Python или SQL или VBA) у меня глаза хотят вытечь.

Физики-химики-биологи обычно пишут совершенно невероятный код. Чаще всего вообще без оглядки на производительность, необходимость дальнейшей поддержки, реюз и т.п. Но порог наступления катастрофы разный. На Python, она наступает раньше. То есть кривой код, который достаточно быстро и безболезненно работает на фортране превращается в полную катастрофу на питоне. На Julia такой же примерно код с большей вероятностью как-то заработает. И да, сломать можно любой язык. Добро пожаловать в новый дивный мир, в котором почти все программируют. В этом мире всех учат «кодить,» но не учат «программировать» (а это прежде всего software engineering).

step back… А вы пишете именно на Julia? И реально она понятнее новичкам чем Python?

Нет, я на ней сам не пишу, но иногда ее читаю. (Сам пишу на фортране, си, эр и матлабе). И по моему опыту порог входа у джулии примерно как у питона, матлаба или эр. Правда в реальности что-то пишут на джулии (пока?) довольно редко и обычно те кто уже хоть немного знаком с питоном.
НЛО прилетело и опубликовало эту надпись здесь

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

НЛО прилетело и опубликовало эту надпись здесь
Поясните, каким боком сюда котлин? Насколько я пониманию, его основная ниша — андроид, и на неё не особо претендуют что питон, что джулия.
В обратную сторону — посмотрел сейчас на гитхабе что пишут на котлине. Как я и думал, в плане научных вычислений и ds практически ничего нет, буквально несколько пакетов с самой базовой статистикой и т.п. В отличие от джулии в нём нет и прозрачного интеропа с питоном (как я понял) — то есть нельзя просто использовать питоновские библиотеки когда нужно.
Ну и одно из главных преимуществ джулии — почти вся стандартная библиотека написана на самом языке, все пользовательские пакеты тоже. Это значит, что не нужно знать несколько языков для понимания или правки имеющихся пакетов, для написания производительного когда; сравните с питон + си, котлин + джава.
НЛО прилетело и опубликовало эту надпись здесь
А Джулия наоборот узкоспециализированный язык

Это-то с чего вдруг? В языке ничего сильно ограничивающего область применения не вижу, кроме разве что сборки мусора.
Действительно сильные библиотеки на джулии сегодня и правда есть почти только для разного рода вычислений — просто потому, что в этой сфере наиболее очевидны преимущества языка, и не особо важны (временные) недостатки. Основной недостаток — медленный старт, и над этим плотно работают с разных сторон, от версии к версии видны стабильные улучшения.

Про котлин в ключе использования для вычислений первый раз слышу, но всё равно как-то не особо понятно зачем на него с питона переходить (если не работаешь в jetbrains). Сразу теряешь все свои наработки и привычные библиотеки, а принципиальных преимуществ не видно. Ну и субъективно я jvm как-то не люблю :)
При переходе же на джулию получаешь компиляцию в машинный код, несравнимо более богатые возможности объединять независимые библиотеки, удобный автодифф, хорошую интеграцию с GPU вычислениями, и многое другое. Это всё получилось не в последнюю очередь благодаря именно дизайну языка. Вдобавок можно продолжать полноценно использовать свои имеющиеся питоновские модули. Ещё есть прозрачный, насколько это возможно, интероп с Си без оверхеда.
НЛО прилетело и опубликовало эту надпись здесь
… но мне не нравится идея изучать целый язык со всем его окружением только ради вычислений. Возможности языка в других направлениях (приложения, сайты...) для меня под большим вопрос, ...

Не очень понимаю, в чём собственно «большой вопрос»? Помимо вычислений, например, удобно пишутся скрипты которые переросли баш, околосистемные демоны, всякие клиенты к api, и т.д. Про гуи-приложения и сайты я совсем ничего не могу сказать по своему опыту, но есть популярные пакеты по генерации статических сайтов, созданию «традиционных» сайтов, и организации rest api.
Просто в этих областях преимущества джулии как языка либо пока не раскрыты библиотеками, либо просто не настолько важны как в вычислениях — но особых недостатков лично я не увидел (кроме скорости старта — см. предыдущее сообщение).

С Котлиным я вижу ситуацию иначе, за ним стоят сильные компании, для jvm уже есть библиотеки для вычислений (коть и меньше, чем для Питона), поэтому я уверен в его будущем.

Это конечно единичный опыт, но я не знаю лично никого из друзей, знакомых, и коллег, кто бы писал на jvm-языке для научных вычислений, data science и около этого. Даже те пара человек, у кого в компаниях крутится спарк, разрабатывают для него на питоне. А так пишут на чём угодно — python (большой отрыв), c/c++, r, matlab, fortran, julia. Совершенно не понимаю будущего котлина в этой области, по-моему экосистемы в питоне и джулии здесь несравнимы с jvm (а питоновские пакеты, повторюсь, прозрачно использовать нельзя). Вдобавок непонятно как там с разработкой на котлине не зная джава, и как с идиоматичностью работы с джава-библиотеками.

Я читал, что Вы используете Джулию уже несколько лет. Для личных проектов или производственных?

В nature есть известная статья Julia: come for the syntax, stay for the speed — так вот у меня примерно обратная ситуация :)
Давно один коллега советовал посмотреть на джулию, но до версии 1.0 я только мельком поглядывал — они сами писали что часто ломают совместимость. Когда вышла стабильная в этом плане 1.0 (в 2018), то сначала пробовал использовать в отдельных узких задачах — преимущественно из-за скорости, для достижения которой не нужно отказываться от нормального написания кода (в отличие от питона). На этом этапе понравился сам язык, заложенные подходы и решения — и стал использовать для почти всех новых проектов и части мелких вещей типа скриптов. За два года с тех пор появилось множество улучшений в языке и реализации, всё больше библиотек.
Ни в каком другом языке не видел настолько удачной работы независимых пакетов друг с другом — обычно это относится на счёт хорошей реализации multiple dispatch. Работа с зависимостями и библиотеками, включая бинарные, удобно сделана, и поддерживает писать воспроизводимо. Ну и без прозрачного интеропа с питоном я бы не смог так легко перейти: использую и свои старые питоновские модули, и некоторые библиотеки типа чтения редких типов файлов, и matplotlib.
Для личных проектов или производственных?

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

но видео просто бомба
большое спасибо
Всё конечно радужно и прекрасно, но хотелось бы видеть в статье хотя бы пару примеров с кодом.
Разработчики Julia хотели получить такой же быстрый язык, как C — но то, что они создали, стало ещё быстрее[ссылка на статью].

Возможно, я ошибаюсь, но в статье и близко нет речи о том, что Julia быстрее С
Разве под заголовком нет вот этой ссылки: "Автор оригинала: Rhea Moutafis"?

Если статья переводная, то мы всегда оформляем именно как «Перевод» с указанием автора и ссылки на первоисточник.
у нас в России пайтон то еще не все компании используют, а с новым (молодым языком) свою вакансию можно долго искать, за то если такие появятся, то будет некое преимущества…
И вообще, если развивать PyPy, то и никакая Julia не понадобится.
НЛО прилетело и опубликовало эту надпись здесь
«C на стероидах» неплохо описывает многие вычисления в питоне. Но это не положительная черта современного языка :) Работает быстро — тут да: хотя и не всё пока реализовано полноценно в numba и других, но многие вычисления на ней более-менее можно написать. Однако, есть куча проблем с расширяемостью/переиспользованием кода/совместным использованием библиотек — киллер-фича джулии именно в том, что всякие комбинации имеющихся пакетов [которые друг о друге не знают] успешно, быстро, эффективно работают вместе.
НЛО прилетело и опубликовало эту надпись здесь
Да, на хабре часто такая ситуация, что сам пост можно сразу пропускать и переходить к комментариям :)
То, как часто стали хоронить Python (сперва Go-феры, теперь еще джулисты) говорит о том, что язык созрел чтобы считаться стандартом и чтобы на него ровнялись. Значит он будет как Java и PHP. Даже когда (и если) станет в чем-то слабее аналогов, очень долго продержится на плаву.
Да, питон останется надолго — вон на перле, R и матлабе тоже огромное количество людей ещё пишут, хотя по задумке питон их должен был бы убить.
Даже когда (и если) станет в чем-то слабее аналогов, очень долго продержится на плаву.

Так он всегда, с самого начала, был «в чем-то слабее аналогов» — просто во многом другом был или стал сильнее.
Языки у которых была больая аудитория умирают совсем не похоже на остальные.
Вторые быстро схлопываются. А вот первые ооочень долго мучаются.
Вот меня всегда удивляют, почему Julia рекламируют Питонистам?
Почему не рекомендуют её веб-программистам на php?
Или почему Julia не рекомендуют программистам на C, C++, go, java, rust, swift?
Представляете, как бы такая статья выглядела? «Ну, Julia — это язык, похожий на ваш, но похуже...».
Задумайтесь, ведь Julia — это же язык общего назначения, правда?
Или это JIT для python с кучей странных решений в дизайне языка и без библиотек? Так у нас тогда Cython и Numba есть.
Да и pytorch вы так и не написали для Julia, если уж хотите для AI / Machine Learning быстрый язык программирования придумать.

Ну наверное потому что для php основная область применения — это веб, а у Julia и Python общая целевая аудитория. Собственно, это как раз единственное что в статье и сказано.
Универсального решения нет. Для каждой области — свой язык и так будет, пожалуй, еще лет 10-15 минимум.
Возможно именно недостатки и удобство Python послужили причиной создания языка, который его основатели считали удобным для каких-то целей.


Задумайтесь, ведь Julia — это же язык общего назначения, правда?

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

А вот автор этой статьи с вами не согласен: он считает, что Julia — лучше C / Ruby / whatever. И ещё и быстрее. Но сравнение идёт почему-то лишь с питоном! :) А на вопрос «Да чем лучше-то?» автор отвечает, как в анекдоте, «чем Питон»…
(быстрее C, говорите? benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/julia-gcc.html, отставание от C на 20% в среднем. Что интересно, у Julia, насколько я помню, тот же LLVM что и у clang, так что или gcc немного быстрее код генерирует, чем clang, или Julia почему-то всё медленнее делает… непонятно...)

Но, в общем-то понятно, почему язык нишевый:
1) всё ещё нет нормальных библиотек. Тут проблема курицы и яйца, но с годами она почему-то плохо решается. Посмотрим на ситуацию ещё через пару лет.
2) некоторые странные решения, типа нумерации массивов с единицы по-умолчанию, глобальных неймспейсов для перегрузки функций.
3) мало полезных абстракций для системного программирования, например, нельзя отключить garbage collector.
4) раньше, когда я им пользовался, постоянно менялось API, но после 1.0 вроде бы перестали так делать. Но есть Fluxml, где опять непонятки: то ли использовать cuarrays.jl, то ли cuda.jl — в общем, напишите мне кто-нибудь, когда сделают нормальный DL на Julia, и веб-фреймворк, на котором удобно можно будет потом засервить модельки. И починят векторизацию на CPU (или починили уже?), потому что в 2017м у меня numpy обгонял julia, местами в несколько раз, а всё потому, что numpy лучше использовал векторизацию.
В общем, если кто разбирается, расскажите лучше, есть ли где-то такое сравнение, где Julia лучше C/Go/Rust/Nim. И расскажите, когда же доделают уже библиотеки для Julia.

Спасибо что вы ворвались в этот тред и так нам все разъяснили внезапно. Тут, правда, все это уже обсудили, но, конечно, велкам.

А вот автор этой статьи с вами не согласен: он считает, что Julia — лучше C / Ruby / whatever.

Статья конечно так себе, но вот этого автор не утверждает — вы точно тот же самый пост читали? И вообще почти никогда в реальности не бывает такого, что один язык объективно «лучше» другого — всегда есть преимущества и недостатки.

быстрее C, говорите? benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/julia-gcc.html, отставание от C на 20% в среднем

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

раньше, когда я им пользовался, постоянно менялось API, но после 1.0 вроде бы перестали так делать

Так в этом и суть ранних версий — не запариваться по поводу обратной совместимости. Я до 1.0 поэтому вообще не смотрел на julia.

потому что в 2017м у меня numpy обгонял julia, местами в несколько раз, а всё потому, что numpy лучше использовал векторизацию

Возможно, это были вычисления, в которых у вас numpy использовал MKL, а julia нет.

всё ещё нет нормальных библиотек. Тут проблема курицы и яйца, но с годами она почему-то плохо решается. Посмотрим на ситуацию ещё через пару лет.

Практически прозрачно можно пользоваться питоновскими библиотеками. Ну и ситуация в julia постоянно улучшается — я сейчас из питона беру только matplotlib и несколько модулей, которые сам писал ранее.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.