Comments 68
Рановато питон хоронят. Ещё перл не весь вымер.
Не являюсь фанатом Питона. Даже по сути не знаком с ним толком.
Но по результату прочтения статьи я скорее в сторону Питона буду смотреть при необходимости, чем в сторону этого нового языка.
Но по результату прочтения статьи я скорее в сторону Питона буду смотреть при необходимости, чем в сторону этого нового языка.
UFO just landed and posted this here
Решил почитать документацию про этот язык...
Массивы индексируются с 1. Ну спасибо теперь. Удачного перехода с других языков?
Конкатенация строк через "*"? Хм..
Интерполяция (подстановка переменных внутрь строки) — в Python я не очень приветствовал f-строки, но тут вообще кивок в сторону Perl..
Похоже что они снова наступили на грабли всех новых языков когда в общий namespace включено куча функций из стандартной библиотеки: pwd, cd, mkdir, download, mktempdir — вот прямо так всегда нужны в каждом модуле? Это только я наугад выбрал. В Python они все в модуле os и если нужны — импортируй сам. Явное лучше неявного. Это ж сколько надо теперь запомнить ключевых слов и стандартных функций чтобы не переопределить ненароком? Назвал переменную mark? Напрасно — это функция такая есть.
Возможно я тут неправ и namespace настраиваются, но это просто беглый взгляд.
Зато области видимости переменных, вроде, сделали по-нормальному — переменная, которую определили внутри цикла (блока) снаружи не видна.
Первый раз посмотрел на этот язык и написал коммент только на то что сразу бросилось в глаза — кто может опровергнуть — пожалуйста.
UFO just landed and posted this here
Это сделано для нормальных людей. Как человек считает яблоки: первое, второе, третье…. Вряд ли кто-то начинает с нуля. Что такое нулевое яблоко? Шиза. В Фортране кстати тоже индексирование начинается с нуля.
Здесь лучше вспомнить аналогию с возрастом: первый год жизни — это когда 0 лет.
Год продолжается, яблоки нет. Индексированная переменная — дискретная величина: первая, вторая, и т.д. Или индекс может быть real? (от такого ужаса даже в Фортране отказались полностью). И не надо рассказывать про смещение как в С, оно интуитивно понятно только программистам, да и то далеко не всем. Для физиков-статистиков-биологов-бухгалтеров и т.п. индексация с 1 интуитивно понятнее (они и слов-то таких как смещение не слышали).
Ладно, индексы — это тоже древний холивар. Я не хотел портить вам чувство прекрасного, но придется снова сходить с козырей.
Как вы думаете, что происходит в этой строке кода?
a = [1 -2; 4 -5]А это, дорогие друзья, объявление двумерного массива! Это не один-минус-два, а, внезапно, пробел, разделяющий элементы. Помнится, многим сильно мешали отступы в Питоне? А вот прочитайте-ка пробелы в середине текста. Я не уверен, но, возможно, если после минуса поставить пробел, то это уже будет арифметическое выражение. Интуитивно понятнее? (простите за сарказм, ничего личного)
Ну вы еще Бейсик вспомните. Простите, но вы документацию видели по этой Julia?
Человек, не знакомый с другими языками программирования ее не поймет. А знакомый — будет все время испытывать неудобства.
Синтаксис языка довольно богатый — это, скорее, плюс, но новичкам тут не место.
Индексация с нуля для программиста на, скажем, Си — интуитивно понятнее, поскольку индекс массива — это смещение относительно указателя на первый элемент. Ну а оттуда и все остальные переняли это.
С индексами особо не важно, откуда они начинаются по-умолчанию. Обычно нужно либо проитерироваться по массиву, либо взять первый/последний элемент — в этих случаях явные индексы в коде не фигурируют вообще. Если же существенно используется обращение по индексам, то часто удобнее обращаться к массиву не с 0 или 1, а совсем по другим диапазонам вроде -n/2...n/2 или даже -1 метр… 1 метр. И если первое (итерация) достаточно удобно записывается и в питоне, и в джулии, то вот во втором (произвольные индексы) джулия явно побеждает.
Ну вот я в последние пару лет весьма удачно перешёл с питона на джулию — неудобства конечно есть (не бывает ничего идеального), но их явно меньше, чем в питоне. Питон продолжаю использовать для некоторых более старых проектов — кстати, interop с джулией очень прозрачно работает.
Человек,… знакомый [с другими языками программирования] — будет все время испытывать неудобства.
Ну вот я в последние пару лет весьма удачно перешёл с питона на джулию — неудобства конечно есть (не бывает ничего идеального), но их явно меньше, чем в питоне. Питон продолжаю использовать для некоторых более старых проектов — кстати, 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 обычно включают в натуральные, да и у нас тоже по-разному бывает. Например, на кафедре теории чисел у нас пропагандировали натуральные числа с нуля, а на кафедре математического анализа — с единицы.
UFO just landed and posted this here
> Натуральный ряд — ряд индукции
Декларации такие декларации…
> Для индукции необходима 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 (итал).
UFO just landed and posted this here
> Скасиоматиа Пеано крутится вокруг индукции
Аксиоматика Пеано не крутится вокруг индукции, в ней все аксиомы необходимы, как, впрочем, это всегда и бывает в системе логически независимых суждений. Она описывает лишь отношения между понятиями «начальный элемент» и «следующий элемент».
До кучи рекомендую следующий комментарий со страницы обсуждения в Википедии:
> И я зная что такое ряд
Вынужден разочаровать. Натуральные числа, как и вообще любые счётные множества, словом «ряд» не называют. Термин этот означает совсем другое.
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 есть натуральное число». Однако, в 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
по-моему, язык очень симпатичный и заслуживает хотя бы ознакомительного внимания)
UFO just landed and posted this here
Согласен. Если бы всем нужна была максимальная скорость — все писали бы на C++. Я раньше любил C, но после питона не хочется возвращаться к компиляции, фигурным скобкам, точкам с запятыми в конце строки и т.д. На C просто иногда хочется пописать в кайф и почувствовать себя олдом.
Все — на C++? Вы серьезно? Вы думаете не-программист (физик, химик, биолог) его осилит? Julia проста как питон (никакого компилятора) и при этом быстро почти как как в C. Для вычислений самое то что надо. Для всего остального она точно не подходит. Этот язык занимает нишу R, Matlab, и т.п. Отсюда и все эти странности с точки зрения программиста.
Если еще вспомнить, что большинство питоновских ML библиотек на самом деле просто обвязки над весьма оптимизированным С-шным кодом, то вообще непонятно в чем весь пафос Julia
UFO just landed and posted this here
Многофункциональность нужна далеко не всем. А пиарят его потому, что сейчас все студенты физики/математики/химики/биологи и т.п. должны обязательно учить «программирование». И что-же они учат? Не C/С++ или даже Fortran, а R и Python. Потом, когда нужно что-то посчитать (и нарисовать табличку и график), написанная абстрактным PhD студентом программка на питоне считает часами или даже днями при этом сжирая всю память и вводя модный Макбук в ступор. Вот для такой аудитории этот язык, не для общей computer science или абстрактного многофункционального «программирования.»
А вы думаете что нельзя на Julia написать код, который сожрет всю память? Плохой пример у вас.
На любом языке надо писать с оглядкой на производительность, а это получается уже после солидного опыта, а там уже не так важно какой язык.
Я часто вижу код, который пишут аналитики. У них математическое образование и они каждый день оперируют очень сложной бизнес-логикой. Но от их кода (Python или SQL или VBA) у меня глаза хотят вытечь.
Физики-химики-биологи обычно пишут совершенно невероятный код. Чаще всего вообще без оглядки на производительность, необходимость дальнейшей поддержки, реюз и т.п. Но порог наступления катастрофы разный. На Python, она наступает раньше. То есть кривой код, который достаточно быстро и безболезненно работает на фортране превращается в полную катастрофу на питоне. На Julia такой же примерно код с большей вероятностью как-то заработает. И да, сломать можно любой язык. Добро пожаловать в новый дивный мир, в котором почти все программируют. В этом мире всех учат «кодить,» но не учат «программировать» (а это прежде всего software engineering).
UFO just landed and posted this here
На питоне можно писать быстрый код. Но это требует изучения numpy (и т.п). А это отдельная сущность, отдельная работа, требующая усилий и времени. Причем со своими концепциями, например статическими типами. Для многих непрограммистов, пишущих код (а число таких людей растет) все это часто бывает большой проблемой (такова жизнь). Julia же позволяет написать считалку в рамках всего одного инструмента. Вот поэтому ее и пиарят. Не поймите меня неправильно, я не призываю всех переходить на Julia. Но у нее действительно есть свои положительные стороны в своей основной нише.
UFO just landed and posted this here
Поясните, каким боком сюда котлин? Насколько я пониманию, его основная ниша — андроид, и на неё не особо претендуют что питон, что джулия.
В обратную сторону — посмотрел сейчас на гитхабе что пишут на котлине. Как я и думал, в плане научных вычислений и ds практически ничего нет, буквально несколько пакетов с самой базовой статистикой и т.п. В отличие от джулии в нём нет и прозрачного интеропа с питоном (как я понял) — то есть нельзя просто использовать питоновские библиотеки когда нужно.
Ну и одно из главных преимуществ джулии — почти вся стандартная библиотека написана на самом языке, все пользовательские пакеты тоже. Это значит, что не нужно знать несколько языков для понимания или правки имеющихся пакетов, для написания производительного когда; сравните с питон + си, котлин + джава.
В обратную сторону — посмотрел сейчас на гитхабе что пишут на котлине. Как я и думал, в плане научных вычислений и ds практически ничего нет, буквально несколько пакетов с самой базовой статистикой и т.п. В отличие от джулии в нём нет и прозрачного интеропа с питоном (как я понял) — то есть нельзя просто использовать питоновские библиотеки когда нужно.
Ну и одно из главных преимуществ джулии — почти вся стандартная библиотека написана на самом языке, все пользовательские пакеты тоже. Это значит, что не нужно знать несколько языков для понимания или правки имеющихся пакетов, для написания производительного когда; сравните с питон + си, котлин + джава.
UFO just landed and posted this here
А Джулия наоборот узкоспециализированный язык
Это-то с чего вдруг? В языке ничего сильно ограничивающего область применения не вижу, кроме разве что сборки мусора.
Действительно сильные библиотеки на джулии сегодня и правда есть почти только для разного рода вычислений — просто потому, что в этой сфере наиболее очевидны преимущества языка, и не особо важны (временные) недостатки. Основной недостаток — медленный старт, и над этим плотно работают с разных сторон, от версии к версии видны стабильные улучшения.
Про котлин в ключе использования для вычислений первый раз слышу, но всё равно как-то не особо понятно зачем на него с питона переходить (если не работаешь в jetbrains). Сразу теряешь все свои наработки и привычные библиотеки, а принципиальных преимуществ не видно. Ну и субъективно я jvm как-то не люблю :)
При переходе же на джулию получаешь компиляцию в машинный код, несравнимо более богатые возможности объединять независимые библиотеки, удобный автодифф, хорошую интеграцию с GPU вычислениями, и многое другое. Это всё получилось не в последнюю очередь благодаря именно дизайну языка. Вдобавок можно продолжать полноценно использовать свои имеющиеся питоновские модули. Ещё есть прозрачный, насколько это возможно, интероп с Си без оверхеда.
UFO just landed and posted this here
… но мне не нравится идея изучать целый язык со всем его окружением только ради вычислений. Возможности языка в других направлениях (приложения, сайты...) для меня под большим вопрос, ...
Не очень понимаю, в чём собственно «большой вопрос»? Помимо вычислений, например, удобно пишутся скрипты которые переросли баш, околосистемные демоны, всякие клиенты к 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.
Для личных проектов или производственных?
Я занимаюсь астрономией/астрофизикой, и понятия «производственных проектов» нет. Личными рабочие проекты тоже нельзя назвать — частью из них кроме меня пользуется немного людей, но больше нуля :) По факту сейчас практически только на джулии и пишу.
Есть ли перспективы у языка программирования Kitten?
kittenlang.org
Код проекта на Github The Kitten Programming Language (~800 stars)
kittenlang.org
Код проекта на Github The Kitten Programming Language (~800 stars)
Всё конечно радужно и прекрасно, но хотелось бы видеть в статье хотя бы пару примеров с кодом.
Разработчики Julia хотели получить такой же быстрый язык, как C — но то, что они создали, стало ещё быстрее[ссылка на статью].
Возможно, я ошибаюсь, но в статье и близко нет речи о том, что Julia быстрее С
Очень символично, что Edison перевёл статью без указания источника: https://towardsdatascience.com/bye-bye-python-hello-julia-9230bff0df62?gi=1707cca4ab41
Разве под заголовком нет вот этой ссылки: "Автор оригинала: Rhea Moutafis"?
Если статья переводная, то мы всегда оформляем именно как «Перевод» с указанием автора и ссылки на первоисточник.
Если статья переводная, то мы всегда оформляем именно как «Перевод» с указанием автора и ссылки на первоисточник.
у нас в России пайтон то еще не все компании используют, а с новым (молодым языком) свою вакансию можно долго искать, за то если такие появятся, то будет некое преимущества…
И вообще, если развивать PyPy, то и никакая Julia не понадобится.
UFO just landed and posted this here
«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 не рекомендуют программистам на 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.
(быстрее 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 и несколько модулей, которые сам писал ранее.
Only those users with full accounts are able to leave comments. Log in, please.
Пока, Python. Привет, Julia❗