Comments 28
Язык Julia на третьем месте по популярности представлнных решений
с площадки rosettacode.org Rosetta Code/Rank languages by popularity/Full list
но, возможно, за счёт каких то его фанов или усилиями разработчиков включённых в его развитие? (т.к., вроде, по нему нет достаточного количества издаваемых книг, если они вообще есть)
А на первых местах в этом списке Phix, Wren – не сказать, что очень популярные языки. Я думаю, что рейтинг Stack Overflow будет немого более репрезентативным. А там насколько я знаю Julia далеко не в лидирующих позициях по запросам.
Да, это не учитываемый, вероятно, рейтинг в подсчёте презентабельных статистик,
но какие то выводы и по нему можно сделать.
FreeBasic, к примеру, в нём сейчас на 14-ом месте и в целом разных упоминаний Бейсиков в нём много, но Вас же в Julia что то привело к действию обратить внимание на этот язык и сподвигло написать статью о нём.
по нему нет достаточного количества издаваемых книг
Если никто список не шлёт… Относительно свежие, доступные для тех кто склонен поступать дурно, и вроде как выходят всё чаще.
Hands-On Julia Programming
Interactive Visualization and Plotting with Julia
Julia as a Second Language - вводный курс
Julia for Data Analysis
Practical Julia - соответствует названию
Web Development with Julia and Genie
Развлекаемся с Джулией
Ну, не так уж и совсем с Джулией, или не со всей Джулией, скорее с REPL Джулии и то больше в пределах терминала. Написать статью про Джулию без единого красивого графика - это оригинально.
Развлекаться с Джулией - это скорее делать из неё stand alone application, это будет как футбол где для перемещения мяча используются наименее подходящие части тела, хотя для Мака проблема вроде уже решена. Или пользовать в Джулии модули Python. Или связывать её с С++, что вроде как предусмотрено изначально, осталось придумать зачем.
Pluto.jl – это Jupyter notebook, для Julia. Пока он уступает по возможностям и в "отполированности" Jupyter, но проект постоянно развивается.
Можно встретить и прямо противоположное мнение - Jupyter неспособен полностью раскрыть преимущества Джулии. Кроме того, у Pluto идеология спредшита, ячейки связаны по смыслу, а у Jupyter - текстового документа, ячейки связаны положением.
Julia не идеальна
Более того, недавно совсем произошёл обмен статьями известных кавалеров Джулии где один утверждал, что и пакеты и сама Джулия забагованы beyond repair, а другой отвечал в том смысле, что у Джулии есть масса уникальных достоинств, то есть не по делу. Это тревожит.
Это правда, когда пишут о Julia, то обычно показывают красивые графики – было написано много хороших библиотек именно для этих целей. Но я думаю, что Ansible и yum сыграли не меньшую роль для популярности Python, чем такие проекты как Pytorch. Python начинался с маленьких скриптов для автоматизации, а Perl как замена для AWK и sed. Julia, как мне кажется для этого подходит не хуже, чем для математического программирования.
Насколько бы мне ни нравилась Julia, для скриптинга она подходит очень так себе.
С точки зрения производительности надо избегать глобальных переменных, лучше всё оборачивать в функции. А это немного не кейс скриптов, как мне кажется.
Ну и первый запуск кода обычно не слишком быстрый, т.к. сперва происходит компиляция кода в IR. Поэтому будет чувствоваться медленным
Вот то, что надо постоянно гонять - на джулии самое то писать. Всякие расчёты и т.д.
За счёт выразительности языка проще будет писаться. Это язык для научных вычислений и он таким сделан неспроста)
Вы правы, конечно, что у Python лучше startup time, но для скритового языка, как показывает пример ruby – это не критично. Bash и Perl еще быстрее, но за это приходится платить недостающей функциональностью или «читабельностью» кода, как в случае с Perl и AWK.
У Julia есть AOT компиляция с помощью PackageCompiler.jl, PCRE, макросы и многое другое. На мой взгляд – это хороший размен, но у каждого может быть свое мнение.
Можно встретить и прямо противоположное мнение
И я с ним согласен. Ноутбуки Pluto очень классные. У юпитера всё хуже с повторяемостью, и нет такой интерактивности (ну или я не знаю о таких фишках там)
Развлекаться с Джулией - это скорее делать из неё stand alone application
Ну это уж точно то ещё развлечение. А вообще, покажите хоть один интерпретируемый язык, где с этим не будет проблем.
А вообще, покажите хоть один интерпретируемый язык, где с этим не будет проблем.
Lua. Потому что встраивается в С, а совместимость с C везде относительно хороша. Python. Потому что Kivy - проблемы порешали добрые люди.
Вообще-то Джулия не интерпретируемый язык, поэтому на мобилках и Lua и Python представлены, а Джулия - нет. Разве что может быть через Termux со товарищи, не знаю, но и это в любом случае ненадолго.
Вообще-то Джулия не интерпретируемый язык,
Не согласен. Интерпретируемый по умолчанию, с возможностью сборки в бинарник. Или что тут имелось в виду?
...поэтому на мобилках и Lua и Python представлены, а Джулия - нет.
И поэтому не очень понимаю вот эту часть.
Тот же Kivy тащит за собой рантайм (хоть и в сокращённом виде), без этого никак. На Джулии тоже такое возможно, есть даже StaticCompiler.jl
Я скорей поверю, что Джулия на мобилках пока просто не требуется, поэтому её и нет)
Джулия jit- компилируется. Поэтому у неё скорость выполнения близка к С или Rust. На мобилках же W^X политика, проталкиваемая под видом заботы о безопасности - то, что может быть записано, не может быть выполнено. Поэтому чисто интерпретируемые языки работают пока не понадобились бинарные модули помимо предустановленных, то есть проверенных магазином, а jit-compiled языки не работают вообще.
На Андроид от этой политики, на самом деле введённой чтобы исключить на народных устройствах обработку информации произвольным образом, можно уйти затребовав совместимость со старой версией Андроид на которой её ещё не было. Приложениям Play Store такое уже нельзя, устанавливаемым APK пока можно. Как пример - Termux.
На iPadOS для приложения Playgrounds сделано исключение. На десктопных ОС исключений больше, но недавно с интересом узнал, что один популярный диалект LISP не может работать на Маках с М процессорами ибо Эппл продвинула на них W^X политику дальше.
На счёт смартфонов не уверен, на них всё неудобно. Но на планшете Джулия очень даже нужна, это точно. Если конечно не удерживать себя на уровне YouTube да мессенджер.
Понял, спасибо за ответ.
Не знал про политику W^X, спасибо что просветили. В последний раз когда я делал что-то под Android, там ещё был Dalvik, который JiT, а не AoT.
Получается, что на мобилках мы вообще никогда не увидим гомоиконичных языков, если так всё будет продолжаться?
так всё будет продолжаться
Это невозможный вариант, острая фаза чего бы то ни было продолжаться долго не может. Моё личное мнение - либо увидим, был же Linux on DeX продвигавшийся Самсунгом при очевидном полном одобрении Гугла, либо не увидим ибо на терминале получения приказов без надобности, либо вопрос потеряет актуальность за отсутствием гаджетов.
вообще никаких проблем делать из джулии приложение или встраиваемую библиотеку (если закрыть глаза на размер, но в 24м и это собираются поправить)
Питонисты DS-толка с уважением смотрят на медленное "восхождение" Julia, но использовать пока не спешат. Уговоры о близости синтаксиса не срабатывают, обилие скобочек и всевозможной пунктуации (расплата за отказ от отступов) - напрочь лишают блокнотный код привычной DS-читаемости, уже достигнутой в Python. Так что, объективно, с этой стороны поддержки не будет.
Обилие скобочек? Это же не лисп, их тут немного. Вы точно видели код на Julia?
Если приведёте пример кода с обилием скобочек, будет очень интересно посмотреть)
Уговоры о близости синтаксиса не срабатывают
Это к Mojo, Julia не пытается быть Python
Так что, объективно, с этой стороны поддержки не будет
Очень сомнительно, учитывая отличную поддержку в Julia автоматического дифференцирования за счёт метапрограммирования. Фреймворки автоматического дифференцирования на Python в принципе могут справиться далеко не со всем
Мне кажется большинство питонистов DS-толка не занимается решением задач где нужен C/C++ (то есть там где важен перфоманс), потому что тогда они бы по другому посмотрели на Julia.
Не хочу утрировать, но у нас DS развивается в основном в корпорациях, – а там Hive/Hadoop, Spark, Airflow и Jupyter Notebook. Бери то что дают. Это хороший стек, есть кадры которые с ним знакомы, но на типовых решениях никогда не будет инноваций.
Задачи DS толка не предусматривают перформанс, там вообще не всегда очевидно как решить задачу по этому пишутся алгоритмы и используется доступная математика а вот если вся эта математичность взлетит то есть задача будет решена с нужным уровнем качества тогда уже можно думать про скорость ресурсы и прочий перформанс.
Для DS на этапе исследования и проверки гипотез важна интерактивность и визуализации данных. Именно для этого нужен REPL и такие проекты как Trino/Presto, Cube.js и так далее. На этом уровне, при современных объемах данных, перфоманс очень важен.
Правда я занимаюсь, доставкой (кода), а не DS. В этой сфере перфоманс тоже очень важен.
Ну вот смотри типичная DS задача, нужно определить с кой вероятность пользователь нашего сервиса не вернет кредит, расскажи мне здесь про REPL и куб ди эс
Понятия не имею, да это и не имеет особого значения, для меня.
Но интересный момент, смотри, есть компании, которые для решения подобного рода задач, использовали базу данных от одной известной американской корпорации и программку от сторонних разработчиков у которой есть GUI. База данных и программка – это монолит написанный на C/C++. Лицензии на этот софт стоят не малых денег, но со своими задачами он справлялся.
В 2023 году российские компании мигрируют на open-source (там где нет отечественного ПО), и решают те же самые задачи, только вместо монолитной базы данных, им приходится постоянно перекладывать информацию из озера данных в СУБД. Hive/Hadoop, GreenPlum, Airflow, Spark, PostgreSQL и так далее. В эту цепочку можно добавить Trino/Presto для агрегации данных из разных источников и MMP, cube.js для сематического слоя.
Разработчики ClickHouse решили эту проблему в OLAP, «просто» написав монолитную БД на C++.
Всегда можно написать производительный код и решить таким образом проблему. Перфоманс имеет значение.
Все что ты написал не имеет никакого отношения к DS и к задачам которые решает датасантист
Решать ДС задачи с помощью GUI - это отдельный вид слабоумия, хотя ТОПам нравится идея ноу кода и лоу кода, но в реальности это все очень хреново заканчивается.( почему нравится и почему хреново заканчивается отдельная очень обширная тема, энивей SAS начал исчезать в 2016-2017 и окончательно стал тыковой году в 2020м)
Все эти переливы данных из транзакционных БД в озеро и из озера в аналитическую БД - это работа дата инженеров и ETL разрабов.
Я тебе больше скажу все эти кликхаусы это для аналитиков что бы отчетики делать и дашики с графичками то есть это продуктовые аналитики, аналитики данных и BI'щики опять же не DS'ы
И отчетики они делают в экселечках а дашики раньше в Табло а теперь в дата ленс, такие дела.
DS - это python, может быть R если не надо работать с современными архитектурами нейронок
"DS - это python, может быть R если не надо работать с современными архитектурами нейронок".
Это войдет в анналы. Без numpy и pandas (которые написаны на c) не может быть DS. Ну может быть на R еще.
LOL
Не думал что мы говорим про анал
На R большинство хороших пакетов для анализа данных использует либо плюсы либо фортран под капотом или андерхуд кому как удобней воспринимать метафоры
Пандас и напай это уже вчерашний день у четких патсанов от мира ДС, вместо первого поларис вместо второго джакс
Еще правда была scala для работы со spark но кажется что не взлетело и уже вряд ли взлетит пушто все работают на pyspark
если посмотреть на релизы pyspark и sparkR то становится очевидным что в бигдате по широте использования R очень сильно отстает от питона
Automate the boring stuff with Julia