Представлен выпуск Rakudo 2022.12, компилятора для языка программирования Raku (бывший Perl 6). Проект был переименован из Perl 6 так как не стал продолжением Perl 5, как ожидалось изначально, а превратился в отдельный язык программирования, не совместимый с Perl 5 на уровне исходных текстов и развиваемый отдельным сообществом разработчиков. Компилятор поддерживает варианты языка Raku, описанные в спецификациях 6.c, 6.d (по умолчанию). Одновременно доступен выпуск виртуальной машины MoarVM 2022.12, формирующей среду для запуска скомпилированного в Rakudo байт-кода. В Rakudo компиляция также поддерживается для JVM и некоторых виртуальных машин для JavaScript...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=58265
Но зачем? Есть posix shell для кроссплатформенных скриптов, есть баш, если posix shell слишком ограничивает, есть питон, если баш-скрипт стал больше ста строк, и есть раст, если в питоне уперлись в тормоза. Зачем здесь нужен сабж, а тем более перл - не ясно.
А что, Rust уже и для скриптования годится?
Box everywhere, clone everything. Получается неплохая замена тому же пистону.
Нет.
Если уже написано, то выбора нет. Например, GLPI.
но написано-то на легаси-перле, а не на раке. Легаси-перл — это тавтология, любой проект на перле — легаси. Не потому что "вышел новый улучшенный перл в виде рака", а потому что перл устарел как концепт. Даже posix shell актуальнее перла. Рак — это просто попытка и дальше развивать заведомо устаревший концепт, отсюда вопрос — зачем он нужен?
Полностью наоборот. Raku -- совершенно новый язык, при этом максимально продуманный. А не как go или плюсы или <твой_язык>, в которых новые фичи прикручиваются синей изолентой.
Насчёт максимально продуманный согласен.Вот только этот максимально продуманный синтаксис и концепции наркомански упороты по сравнению с наркоманским perl5 и упоротым растом.
Например
@a >>+>> 1
Почему упороты? Есть метаоператоры, которые можно применять с любыми обычными операторами. И это логичнее и проще, чем выучить 100500 каких-нибудь .ListAdd(1) на каждый чих. А если не нравятся метаоператоры, никто не мешает написать `@a.map(* + 1)` или вовсе for `@a { $_ += 1 }`.
Кавычку перепутал, конечно `for @a { $_ += 1 }`.
> Кавычку перепуталЭто очень показательно.
То, что ты просто троль -- это понятно. Мне интересно, кто те 6 человек, которые плюсанули этот коммент.
Listadd() понятно всегда, везде, любому, а если даже по слову непонятно, можно спросить гугл, и немедленно разобраться, что тут происходит.Но вот это `@a.map(* + 1)` или это `for @a { $_ += 1 }` - упоротый брейнфак.
Я бы понял, если бы это был С или Ассемблер, и за этот брейнсекс при чтении кода получались плюшки в виде ускорения исполнения в 100500 раз и уменьшения размеров исполняемых файлов в 100500 раз.
Но оно ровно так же (плюс минус) тормозит, как питон или джава. В чём смысл этой наркомании и брейнфака?
Условный Listadd нужно знать наизусть. Причём в каждом языке, в котором есть функции такого типа. А те конструкции, которые я привёл -- они пусть и выглядят поначалу страшно, зато их не нужно знать. Они вытекают из логики языка. Выучить возможности функции (или метода) map -- совсем не сложно. А значение переменной $_ человек узнаёт, наверное, уже через 10 минут изучения языка. И забыть это невозможно, потому что эта переменная применяется буквально везде. С другой стороны, пресловутый Listadd нужно знать, либо мучительно вспоминать: может это ListAdd? Или list_add? Или вообще arrayAdd?
У меня ровно противоположное мнение.И вот почему. Listadd - это нормально человеческий язык, и не нужно никакой другой особенной логики выучивать и в ней потом упарываться.
А эти ваши >> % $* $\ $_ трудно вспомнить через месяц, если perl или этот ваш раку в руки не брал.
И снова повторю. Я бы понял, что все эти извращения давали ассемблерную скорострельность. Есть смысл морщить лобные доли, заталкивая туда это наркоманство. Но я лично не вижу никакого выигрыша для работы. А для развлечения я лучше с котанами в евреван на моцылях сгоняю.
Написать никто не мешает, а читать написанное другими?
> Написать никто не мешает, а читать написанное другими?Это правда, конструкции с метаоператорами сложнее для чтения. С другой стороны, такие конструкции очень ёмкие по смыслу, что компенсирует сложность чтения. В любом случае, для тех, кому важно много читать код (большие компании разработчиков, постоянно меняющийся код), существует кодстайл. И без него даже на обычном языке можно наворотить нечитаемую бяку.
что не упорото?похожую конструкцию наверное можно и на С скомпилить.
вообще, не пишите упорото да не упоритесь.
На APL посмотри https://git.pashev.ru/gcd/tree/gcd.apl
apl --eval "∨/⍎¨(↑⍸{'--'≡⍵}¨a)↓a←⎕ARG" -- 11 22 121
По продуманности Go самый продуманный язык из всех новых языков. Если ты считаешь что продуманность это запихать все возможные концепции в язык как в р**** то ты глубоко и сильно заблуждаешься.
Go это тот язык, на котором я (для обучения) написал калькулятор, проблевался от системы типов, и больше не хочу ничего делать на этом языке. Сразу видно, что это наколенная поделка от корпорастов для вебмакак, чтобы они могли компилировать свою писанину. Мне повезло сразу понять суть этого языка. Но те люди, которым не столь повезло, могут оформить ещё много претензий к этому недоязыку.
Ну конечно ты переходя со своего пхп будешь ловить батхерд от любой системы типов. Но Go это язык на котором действительно можно делать продукты в отлчии от всяких Хаскелей, р***** и других брейнфаков.
Я писал на C#, C++, Raku. Вот там -- действительно система типов. А в Go -- какое-то недоразумение. Проще сказать, в нём просто нет системы типов. Потому что это не система, а мешанина непонятно чего. В большой степени именно потому, что язык писался для тех же ПХПшников, у которых вследствие профессиональной деградации туго со строгостью мышления.
Что ты несешь в Go даже дженериков не было последнее время и это было правильно. А потом видимо пришли такие как ты из добавили.
жырноаноны не нужны.
Perl мёртв. Жаль, но факт. Не плох, просто не выдержал конкуренции. Сообщество в самый ответстенный момент распылило кучу сил на "революционный" perl6 вместо развития perl5
Да.
На этом, как и на Расте ничего дельного не написано и написано не будет. Распил бюджетов.
На Хаскеле и Брейнфаке тоже не продуктов. Это не языки это искусство. Р*** это конечно же не искусство это просто порнография. Поэтому и привлекает столько недалёких фанатов.
>На Хаскеле и Брейнфаке тоже не продуктовxmonad
> На Хаскеле тоже нет продуктовPandoc. Но его можно было на чём угодно написать. Взяли хаскель, ну штош... ¯\_(ツ)_/¯
> На Хаскеле и Брейнфаке тоже не продуктовshellcheck
От названия ожидаешь что это как-то связано с R, а оно - всего лишь связано с Rakuвником
Причём, вроде бы перл продолжает пилиться. Зачем ещё один перл но переименованный
Если бы смузихлёб удосужился прочитать новость, то не задавал бы тупых вопросов.
несмузихлёб вроде тебя может объяснить, почему есть перл 5, раку - который переименованный не выпущенный перл 6, а ещё - есть перл 7 который перл 7 а не раку 2 но при этом реальной обратной совместимости к перлу 5 у него тоже нет
а какая есть? нереальная?
Исторический казус. Это то же самое, что выяснять, почему в венде системный диск -- это "C:", а не "A:". Или почему есть языки С++ и C#, которые вообще не похожи друг на друга и оба не скомпилируют код C. Просто так вышло исторически.P.S. Вы ещё спросите про opensuse: почему после версии 13 идёт 42, а после 42 -- 15? :D
для анона. "А" всегда было именованием флоппи диска. как первого с чего запускались и устанавливались все дос и виндовс. про "В" ничего не скажу, сам не интересовался. и осталась для жесткого диска буква "С". вот и весь секрет. как ты выразился исторически вышло.))
Ну вот я и говорю, что с именованием перла и раку так же вышло. Когда-то что-то как-то было, а теперь имеем что имеем.
Ура, любимый язык стал ещё лучше!
Отлично, молодцы.
>Raku (бывший Perl 6)Если в результате ребрендинга нужно постоянно упоминать старое название, то это хреновый ребрендинг.
Вопрос к новостепейсателю. ИМХО упоминать это не нужно совершенно. Если необходимо пояснение, то гораздо более ценным было бы что-то вроде "язык, сохранивший базовые принципы, устоявшиеся среди Perl-разработчиков, но изначально реализуемый с учётом новых технологий"
Я понимаю желание энтузиастов продолжить проект, им по кайфу, но не понимаю, какой в этом практический смысл?Что даст раку относительно питона или джавы? Библиотек нет, информации нет, специалистов нет, нет и устойчивой платформы, как например в perl5.
Я уже не говорю про совершенно наркоманский синтаксис, по сравнению с которым раст является эталоном читабельности.
1. единство в многообразии
2. когда начинался пыфон и джава, то тоже было: Библиотек нет, информации нет, специалистов нет, нет и устойчивой платформыВам карман не жмет? Тогда не задавате вопросов, а лучше радуйтесь.
Кстати о преимуществах. Относительно пыфона пишут, что вроде бы работает шустрее. Ну а относительно джавы - пишется быстрее.
Я бы добавил, что относительно питона, важное достоинство раку -- это стабильность языка. Любые библиотеки, сколь угодно старые, на раку у меня без проблем работают. Чего не скажешь о питоне: даже актуальные питонопроекты порой не работают из-за зоопарка зависимостей.
Это стабильность, а бедность. Пока этих библиотек чуть более десятка, то оно всё более менее стабильно.Разростётся (если) и стабильность кончится.
Возможно. Поживём, увидим. Но не надо путать понятия. Я не говорил, что библиотеки стабильные. Я говорил -- стабильный язык, то есть синтаксис. Благодаря этому старые библиотеки без проблем работают.И хотя язык меняется (вот, версию 6.e выкатывают), это не влияет на стабильность, потому что более старые версии языка поддерживаются компилятором, их никто выкидывать не собирается.
> когда начинался пыфон и джава, то тоже было: Библиотек нет, информации нет, специалистов нет, нет и устойчивой платформыРаку 22 года так-то. И до сих пор ничего нет.
> Относительно пыфона пишут, что вроде бы работает шустрее. Ну а относительно джавы - пишется быстрее.
Я сомневаюсь и в том, и в этом. Потому что виртуальная машина тормозит, и потому что нет библиотек. Есть библиотека, тяп-ляп и готово.
Мне на эту упоротую маргинальщину похрен, когда-то писал на perl, и уже тогда бомбило от упоротости синтаксиса, глянул на дальнейшее развитие перла под названием раку и выпал в осадок совсем.
"Относительно пыфона пишут, что вроде бы работает шустрее."
Для начала предыстория. Я много лет писал на перл и, наверное, до сих пор люблю этот язык.
Давным давно, когда деревья были большими, я шел по Савеловскому рынку и увидел тоненькую книжку "Perl 6". Полистал, там было написано, что решено выделить виртуальную машину и вообще будет все по новому и много лучше и быстрее. Я обрадовался, но книжку не купил. И стал ждать. Долго и упорно писали один компилятор, другой не прошло и 20 лет и вот наконец родили хоть как-то работающий.
А теперь про быстродействие:
my $s=0;
my $x=0;
my $y=30000000;
$s+=$x++ while $x < 30000000;
say "$s\n";
Как думаете как быстро это будет работать? В 11 раз медленнее такого же кода на perl5, почти в 5 раз медленнее python 3.6.
Может типы нужно поставить? Может ТОЛЬКО не Int. C Int будет работать еще медленнее!!
Если поставить int то да, обгонит и perl5 и python, но будет в 4 раза медленнее pypy.
Скомпилировать программу в отдельный файл с байт кодом до сих пор не возможно.
Изучать упоротый (даже для знающего perl5) синтаксис из любви к искусству?
Мне по кайфу писать на raku. Да, в питоне больше библиотек. Но от питона нет кайфа, он неудобный. А раку удобный и продуманный. Наибольший кайф я получал, когда решая какую-нибудь задачу, писал код наобум: "а заработает ли так?" И оно работало! Я считаю это высшей степенью логичности. Когда даже без чтения документации понятно, как нужно написать.P.S. Понятно, что кому нужно "снап-снап и в продакшон", язык пока не подойдёт. Количество библиотек -- главная причина.
Попробуй лучше Руби у него и библиотеки есть.
Ну как сказать библиотеки, скажем так часть библиотек мягко говоря сомнительного качества где автор узнал что в рубях есть метапрограммирование и решил его по практиковать везде.
А таких библиотек очень много, часть из них заброшена, но типо они есть.
> Наибольший кайф я получал, когда решая какую-нибудь задачу, писал код наобум: "а заработает ли так?"Вот я и говорю, наркомания )))
> Понятно, что кому нужно "снап-снап и в продакшон", язык пока не подойдёт. Количество библиотек -- главная причина.
Главная причина -- люто, бешено упоротый наркоманский нечитаемый синтаксис. Кому надо, чтобы работало, они ищут в языке программирования читабельности и однозначности, а не синтаксических лингво-извращений.
Впрочем, возможно, что у меня лапки и я не могу превзойти всю блистательность раку.
Не говоря уже о:
"Одна из целей живого и красочного дизайна логотипа заключалась в том, чтобы препятствовать мизогинии в сообществе и дать возможность людям с «мужскими убеждениями» показать свою чувствительную сторону"Сразу хочется держаться подальше от повесточки.
От логотипа меня самого коробит.А читабельность -- она у каждого своя. Для меня вот, код на C нечитаемый. Потому что и ключевые слова, и функции, и переменные выглядят одинаково. Да, есть подсветка редактора, но это внешний костыль для языка, изначально плохочитаемого. Это моё мнение, никому не навязываю.
Мне Perl казался слишком свободным языком чтобы быть компилируемым. Реально компилятор?
Про виртуальную машину, наверное, прочитал? а понял?Visual Basic тоже был свободный язык программирования, где можно было писать программы без типов. Компилировался как в p-код, так и в исполняемый код на раз-два. Исполнялся на 10-15% медленнее программ на Visual C++.
Ой. Новость не читал, сразу отвечал!
Ну может просто нет типов - нормально, а вот какой-нибудь tcl будет сложно скомпилировать.
А кстати почему так медленно? Только из-за типов? Очень странно.
Если вопрос про VB, то VB - это кроме языка программирования была и оболчка над технологией OLE(COM,ActiveX), которая сама по себе не быстрая. А при использовании бестиповых переменных применяли тяжеленную структуру VARIANT. Эти накладные расходы и не самый совершенный компилятор (это же не системный язык, а бизнес-язык).Вроде есть другие варианты Basic, типа Pure Basic и другие, котрые тоже комплируются в исполняемый код только без обвеса из OLE. Но я не знаю про их производительность. Да и знать уже не надо, когда у меня есть для хобби ADA :) - я для изучения языков программирования купил эту книгу первой в каком-то мохнатом году. Но из-за полного незнания на тот момент, а потом отсуствия доступного компилятора, я так и не познакомился с ним. Вот только сейчас получилось, когда команда ADA разработало вменяумую IDE.
Raku кстати тоже может стать вариантом языка для хобби не больше.
Ну как-то скобочки ближе и проще однако, а там вообще хер поймешь где код, а где не_код (данные). Хотя помню, что строка не_кода могла в итоге оказаться им))
Тогда пиши на лиспе.
Так там код и есть данные лиспа.
А если в следующей версии Перл и Раку все-таки сойдутся, как назовут новый язык -- Перлак?
Не сойдутся. Они очень разные. Raku -- это язык современный, модно-молодёжный. А Perl7 -- это для поддержки легаси, и для перловиков, которые не хотят слезать с перла.
> перловиков, которые не хотят слезать с перлагорбатых могила исправит
Да новый никому не нужен, а старый на пенсии.
Перл и Раку - языки, которые 95% программистов на питоне никогда не смогут осилить. Сидели бы на попе молча, но нет, лезут комментировать.
Ну почему? Я писал на perl, вполне себе нормально для своей ниши при условии, что делаешь это постоянно 24х7. Стоит оставить на месяц, всё, мыло мочало, начинай сначала.Я не программирую 24х7, для меня это средство решать попутные задачи, поэтому выкинул perl в пользу питона.
У нас в конторе на perl пара вспомогательных скриптов (типа генераторы пакетов данных), а весь продакшн на плюсах и джаве.
Вы пишете на раку серьёзные большие проекты за много денег? Тогда да, у вас есть резоны считать раку годным инструментом, если это всё на уровне пет-проектов для собственного удовольствия, не вижу предмета для дискуссии, потому что раку не существует в продакшене.
Чисто личный опыт. Пишу на раку не 24/7, а примерно неделю через две. Проблем не исптываю. Про пёрл не скажу. Когда писали на перле, я ещё в животе сидел.А продакшон -- не самое лучшее мерило для качества языков. Потому что продакшон -- это про "здесь и сейчас", а не про "надёжно и на века". Это подтверждается и практикой: тот же пёрл вроде бы никогда не был особо популярным в продакшоне. Зато то, что на нём написано, так и работает уже 30 лет. А в продакшоне примерно так: сегодня пилим продукт, продаём. Завтра уже не покупают, поэтому закапываем и пилим другое. Поэтому получается, что для продакшона -- одно, для опенсорца -- другое, а лично для себя -- вообще что душе угодно.
> продакшон -- это про "здесь и сейчас", а не про "надёжно и на векаНаоборот.
> тот же пёрл вроде бы никогда не был особо популярным в продакшоне
Наоборот. Только perl всегда используется как вспомогательный клей. А писали на, хе-хе, фортран, кобол, ада, С, С++, потом подтянули Java. Python занял место Perl. И то, с оговорками.
> в продакшоне примерно так: сегодня пилим продукт, продаём. Завтра уже не покупают, поэтому закапываем и пилим другое
Вы, коллега, по причине силы силы юности, путаете продакшн и стартап. Не надо так.
Например, интерфейс к сети SWIFT, SWIFT Alliance Access написан на плюсах (ещё есть куски java, в качестве клея tcl и perl) и прекрасно работает с 1989, емнип, года в более чем 7000 банков по всему миру. Это - продакшн.
Из примеров попроще -- vim (1991 год, С и vimscript) и emacs (1984 год, С и emacs lisp). Ими пользуются десятки миллионов человек по всеми миру более 30 лет. Или Sendmail (1980 год, С и Perl).Завтра какой-нибудь pycharm загнётся, а vim c emacs так и будут жить и развиваться.
Это -- продакшн.
И кстати, не надо путать продакшн и опенсорс. Это вообще ортогональные вещи.
> Например, интерфейс к сети SWIFT, SWIFT Alliance Access написан на плюсах (ещё
> есть куски java, в качестве клея tcl и perl) и прекрасно
> работает с 1989, емнип, года в более чем 7000 банков по
> всему миру. Это - продакшн.Убедительный пример. Но мне всё же кажется, что правда где-то посередине. То есть продакшн бывает разный. Вы привели пример SWIFT. А я могу привести в пример сбербанк онлайн. Он постоянно меняется, переписывается, но при этом он никогда не работал стабильно и без ошибок. Всё таки сбер нельзя назвать стартапом, вполне себе энтерпрайзненький продакшон.
А про продакшн и опенсорц -- я не путаю и понимаю, что и то, и то может быть самого разного качества. Да, они ортогональны, но это в теории. А на практике часто случается так, что корпорация может себе позволить 10 раз переписывать продукт на новом молодёжном фреймворке. Опенсорц не может себе это позволить, потому что нет столько ресурсов. Да, есть много любителей попереписывать, но их проекто обычно и не живут долго. В то время как vim и emacs, которые вы справедливо упомянули, ещё и нас переживут.
> сбербанк онлайнКусок полуработающего говна, написанный стартаперами на стартапных же технологиях аджайл-абырвалг.
> сбер нельзя назвать стартапом
Разумеется нельзя, потому что сбер и стартап -- это банк и игра на смартфоне в свинок.
Что касается их подхода к изготовлению ПО, они там исповедуют совершенно уродские аджайл-подходы, но могут позволить себе залить деньгами недостатки ума и архитектуры.
Продакшн и опенсорс -- это вы хотите сравнить белое и круглое. Если камень белый, то он не круглый, или камень больше круглый, чем белый.
Для примера. RHEL -- продакшн? Да. Опенсорс? Несомненно.
> на практике часто случается так, что корпорация может себе позволить 10 раз переписывать продукт на новом молодёжном фреймворкеНет, так практически не бывает. К примеру тот же Alliance Access был один раз перенесён с самописной БД на основе с-isam на oracle. Пои этом практически вся архитектура пакета и логика работы осталась неизменной, а изменения вносились по капле годами.
Как раз стартапы как мартышки занимаются херней переписывания, потому что не могут в архитектуру и сила юности в жопе играет, а давай всё напишем на раку, модно, стильно, заодно и раку выучим. Потом один из двух стартаперов подавился смузей, нашёлся другой и решили всё переделать на Хаскеле, а чо, круто!
Таким переписыванием MS страдает, все знают мем про фатальный недостаток. Но там другие причины, смыслы и цели.
>Стоит оставить на месяц, всёСлабый программист - это норма.
>поэтому выкинул perl в пользу питонаПравильно сделал. Не твой язык.
>Вы пишете на раку серьёзные большие проекты за много денег?
>Тогда да, у вас есть резоны считать раку годным инструментомHaskell или Ocaml в вашем понимании годные инструменты? Языки программирования, их ценность как языков, от количества проектов зависят мало. Раку (и сам перл тоже) - это про развитие языков программирования. Выразительные, интуитивные, стоящие на границе естественного и формального языка. Питон как язык по сравнению с перлом - убожество. Чем он от паскаля отличается или бейсика? Тормознутее разве что.
> Языки программирования, их ценность как языков, от количества проектов зависят малоНет ни одного маргинального языка программирования, который имет ценность помимо академических изысканий студентов и теоретиков-преподов.
> Правильно сделал. Не твой язык.
Твое мнение очень важно для меня.
> Питон как язык по сравнению с перлом - убожество.
Всё, что можно написать на perl, можно написать и на python. А вот то, что можно написать например на С, на perl и python не выйдет. То есть, что perl, что python, это одного поля морковки.
Всё остальное про ценность, выразительность, пограничность и интуитивность есть словоблудие.
>их ценность как языков, от количества проектов зависят мало.Зато чому-то эта ценность растёт с количеством скоммунижженых фич из языков наподобие Haskell и OCaml.