Комментарии 71
Рановато питон хоронят. Ещё перл не весь вымер.
Не являюсь фанатом Питона. Даже по сути не знаком с ним толком.
Но по результату прочтения статьи я скорее в сторону Питона буду смотреть при необходимости, чем в сторону этого нового языка.
Но по результату прочтения статьи я скорее в сторону Питона буду смотреть при необходимости, чем в сторону этого нового языка.
НЛО прилетело и опубликовало эту надпись здесь
Решил почитать документацию про этот язык...
Массивы индексируются с 1. Ну спасибо теперь. Удачного перехода с других языков?
Конкатенация строк через "*"? Хм..
Интерполяция (подстановка переменных внутрь строки) — в Python я не очень приветствовал f-строки, но тут вообще кивок в сторону Perl..
Похоже что они снова наступили на грабли всех новых языков когда в общий namespace включено куча функций из стандартной библиотеки: pwd, cd, mkdir, download, mktempdir — вот прямо так всегда нужны в каждом модуле? Это только я наугад выбрал. В Python они все в модуле os и если нужны — импортируй сам. Явное лучше неявного. Это ж сколько надо теперь запомнить ключевых слов и стандартных функций чтобы не переопределить ненароком? Назвал переменную mark? Напрасно — это функция такая есть.
Возможно я тут неправ и namespace настраиваются, но это просто беглый взгляд.
Зато области видимости переменных, вроде, сделали по-нормальному — переменная, которую определили внутри цикла (блока) снаружи не видна.
Первый раз посмотрел на этот язык и написал коммент только на то что сразу бросилось в глаза — кто может опровергнуть — пожалуйста.
НЛО прилетело и опубликовало эту надпись здесь
Это сделано для нормальных людей. Как человек считает яблоки: первое, второе, третье…. Вряд ли кто-то начинает с нуля. Что такое нулевое яблоко? Шиза. В Фортране кстати тоже индексирование начинается с нуля.
Здесь лучше вспомнить аналогию с возрастом: первый год жизни — это когда 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 обычно включают в натуральные, да и у нас тоже по-разному бывает. Например, на кафедре теории чисел у нас пропагандировали натуральные числа с нуля, а на кафедре математического анализа — с единицы.
НЛО прилетело и опубликовало эту надпись здесь
> Натуральный ряд — ряд индукции
Декларации такие декларации…
> Для индукции необходима 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 (итал).
НЛО прилетело и опубликовало эту надпись здесь
> Скасиоматиа Пеано крутится вокруг индукции
Аксиоматика Пеано не крутится вокруг индукции, в ней все аксиомы необходимы, как, впрочем, это всегда и бывает в системе логически независимых суждений. Она описывает лишь отношения между понятиями «начальный элемент» и «следующий элемент».
До кучи рекомендую следующий комментарий со страницы обсуждения в Википедии:
> И я зная что такое ряд
Вынужден разочаровать. Натуральные числа, как и вообще любые счётные множества, словом «ряд» не называют. Термин этот означает совсем другое.
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
по-моему, язык очень симпатичный и заслуживает хотя бы ознакомительного внимания)
НЛО прилетело и опубликовало эту надпись здесь
Согласен. Если бы всем нужна была максимальная скорость — все писали бы на 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).
НЛО прилетело и опубликовало эту надпись здесь
На питоне можно писать быстрый код. Но это требует изучения numpy (и т.п). А это отдельная сущность, отдельная работа, требующая усилий и времени. Причем со своими концепциями, например статическими типами. Для многих непрограммистов, пишущих код (а число таких людей растет) все это часто бывает большой проблемой (такова жизнь). Julia же позволяет написать считалку в рамках всего одного инструмента. Вот поэтому ее и пиарят. Не поймите меня неправильно, я не призываю всех переходить на Julia. Но у нее действительно есть свои положительные стороны в своей основной нише.
НЛО прилетело и опубликовало эту надпись здесь
Поясните, каким боком сюда котлин? Насколько я пониманию, его основная ниша — андроид, и на неё не особо претендуют что питон, что джулия.
В обратную сторону — посмотрел сейчас на гитхабе что пишут на котлине. Как я и думал, в плане научных вычислений и ds практически ничего нет, буквально несколько пакетов с самой базовой статистикой и т.п. В отличие от джулии в нём нет и прозрачного интеропа с питоном (как я понял) — то есть нельзя просто использовать питоновские библиотеки когда нужно.
Ну и одно из главных преимуществ джулии — почти вся стандартная библиотека написана на самом языке, все пользовательские пакеты тоже. Это значит, что не нужно знать несколько языков для понимания или правки имеющихся пакетов, для написания производительного когда; сравните с питон + си, котлин + джава.
В обратную сторону — посмотрел сейчас на гитхабе что пишут на котлине. Как я и думал, в плане научных вычислений и 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.
Для личных проектов или производственных?
Я занимаюсь астрономией/астрофизикой, и понятия «производственных проектов» нет. Личными рабочие проекты тоже нельзя назвать — частью из них кроме меня пользуется немного людей, но больше нуля :) По факту сейчас практически только на джулии и пишу.
Есть ли перспективы у языка программирования 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 не понадобится.
НЛО прилетело и опубликовало эту надпись здесь
«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 и несколько модулей, которые сам писал ранее.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пока, Python. Привет, Julia❗