Опубликован релиз языка программирования Julia 1.11, сочетающего такие качества как высокая производительность, поддержка динамической типизации и встроенные средства для параллельного программирования. Синтаксис Julia близок к MATLAB с заимствованием некоторых элементов из Ruby и Lisp. Метод манипуляции строками напоминает Perl. Код проекта распространяется под лицензией MIT...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=62026
Хороший, годный язык.
Жаль только, что на RISC-V не хотят портировать.
Экзотика пока ещё RISC-V. Тем не менее, народ ковыряется - https://discourse.julialang.org/t/julia-installation-on-risc...
> Жаль только, что на RISC-V не хотят портировать.Потому что никто не будет делать научные расчёты на одноплатниках с производительностью четвёртого пня.
Так RISC-V в перспективе это ещё и суперкомпьютеры
Ох, коллега!
Давайте вы мне не будете рассказывать, чем я буду заниматься, а чем нет.
А то как-то неудобно выходит.
Да и на расте переписывать никто не спешит. Сразу видно - очередное нинужно эта ваша Julia.
Кто-нибудь знает почему на FreeBSD Julia не собирается из портов и как это исправить ?
Вообще-то вот инструкция - https://docs.julialang.org/en/v1/devdocs/build/freebsd/. Если не работает, имеет смысл открыть issue на гитхабе.
Довольно сложный язык много подводных камней и непоняток
Как язык Julia очень проста. Синтаксис за вечер можно освоить. Сложности могут быть с написанием макросов, но они начинающим не нужны. И есть очевидные сложности изучения новых библиотек.
Джулию не понимает чатгпт, поэтому сложна. И на курсах от скилбрейнс не преподают. Это чтобы её выучить надо книги читать, а не видео смотреть - вкатун такое не выучит.
Чатгпт понимает. Могут быть некоторые проблемы, если задача касается библиотек, где сильно меняли API, но в целом, работает. Причём, были даже наблюдения, что генерируемый на Julia код в целом правильнее, чем на Питоне (сказывается, что на Джулии студенты и школьники свои поделки на гитхаб не выкладывают).
Он даже питон не понимает и генерирует совершенно случайный булшит, который каким-то чудом может работать (хоть и не так, как предполагает бот). А вы тут хотите от него эзотерические языки.
https://discourse.julialang.org/t/julia-ranking-fairly-good-...
Ну хз, чувак, я регулярно генерирую вспомогательные скрипты в chatgpt и claude.
Периодически использую claude для генерации простых драйверов. Там это крайне удобно: создаешь проект, заливаешь в knowledge base datasheet и всякую сопутствующую инфу а-ля стиль кодирования и т.д. Даешь задачу оно генерит. Это как иметь виртуального джуна, но как и за реальным за ним надо проверять, что оно сделало. Но в целом каких-то радикальных промахов обычно не бывает.
Генеративные сети могут экономить время на тривиальщине, но ровно до тех пор, пока не окажется, что они его не экономят, а цена ошибки ощутимо возрастает (как и их количество). И если чатгпт хотя бы генерирует код, который в теории как-то работает (чего может даже оказаться достаточно, хотя обычно надо несколько раз указать на проблемы), то клауде генерирует какую-то дичь, надёрганную непонятно как и откуда, которая выглядит замечательно (по сравнению с тем же чатгпт), но содержит невообразимое количество ошибок, которые ты ещё долго бкдешь искать. Ой, даже не начинай, чувак.
Обычный матлабообразный фотраносодержащий язык. Все непонятки возникают если ты начинаешь мыслить как программист, а не как инженер или учёный.
В принципе, хороший язык с достойно организованной ориентацией на научные вычисления. Дай Дарвин ему ресурсов для развития. Но сам нашёл лучшую замену. Язык, компилируемый в бинарный код, работающий без всяких прослоек. Рекламировать не буду.
Асемблер?
C
да вы интриган! И я заинтригован.
Rust не считается за замену. Он не предназначен для научных рассчетов.
Zig?
Если пригоден для научных вычислений, компилируемый сразу в машинный код... С++ !
FORTRAN же!
> Язык, компилируемый в бинарный код, работающий без всяких прослоек. Рекламировать не буду.И как это вы делаете? (Пусть хоть чуть чуть посложнее чем Хелоу Ворлд)
Ну чтоб вот правда, взяла и готовый выполняемый бинарник чтоб сделала, который можно выполнить на другой машине где нет Юлии Петровны.
Вот за это мне язык и нравится )
(Аноним 7)
> Вот за это мне язык и нравится )
> (Аноним 7)Я не совсем понял, нравится то, что язык хвалится что комилит нативные бинарники под мульти платформы, но в реальности нет тулчэйна по сборке и это или очень большая головная боль чтоб просто компильнуть (привет StaticCompiler, StaticTool) или чаще - это просто не возможно, и это нравится ?
Я тоже на естественный отбор надеюсь, но в другом смысле.Julia создали как язык, который решит "проблему двух языков" (прототип приходится делать на одном удобном языке типа питона, релиз на другом быстром типа C++; неудобно, поэтому делаем язык, удобный как питон и быстрый как C++).
В итоге получилось, что Julia не прыгает выше питоновских JIT'ов и математических либ и назначение языка замяли. Зачем он теперь нужен? Просто так.
В сообществе пользуются уникальным термином "time to first plot" (время до первого графика), потому что запуск тормозит. Статические бинарники занимали сотни мегабайт, память не экономит, часть решений продиктована NIH-синдромом (конкатенация строк через оператор умножения).
> конкатенация строк через оператор умноженияОператор + тоже некорректно использовать несмотря на популярность этого в мейнстримных языках.
str1 + str2 - узнаваемость, правило наименьшего удивления.
[str1 str2] - математичность, преемственность с MATLAB/Octave
str1 * str2 - "видали как я могу, а!? да я три бутылки залпом могу"
А str1.str2 забыли
Как уже заметили выше, забыли str1.str2 (Perl).
Добавлю str1 || str2 (PL/SQL).
Добавлю тогда уж до кучи Visual Basic: Str1 & Str2 (кстати тоже логичный как и Str1 + Str2)
Это обычный оператор стандартного SQLУмничанье не проканало.
Во-первых, для конкатенации есть метод string("abc", "def"), который ещё и типы умеет преобразовывать. А во-вторых, объяснение почему нельзя использовать * как операцию склейки приводится тут - https://docs.julialang.org/en/v1/manual/strings/#man-concate...Причина в том, что с математической точки зрения операция + должна гарантировать коммутативность. То есть 1 + 2 == 2 + 1. Но со строками это не проходит. А вот операция матричного умножения не является коммутативной по определению. Поэтому её и взяли для конкатенации.
> с математической точки зрения операция + должна гарантировать коммутативность
> In mathematics, + usually denotes a commutative operation (#man-concatenation).
> должна гарантировать
> usually denotes...
Её взяли из-за NIH-синдрома. Так-то и операция умножения над векторами должна умножать вектора.
'abc' * transpose('def') == 29696 % MATLAB
Да и если избегать +, в языках программирования для конкатенации уже использовали 5 других операторов:
~ <> ++ . ..Julia захотела отличиться от всех этих языков (Wolfram Mathematica, Haskell, D, Lua, Perl...).
Хм, а операция умножения разве не должна быть коммутативной?
> Хм, а операция умножения разве не должна быть коммутативной?Матричное умножение? Нет, не должна. Матричное сложение может быть коммутативным.
> А вот операция матричного умножения не является коммутативной по определению. Поэтому её и взяли для конкатенации.Причём здесь матрицы? Речь же о строках. По аналогии? Ну тогда так и говорить надо.
>>прототип приходится делать на одном удобном языке типа питона, релиз на другом быстром типа C++; неудобноКак это? Наоборот же, очень удобно сначала накидал тяп-ляп быстренько, чтоб работало, а потом пишешь нормально. Так всегда делается, даже если всё на одном языке. Тем более при переписывании одновременно производится и аудит и рефакторинг в одном флаконе.
Если язык прототипа отличается от целевого и не используется автоматическая трансляция кода, это означает, что оба раза будет тяп-ляп. И после переписывания на другой язык придётся отдельно делать рефакторинг и переписывание уже под прод. Джулийный подход с написанием прототипа на ней же всегда будет дешевле, чем связка питон + что-то ещё. Не говоря уже о том, что квалификация одного универсального джулийного программиста будет выше, чем питониста + чеготоещениста. Он и задачу понимать будет, и оптимизацию решения.
Если тебе удобно так - ну, ок, не вопрос, пожалуйста. Кому-то (в т.ч. мне) удобнее сразу на целевом языке - не надо тратить время на изучение отдельного языка для этапа тяпляпинга, не надо насиловать мозги переключением с одного языка на другой, не надо переделывать внутреннюю логику работы программы под другой язык.
> прототип на одном удобном языке типа питонаЧасто прототипы не переписывают, а живут с ними в мучениях.
Поэтому и нужны языки, которые и удобные, и быстрые, и гибкие. C#, go, rust.
Питон вообще не поддается рефакторингу. Чуть что, - рантайм исключение.
Не повторяйте ошибки
> Питон вообще не поддается рефакторингуЭто из чего следует?
Из практики. Из отсутствия культуры.У нас была команда пэйфон девелоперов. Так они просто писали код, затем при первой проблеме выкидывали его и переписывали с нуля.
>Но сам нашёл лучшую замену. Язык, компилируемый в бинарный код, работающий без всяких прослоек. Рекламировать не буду.Fortran？
так Фортран быстрее Си на математических вычислениях и сами математики прекрасно это знают, и задел библиотек у них в нем огромный. Поэтому спроса на новинку не будет в принципе.
> задел библиотеккривых. Не стал бы доверять - пишем только сами.
> кривыхЛично провёл аудит?
> пишем только сами.Лол. Успехов.
Никто пока не назвал :) Уже становится забавным. Zig — тепло, но не он.Ребята, ещё попытка. Компилируемый в нативный код на большинстве известных платформ и ОС. Строгая типизация. Простой как топор синтаксис. Чрезвычайно легко реализовывать научные вычисления, хотя предназначен скорее для системного программирования. Мощная система макросов. Входит в десятку языков, генерирующих наиболее быстрый код. Как уже освоивший этот язык, добавлю пару недостатков: не самая развёрнутая документация. Сравнительно медленная компиляция.
Подпись: Аноним 7 )
this is Nim
Бинго! )
Бинго - это Mojo. Хотя и Python 3.15 обещает быть компилируемым
Ну, явно не си, у сей со всем перечисленным всё в порядке. Видимо, плюсы.
Это подумал Я:
V ?
Z ?
Hare ?
Carbon ?
Elena ?Это подумал Claude 3.5 Sonnet:
Я читаю форум opennet.ru и вижу что там в комментариях загадали загадку, найди ответ, какой из языков программирования может соответствовать описанным признакам!
Признаки:
> В принципе, хороший язык с достойно организованной ориентацией на научные вычисления. Дай Бог ему ресурсов для развития. Но сам нашёл лучшую замену. Язык, компилируемый в бинарный код, работающий без всяких прослоек. Рекламировать не буду.
> Никто пока не назвал :) Уже становится забавным. Zig — тепло, но не он.Ребята, ещё попытка. Компилируемый в нативный код на большинстве известных платформ и ОС. Строгая типизация. Простой как топор синтаксис. Чрезвычайно легко реализовывать научные вычисления, хотя предназначен скорее для системного программирования. Мощная система макросов. Входит в десятку языков, генерирующих наиболее быстрый код. Как уже освоивший этот язык, добавлю пару недостатков: не самая развёрнутая документация. Сравнительно медленная компиляция.
---
не - Zig, не - Rust, не - C++, не - Julia, не - Fortran
---
Перечисли все остающиеся варианты!Давайте проанализируем указанные характеристики и подумаем о возможных вариантах:
1. Компилируется в нативный код
2. Поддерживает множество платформ и ОС
3. Строгая типизация
4. Простой синтаксис
5. Хорош для научных вычислений
6. Предназначен для системного программирования
7. Мощная система макросов
8. Быстрый сгенерированный код (Входит в топ-10 по скорости выполнения)
9. Не самая развёрнутая документация
10. Сравнительно медленная компиляцияУчитывая эти характеристики и исключённые варианты, возможные кандидаты:
1. D (D language)
2. Ada
3. Crystal
4. Nim
5. OCaml
6. Pascal (Free Pascal)
7. Mercury
8. Go (хотя его компиляция обычно быстрая)
9. F#Из этих вариантов, наиболее вероятными кандидатами я бы назвал:
1. D - очень хорошо подходит под все характеристики
2. Nim - также соответствует многим указанным признакам
3. Ada - используется в научных вычислениях и системном программированииЕсли нужно выбрать наиболее вероятный вариант, я бы предположил, что это язык D, так как он идеально соответствует всем перечисленным характеристикам, включая медленную компиляцию и мощную систему макросов.
Nim также является вероятным кандидатом, но его компиляция обычно быстрее, чем у D.
Твой бот бракованный. У D рантайм, для системного программирования не очень. Согласно чатгпт, существуют определённые способы исключения GC, но, что-то сомнительно, видимо, это задача уровня написать ОС на GO. Nim сомнительно.
Што это за Claude?
Спросил у ChatGPT: Что это за язык программирования? Компилируемый в нативный код на большинстве известных платформ и ОС. Строгая типизация. Простой как топор синтаксис. Чрезвычайно легко реализовывать научные вычисления, хотя предназначен скорее для системного программирования. Мощная система макросов. Входит в десятку языков, генерирующих наиболее быстрый код. Недостаки: не самая развёрнутая документация. Сравнительно медленная компиляция.ОТВЕТ:
Судя по описанию, речь идёт о языке программирования Nim. Вот как его характеристики совпадают с вашим описанием:
Компилируемый в нативный код: Nim компилируется в C, C++, JavaScript, и его можно легко скомпилировать в нативный код для большинства платформ.
Строгая типизация: Nim поддерживает строгую статическую типизацию.
Простой синтаксис: Nim известен своим лаконичным и простым синтаксисом, который легко освоить.
Научные вычисления и системное программирование: Nim позволяет легко работать с вычислениями благодаря своей производительности, хотя он более направлен на системное программирование.
Мощная система макросов: В Nim используется продвинутая система макросов, что даёт возможность писать гибкие программы с расширенными возможностями метапрограммирования.
Быстрый код: Nim часто входит в списки языков, генерирующих высокопроизводительный код.
Недостатки: Некоторая документация по языку может быть недостаточно развёрнутой, а компиляция не самая быстрая по сравнению с более зрелыми языками.Этот язык хорошо известен в сообществе системных разработчиков и в научной среде.
Common Lisp, реализация SBCL.
Перешёл на него с убогих и тормознутых R и Python.
А как же NumPy и Numba?
Слишком коряво по синтаксису. Даже близко нет лаконичности Джулии. И чрезмерный расход вычислительных ресурсов. Несерьёзно.
Согласен с Вашими определениями. Но перешел на C++.
У-у-ух, не нужны нам эти ваши питоны и джулии, нам подавай только ANSI C!
А , что будешь делать когда python mako затребует? Есть что то чем заменить ?
Julia такое же дурацкое название как и Go. Хуже не придумаешь, гуглить что-то себе дороже. Для go уже давно синонимом стало "golang". А здесь? "Julialala"?
Juliabla
Нормальные названия, всяко лучше, чем буквы из алфавита брать.
julialang.org - как бы намекает...
а C как деды гуглили?)
Дедам это было не нужно, т.к. руководство по Си шло вместо мануала к игре под названием UNIX OS.
C/C++ есть везде помимо UNIX. В этом достоинство - компилируется (адекватным компилятором) в любой системе. Недавно ради смеха взял и сделал тот же код вообще в экзотике.
Изучая эти руководства максимум можно было достичь уррвня джуна, ибо всё описано было поверхностно. Например арифметика указателей максимум простой пример обмена значениями двух переменных. Чтоб научиться серъезно нужны были совсем другие книжки.
у меня был такой свиток, распечатанный на барабанном принтере
Трое создателей языка во время очередной попойки пошли к Джулии. на утро, чтобы она не подавала в суд, сказали что назовут язык в честь неё. Ведь ночка была та ещё.
> StyledStringsЗачем это на практике?
Для разукрашивания текста, выводимого в консоль. И для формирования отчётов. Идея в том, что к частям строки можно навесить атрибуты отображения, для которых прописать стиль. То есть, формируем строку в вычислительной части программы, навешиваем стили на кусочки, из которых её формируем, а потом кидаем на отображение.
> отчетыИ чем это лучше готовых шаблонов?
Поскольку оно только что появилось, очевидно, никто реального опыта использования не имеет. Чисто в теории разница с шаблонами в том, что в одном случае код надо кусочками компоновать по частям шаблона (в зависимости от того чем шаблон делаем), во втором - формируем линейную строку и полностью развязываем отображение от кода. Да ещё и можем легко нанизывать разные схемы отображения на одну и ту же строку без перекомпоновки кода.
> основан на наработках проекта LLVMИ это прекрасно.
Тому що швидчее закопают
О нет. Здесь же есть вот эти end как в Pascal.
Тогда тем более годно
Которые как и в матлабе можно тупо не писать.
>Высокая производительностьjulia - это скриптота. Поэтому о высокой производительности можно забыть. Чтобы собрать статический бинарник, придется запихивать целый интерпретатор.
Перед тем как писать комментарии, стоит хотя бы поверхностно ознакомиться с предметной областью.... Ну или почитать как работает компилятор Julia. Тесты же производительности присутствуют на главной странице сайта языка.
Мало ли, что там написано. Вон даже чатгпт утверждает, что жулия язык с динамической типизацией и рантаймом, сиречь питон, и других вариантов использования не подразумевает (т.е. нельзя как жаву скомпилировать без вм при отказе от части функциональности).
> Мало ли, что там написано.А код посмотреть на гитхабе и проверить слабо?
Естественно, синтетика позволяет показывать красивые графики для недалёких. Это конкурент жаваскрипта и никому не нужен ещё один жаваскрипт.
Я-то знаком с этой скриптотой. Даже простой джулиевский хеллоуворлд выжирает 250 мегабайт, потому что интерпретатор запускается.
Ок. Не занимайтесь больше программированием.
`occursin` — наверное смешно было, когда имя функции придумывали ('случись грех'). А у меня сразу же стойкое мнение - "разрабы - придурки".
> А у меня сразу же стойкое мнение - "разрабы - придурки".Нет, это всего лишь незнание английского языка в части использования глаголов с местоимением (первый аргумент) в треьем лице.
>поддержка динамической типизацииНо зачем? Из-за динамической типизации куча проблем вылазит в рантайме.
>Высокая производительность: одной из ключевых целей проекта является достижение производительности близкой к программам на языке Си. Компилятор Julia основан на наработках проекта LLVM и генерирует эффективный нативный машинный код для многих целевых платформ;Управления памятью в нём нет, из-за динамической типизации данные всегда придётся оборачивать и тратить дополнительное время на проверки во время исполнения.
>> поддержка динамической типизации
> Но зачем? Из-за динамической типизации куча проблем вылазит в рантайме.Динамическая типизация позволяет использовать язык в блокнотике и не думать об избыточном указании типов, когда они и так могут быть автоматически выведены.
>> Управления памятью в нём нет
чего нет?..... А при чём тут оно и динамическая типизация?
У Джулии жесткая типизация на уровне кода. Невозможно исполнение кода с невыведенным типом. Все методы на уровне кодогенератора имеют конкретные типы аргументов. Но если программист сделает типонестабильные методы, которые возвращают каждый раз значение нового типа, то да, это заставит Джулию каждый раз создавать комплект методов под новый встретившийся тип.
https://docs.julialang.org/en/v1/devdocs/eval/
PS: при должном умении любой ЯП можно поставить на колени. Но не каждый из ЯП с коленей способен подняться даже при очень прямых руках. Некоторые так и остаются ползать.
>Динамическая типизация позволяет использовать язык в блокнотике и не думать об избыточном указании типов, когда они и так могут быть автоматически выведены.С учётом Хиндли-Милнера, которые используется во многих функциональных языках, например Ocaml и Haskell, их тоже можно использовать в блокноте.
>чего нет?..... А при чём тут оно и динамическая типизация?Возможности управления выделением памяти. Например, сделать кастомный алокатор.
>Но если программист сделает типонестабильные методы, которые возвращают каждый раз значение нового типаПервый же json, и джулия окажется в затруднении. Хотя в плане типа данных - json это один из самых простых вариантов.
>У Джулии жесткая типизация на уровне кодаЭто называется сильная типизация, но никак не мешает языку падать с рантайм ошибками. Например, внезапно пришёл null
> Это называется сильная типизация, но никак не мешает языку падать с рантайм ошибками. Например, внезапно пришёл nullУ вас всё замешано в кучу. В Julia декларируется динамическая типизация, и это механизм, который доступен программисту, позволяя менять значения переменных в пределах заявленных для них типов (или любой потомок Any, если не заявлено). А то, что на этапе выполнения она по факту становится строго типизированной, это никак не отменяет динамическую типизацию для программиста. "Динамическая типизация" - это признак синтаксиса языка, а не этапа выполнения программы.
> Первый же json, и джулия окажется в затруднении. Хотя в плане типа данных - json это один из самых простых вариантов.JSON - это не тип данных, а формат обмена данными. Код, который его разбирает, может как быть строго типизицированным, так и не быть. Разобрать его можно как в иерархию объектов типа Dict, так и в специально созданные структуры с предопределённым набором полей. И даже eval может использовать в Typescript или Javascript, поскольку именно подмножеством языка Javascript формат JSON и является. Но это совершенно никакого отношения не имеет к Julia. Как и разбор ProtoBuf и пр. обменных форматов. Парсеры JSON для Julia доступны в открытом коде.
> Возможности управления выделением памяти. Например, сделать кастомный алокатор.
https://docs.julialang.org/en/v1/base/libc/#Base.Libc.malloc
https://docs.julialang.org/en/v1/base/arrays/#Core.GenericMe...
https://github.com/JuliaSIMD/ManualMemory.jl+ новый тип Memory, поверх которого переписана реализация многомерного массива Array.
>"Динамическая типизация" - это признак синтаксиса языка, а не этапа выполнения программы.Наоборот. Динамеческая - во премя выполнения, статическая - во время компиляции. А с точки зрения синтаксиса - явная/неявная.
>JSON - это не тип данных, а формат обмена даннымиДа, но формат диктует определённые ограничения на типы. В каких-то языках, например Ocaml, json парсится в определённый тип, и особенности формата, например ключи в виде строк явно отображены в самом типе данных. В других языках, система типов недостаточно выразительна, чтобы описать все ограничения в виде типа, и он будет рабираться в нетипизированный объект.
> Наоборот. Динамеческая - во премя выполнения, статическая - во время компиляции.Если хотите, считайте, что в Джулии динамической типизации нет. Поскольку после компиляции методов с выведенными конкретными типами, никаких накладных расходов на их выполнение нет.
> Да, но формат диктует определённые ограничения на типы.
https://quinnj.github.io/JSON3.jl/stable/#Basic-reading-and-...
https://quinnj.github.io/JSON3.jl/stable/#Read-JSON-into-a-type
https://quinnj.github.io/JSON3.jl/stable/#Parametric-typesразбор в Dict, разбор в структуру, разбор с возможность валидации данных...
>Если хотите, считайте, что в Джулии динамической типизации нетФакты не зависят от желания
>Поскольку после компиляции методов с выведенными конкретными типами, никаких накладных расходов на их выполнение нетРасходы есть на компиляцию. И в случае изменения типа данных на перекомпиляцию существующего кода. Например, есть функция, которая иногда по недосмотру возвращает string вместо date.
>разбор в Dict, разбор в структуру, разбор с возможность валидации данных...Вы меня не поняли. В системе типов можно описать, что в качестве ключа может быть только строка, а в качестве значения не может быть, например даты. И если вы работаете с данными без схемы, например как в утилите jq, то джулия вам ничем не поможет
> Расходы есть на компиляциюДля этого у Джулии есть прекомпиляция и запуск кода модульных тестов. И бинарник делается таким же образом на основании прогона программы по набору данных.
> Например, есть функция, которая иногда по недосмотру возвращает string вместо date.
Такие вещи случайно не возникают. Во-первых есть инструменты для анализа кода на типонестабильность. Во-вторых можно жестко прописать тип возвращаемых значений для каждого метода. Тогда компилятор выдаст ошибку сразу.
Возможно, в сабже что-то быстро.
Но это не точно ¯\_(ツ)_/¯