Доступен релиз языка программирования Julia 1.8, сочетающего такие качества как высокая производительность, поддержка динамической типизации и встроенные средства для параллельного программирования. Синтаксис Julia близок к MATLAB с заимствованием некоторых элементов из Ruby и Lisp. Метод манипуляции строками напоминает Perl. Код проекта распространяется под лицензией MIT...Подробнее: https://www.opennet.me/opennews/art.shtml?num=57650
Слишком много символов разрешено и используется.
Они будут весь юникод по три символа добавлять. И минорную версию менять.
А я вот считаю что мало половин.
Реквестую язык Юрий ...
> Реквестую язык Юрий ...По опыту последних лет 50-ти, языки с женскими именами получаются куда изящнее....
Сишечка
нет, язык С, он же Си, он же Си Цзиньпин.
Язык Ада
Ещё один ненавистник паскаля и фортрана :)
Паскаль и Оберон форева!
А Го вообще суслик!
Агриппина, Параша, Даздраперма - женские названия для импортозаместительнх языков
> Реквестую язык ЮрийРеквестирую языки "олег" и "оксана"
А как вам Саша? Унисекс
Валя же есть.
>А как вам Саша? УнисексАркадий лучше ... Солиднее ... Ну, или Андрюшка хот бы.
Много интересного появилось. При запуске бинарников, если весь код откомпилирован, теперь можно съэкономить 60МБ на LLVM компиляторе.
уже лет пять вижу эти -60 мб в каждой новости
> уже лет пять вижу эти -60 мб в каждой новостиГалюцинации
Круто что они не растут. Типа за пять лет они могли стать 600 мб.
Так и незашла эта жулия.
Слишком много телодвижений нужно для всего.
Пытался нагуглить что-то по типу питорча - то ли Гугл не едет то ли я не то гуглю.Давно не интересовался но хоть на видеокарте она считать умеет из коробки?
> Пытался нагуглить что-то по типу питорча - то ли Гугл не едет то ли я не то гуглю.Flux.jl и ONNX.jl для запуска чужих готовых моделей
> Давно не интересовался но хоть на видеокарте она считать умеет из коробки?
конечно:
julia> using CUDA
julia> CUDA.functional()И даже в M1/M2 умеет - Metal.jl
Ну модели можно и на плюсах запускать и везде.
А вот учить...Только куду кстати поддерживает?
Надо будет как-то ещё раз взглянуть, может удастся от питона сбежать.
> Ну модели можно и на плюсах запускать и везде.А смысл? Остальной код всё равно хочется не на плюсах делать.
> Только куду кстати поддерживает?
CUDA.jl и https://github.com/JuliaGPU в целом
на видеокарте, а не на невидии
С прошлого выпуска - очень проникся. После обычных ООП языков очень необычно пишется, абстрагировано, удобно для научных расчетов.Но главный косяк языка, имхо - это комьюнити, многократно меньшее, чем у того же питона. И как следствие, многие популярные пакеты заброшены и/или находятся в недописанном состоянии.
Ну Julia почти в три раза моложе Python, у которого приличное комьюнити возникло лет этак через 20 с момента его появления.
До 2018-го (когда Julia 1.0 вышла), ею вообще мало кто пользовался. За 4 года прирост очень значительный.
Синтаксис хороший, но отсутствие полноценного отладчика, делает Джулию мало пригодной.
Не может быть "популярность" и коммунити у специализированного языка быть такой же как у более массового, и тем более языка для обучения.
Был бы язык для физиков-теоретиков, так о нём бы и вовсё почти не слышали, будь язык хоть трижды классным.
'производительности близкой к программам на языке Си'
есть же Си и миллиард либ под любые нужды
Когда вам нужно решить конкретную задачу, думать об особенностях си без соответствующего багажа знаний проводить к серьёзным провалам
Поэтому все начинают изучать джулию, чтобы накопить багаж знаний
более того, когда нужно решать серьёзные задачи вообще лучше не думать!
В Юле я так понял прикол в том что код очень, очень динамический, что важно для датасатанистов.Например вы можете объявить на вашем типе операцию умножения между объектами этого типа, и все либы, которые умножали объекты одинаковых типов будут работать (ну, почти всегда). Юлия перекомпилирует весь их код под ваши типы.
Это называется multiple dispatch и означает не полную перекомпиляцию, а генерацию отдельных методов функций под аргументы с указанными типами. Можно писать и без указания типов, но тогда кодогенерация под новые типы будет проходить в момент первого исполнения кода.По сути, это стандартный полиморфизм на типах аргументов функции.
Поделитесь, кто на этом языке пишет в продакшене и что
> Поделитесь, кто на этом языке пишет в продакшене и чтоNLP-сервисы. Очистка, обогащение.
Дайте пруфы)
> Дайте пруфы)Ссылки на внутренний репозиторий и паспортные данные разработчиков?....
покажи хотя бы кусок кода на пейстбине. inb4 - ничего не покажешь под любыми предлогами
Вот интересно, каков процент компаний, готовых уволить разрабов за публикацию кусков рабочего кода без согласования?....
а в чем проблема-то? судя по тому, что ты описал выше, ничего секретного, соответственно уникального там нет, для демонстрации можно выбрать кусок, не выдающий ни суть продукта. но ты ничего не выложишь не поэтому, а потому что тебе нечего показать
Когда работать начнёшь, может быть узнаешь, что такое интеллектуальная собственность и её понимание у юристов компании. А пока иди к школе готовься....
Хотя бы просто названия компаний и продуктов
https://hrtool.dotin.us/ - большая часть NLP-сервисов именно на Julia
У ACML тулинг для test coverage на нем пишется.
Поэтому ACML и не интел и не амд. Потому что занимается всякой ерундой вместо того чтобы делать бизнес.
Ты о чем? У ACML(221.12) капитализация больше чем у Intel(145.52) и AMD (154.26).
Ну такое себе... В чем выгода от эзотерики?
Опять наркоманский синтаксис как у большинства новых модных молодежных язычков ?
Python, Php и Perl: ну да ну да, пошли мы нахер.За пределами C-подобных языков вообще любой синтаксис будет казаться наркоманским. Как по мне, только у APL получилось добиться реального безумия.
Да он и у сишки казался наркоманским на момент её изучения - тонны всевозможных скобок и прочие прелести
Что там учить-то? Возьмите нормальные источники: Керниган-Ритчи или Уэйт-Прата.
Не думал что Си нужен был просто нормальный синтаксис чтобы его все использовали?
Синтаксис С не "казался наркоманским", а так и есть наркоманский по сравнению с тем же Pascal, Ada.
Я не буду перечислять всех идиотизмов и двусмысленностей синтаксиса С, его макросов и т.д. - о них и так уже много где написано. Не зря же для программирования встраиваемых устройств на С придумали стандарт MISRA, в котором убраны некоторые идиотизмы С.Я ничего не имею против С. Но его надо бы было маленько переработать, убрав весь исторический шлак развития компиляторов, препроцессор, но оставив по большей части синтаксис, и другие фишки С - работу с указателями, памятью и т.д. А не плодить языки типа новые наркоманские языки типа D, Rust, Julia и т.д. В конце концов весь код превращается в одни и те же инструкции процессора, и надо работать, а не изучать новые, якобы современные языки программирования, но которые требуют тонны памяти, гигабайты энергии и т.д.
Во-первых, не одни и те же инструкции. А во-вторых, батенька, вы знаете извращения с многословным паскалем
заткнись, питон идеален
загрязнение окружающей среды из-за отсутствия скорости выполнения и траты места на пробелы - это идеально?
для тех задач, на которые нацелена решать julia есть нативные библиотеки, работающие быстрей этой самой julia. что ты там под тратой места имел ввиду, я даже знать не хочу, такие как ты (не работавшие ни с чем, ни с питоном, ни с джулией) еще любят упоминать gil
> заткнись, питон идеаленгромоздкий и корявый синтаксис
разработчики, не способные осмыслить функциональные парадигмы
Конечно он идеален. Даже больше, синтаксис C-подобных языков я считаю гораздо более наркоманским. Особенно плюсов. К нему можно привыкнуть, но чтение шаблонов шаблонов шаблонов требует интересной ментальной эквилибристики.
Питон идеален, поэтому пусть он лучше стоит в сторонке под бронированным колпаком. Чтобы никто своими грязными руками этот идеал в прод не тащил... Да и вообще, поменьше лапал, чтобы не испортить.
> достижение производительности близкой к программам на языке СиМожет, сразу взять С и не заморачиваться?
Чем это лучше Фортрана?
У желающих приторчать теперь есть наркоманский синтаксис. Рестораны нервничают.
Дело не в синтаксисе, а в перегруженности самого языка возможностями, которые к нему не нужно относить, оставив в стандартных библиотеках. Подобно тому, как в С, что делает язык простым и лаконичным.
> Дело не в синтаксисе, а в перегруженности самого языка возможностями, которые к
> нему не нужно относить, оставив в стандартных библиотеках. Подобно тому, как
> в С, что делает язык простым и лаконичным.Си далеко не лаконичный. И далеко не ортогональный. Но, относительно не перегружен.
Удобно отлаживаться (так как код компилируется на лету), есть возможность интерактивной работы в стиле скриптовых языков (например, в Jupyter, Juno), приятный лаконичный синтаксис, скорость выполнения примерно как у Фортрана (во многих тестах даже обгоняет). Важно, что в сообществе разработчиков есть адекватная концепция дальнейшего развития языка, понимание существующих проблем, развитие идёт в правильном направлении, в последнее время виден хороший прогресс. Приятно удивляет сообщество: постоянно появляются какие-то новые интересные завязанные на Julia вещи, инструменты для повышения удобства работы, публикуются статьи, книжки, проходят конференции. Всё это очень заряжает. В сообществе Фортрана такой вдохновляющей активности нет.
Для фортранчика тоже есть реализации с возможностью интерактивной работы. Не буду показывать пальцем.
Имели много расчетных наработок на фортране. Нужно было использовать в новых задачах. Новые задачи сделали на С. Фортрановские библиотеки использовали в проектах. Все последующие расчетные методы уже делали на С.
Отлаживаться как раз не удобно. Консольного отладчика как не было так и нет. А тыкать мышью занятие такое себе.
Отличный язык. Перешел на его с R. Использую его для Data Science и Big Data. Строю кучу графиков, гоняю данные, в том числе из базы данных. Работает все шустро. Питон никогда не использовал и даже нет желания его изучать. Julia умеет практически все.
Как ты отлаживешь код?
> Как ты отлаживешь код?Детальные модульные тесты и отладочный вывод.
Для своего проекта пойдет, но когда нужно разобраться в большом и сложном чужом проекте, такой метод не сработает. Поэтому для Джулии нужен отладчик, но разработчики не спешат. Всё, что есть это сторонние проекты.
Это пошаговый отладчик вам не поможет в большом и сложном проекте. А модульные тесты для того и пишут, чтобы покрывать код по высокоуровневым функциям. И, если разработчики, которые их писали, достаточно квалифицированные, то проблем разобраться с кодом не будет.
Совершенно согласен с тем, что пошаговый отладчик не поможет. Более того, я считаю, что пошаговые отладчики придуманы для слабаков. Настоящий программист должен уметь выполнять код в уме! Программисты Джулии видимо в совешенстве владеют этим навыком. Зачем вообще придумали все эти отладчики? Gdb и прочие? Отрасль деградирует.
Просто нет у вас навыков отладки отладочной печатью. Julia далеко не единственный ЯП, у которого нет удобного пошагового отладчика (неудобный есть). В случае Julia, просто надо разбивать код на небольшие фрагменты для отладки и тестирования. Именно поэтому, надо использовать модульные тесты. Если эти тесты достаточно детальные, то проблем отладить кусок кода нет. То же в отношении Haskell, то же в отношении отладки кода на устройствах, куда просто так не подключишься. Отладка без пошагового отладчика, хоть и требует определённой привычки, но это совершенно не то же самое, что отлаживать код на листочке бумаги. И уж точно, не сложнее пошагового отладчика, хотя и требует определённой дисциплины написания кода.
Да, уж чукча не читатель, чукча писатель... Большую часть времени программисту приходится не писать, а читать код. А мне как научному сотруднику еще приходится читать кучу статей и кода к ним, который писался отнюдь не профессиональными программистами, а учеными, которые и слов-то таких как модульные тесты не знают. В общем жить без пошагового отладчика можно, но зачем?
> мне как научному сотрудникуА как, по-вашему, отлаживают код во всяких Jupyter Notebook?.... Или, например, как отлаживались https://arxiv.org/abs/2207.13513 ?
Пошаговый отладчик лишь один из вариантов отладки. Но на нём всё не зациклено.
Юпитер ноутбук инструмент, предназначенный для обучающих и демонстрационных целей. Студент защищает диплом и показывает интерактивно результате в Юпитере. Или научный сотрудник демонстрирует возможное решение руководству с графиками и диаграммами в Юпитере. Для серьезных целей не предназначен. По ссылке, код скорее всего одноразовый, смоделировали, получили результаты, опубликовали статью, забыли. Проблемы возникнут лет через 5, когда либо авторам, либо еще кому-то понадобится разобраться в статье и коде к ней. Вот тут и понадобится отладчик. А его в Джулию не завезли...
> По ссылке, код скорее всего одноразовый, смоделировали, получили результаты, опубликовали статью, забыли. Проблемы возникнут лет через 5, когда либо авторам, либо еще кому-то понадобится разобраться в статье и коде к ней. Вот тут и понадобится отладчик. А его в Джулию не завезли...Возьмите да посмотрите этот код... Зачем рассуждать о том, чего не понимаете. Одноразовый код и пошаговым отладчиком никто ковырять через 5 лет не будет.
> Юпитер ноутбук инструмент, предназначенный для обучающих и демонстрационных целей.
И тут не совсем так. Вполне себе инструмент для анализа данных. Только пошагового отладчика в нём нет.
Еще как приходится ковырять! Когда работал С-шником, как-то поручили переработать старый кусок крупного проекта. Документации нет, тестов нет, разработчик уволился 10 лет назад и уехал в Америку. Каким-то неведомым образом работает. Нужно провести рефакторинг и добавить новые фичи. И как тут без отладчика? С помощью GDB проходил и разбирался. Пол-года пришлось делать. Юпитер для анализа данных можно использовать, но я бы предпочел R-сдудию, или Матлаб (Октав). Юпитер был ответом Вольфраму, который и изобрел этот формат блокнота, презентация и код в одном флаконе. Но у Вольфрама если не ошибаюсь есть пошаговый отладчик (Давно не работал с Математикой)! А тут какой-то карго культ. Внешне сделали похоже, суть забыли.
Поймите, что каждый ЯП требует своего подхода. На Julia просто невозможен монолитный крупный проект. На C++ или Java - это нормальная практика. Сама идеология разработки на Julia - это функционально ограниченный пакет, внутри которого есть ограниченное количество модулей (не файлов). Вы собираете большой проект из автономных пакетов. И вы не сможете сделать пакет, если не разработали для него модульные тесты. А сама схема разбиения на пакеты - это функциональная декомпозиция. Если она выполнена по-человечески, то назначение пакета установить несложно.Для разработки в Julia есть VS Code. И то, что пошаговым отладчиком пользоваться неудобно (он просто очень медленный), не исключает возможность по-строчного запуска кода с визуализацией значений переменных. Но это не пошаговая отладка, а отладка по результатам вызова функций. По произвольному коду. И без пошагового отладчика, отладка в целом выполняется без каких-либо затруднений.
Хорошо. Как быть с интерактивностью? Джулия позиционируется как язык научных вычислений. Уже есть язык научных вычислений Матлаб. В Матлабе можно поставить точку останова, в командной строке провести эксперименты, увидеть результат, внести изменения в код. Такой подход очень продуктивен, при написании именно научного кода, не зря Матлаб и его клоны (Октав) пользуются такой популярностью. Как с этим у Джулии? Кстати я читал несколько лет назад, обсуждение разработчиков Джулии, по поводу отладчика, они писали, что из-за Джит компиляции, разработка полноценного отладчика обойдется в крупную сумму (чуть ли не миллион долларов, не помню уже точную сумму) поэтому написание отладчка не в приоритете. Видимо они понимают нужность, но из-за дефицита ресурсов другие задачи.
Если очень надо, точку останова в VS Code поставить можно. Но если кода много, будете долго ждать, пока туда попадёте. Но попадёте.При этом, всегда есть отладочная печать. Если в каком-то месте надо проверить результат произведения 2-х 5-ти мерных матриц, вам пошаговая отладка ну совершенно никак не поможет. По-любому будете для этого места писать какой-то дополнительный код, которые сделает возможным оценить результат. Как и в большинстве мест научного кода. Нет смысла проверять одну строку кода. Есть некоторый частный результат, который надо валидировать. Именно поэтому, для Julia пошаговый отладчик никогда и не был приоритетом.
Поэтому, нормальный режим отладки для Julia - пишется основной код, пишутся модульные тесты. Дальше, в VS Code, построчно проходим модульные тесты в активной сессии REPL, и смотрим результат. Если надо внести изменения, вносим. Попутно, вставляем отладочный вывод в основном коде. При загруженном Revise.jl, изменения в модулях подхватываются на лету.
В Julia 1.9 сейчас акцент на статическую компиляцию в рамках нового компилятора. В рамках него, перерабатывается и отладчик.
В целом ясно, но раздражает, что некая модель разработки навязывается. Например в ПИтоне, можно писать модульные тесты, можно не писать, можно писать в каком угодно стиле, можно проходить отладчиком, сколько угодно, благо их опенсорсных полным-полно и с хорошим функционалом.
Нельзя писать без модульных тестов. Именно их отсутствие и приводит к тому, что через некоторое время никто не знает как работает код и как, собственно, его надо было вызывать. На Julia тоже "можно" писать в каком угодно стиле с тестами или без, но такой код никому кроме автора точно не будет нужен. И проблемы поддержки тоже не будет.
https://pretalx.com/juliacon-2022/talk/JPYJS8/Про интерактивную работу в VS Code. Запись с последнего JuliaCon, месячной давности.
Даже по сравнению с Октавом, выглядит как поделка. Не говоря уже о Р-студии. Опять же, сначала у них была среда Джуно, на атоме, теперь перешли на ВСкод... Не серьезно как-то, метания.
С чем можно согласиться, так это с тем, что Julia Computing не уделяет должного внимания бантикам. Какой смысл сравнивать, например, Octave c Julia, если на Octave вы ничего высоконагруженного не напишите?
Октав не предназначен для чего-то высоко нагруженного. Его ниша это создание прототипов и образование.
В JupyterLab есть пошаговый отладчик, окно переменных в т.ч. для структур, стек вызова. Т.е. это уже почти IDE. А еще в нем есть одновременная мультикурсорная правка несколькими пользователями через web и вариант работы вообще без сервера - JupyterLite. Тоже с мультикурсорной правкой. Но все это пока только для Python.
> Большую часть времени программисту приходится не писать, а читать код.Не читай гавнакода. Если в коде невозможно разобраться без отладчика, то пользоваться им нельзя. Надо переписывать.
> как научному сотруднику еще приходится читать кучу статей и кода к ним, который писался отнюдь не профессиональными программистами
Читай статьи, а не код к ним. Я всегда так делаю. Читаешь статью, вникаешь в написанное, воспроизводишь своими руками. В код можно заглядывать иногда, но имея очень конкретные вопросы, которые почему-то не освещены в статье.
Этот код всё равно бесполезен для чего-либо. Он там скорее как пруф того, что авторы статьи проверили свои идеи практикой.
> жить без пошагового отладчика можно, но зачем?
Очень воспитательно. Я впервые столкнулся с необходимостью этого в лиспе, где отладчики типа есть, но там всё так через ж с пошаговостью, что проще без них.
Обучает писать код так, чтобы отлаживать его не нужно было бы. Да, отладочной печатью приходится пользоваться, тестами покрывать, но пошаговая отладка не нужна. Раньше я кщё дерево вызовов строил отладчиком, но сейчас у меня есть vscode, который всё то же делает статически.
> Не читай гавнакода. Если в коде невозможно разобраться без отладчика, то пользоваться им нельзя. > Надо переписывать.Хороший совет. Особенно можно рекомендовать тем, кто только устроился на новую работу. Прямо с порога заявить. Код ваш - дерьмо, читать его не буду, нужно все переписать, потому что сделано неправильно. Сразу коллектив и руководство будут уважать, поймут что новый программист силён.
> Прямо с порога заявить.Не, зачем же так. Видишь гнокод, ищешь другую работу. И молчишь о гнокоде здесь пока зарплату платят.
Альтернативно можно попытаться объяснить менеджменту во сколько человекочасов ежемесячно им обходится гнокод и его отладка. Но это вряд ли сработает: если бы они интересовались продуктивностью, они бы сами уже это выяснили бы.
Хотя в реалистичной ситуации менеджмент будет признавать косяки, и даже возможно предпринимать какие-то усилия по исправлению. И вот тут уже смотри сам, насколько тебе интересно в этом участвовать.
Каждый за время своей карьеры должен поработать с гнокодом, хотя бы для того, чтобы понимать что стоит за требованиями предъявляемыми к качественному коду. Но не работая с качественным кодом ты не сможешь усвоить урок. И никогда не научишься писать программы. Так что я б сказал, что полгода можно с гнокодом поработать, а потом надо срочно уходить, чтобы гнокод не превращался бы в привычку.
Для Джулии, помимо всего прочего, модульные тесты с полным покрытием являются частью тех. процесса. Без них не соберёшь бинарники.
Debugger.jl
Пару лет назад пробовал использовать. Произвел впечатление грубого прототипа. До GDB явно не дотягивает.
Логгирование, трассировка, юнит-тесты. Я даже когда на Жабе писал конкурентный код, то тоже не использовал отладчик. Нахер он нужен вообще? Тем более в Джулии, где легко можно понять, где ошибка, там одни структуры данных.
Звучит как что-то нереально крутое. Скорость разработки скриптовых языков и скорость + прямота нескриптовых. Почему это не ...популярнее?
Хотя выглядит что оно для расчётов.
Ему всего 4 года в проде
Джулию сильно ругают. Баг-репорты висят годами. И множество других проблем
А есть хоть какой-нибудь ЯП, про который нельзя сказать тоже самое?
По опросам на Stackoverflow, Julia один из самых любимых языков.