В кодовую базу эталонной реализации языка Ruby добавлен новый JIT-компилятор ZJIT, позиционируемый как следующее поколение Ruby JIT. ZJIT войдёт в состав следующего значительного выпуска Ruby 3.5, в котором будет доступен в качестве опции параллельно с JIT-компилятором YJIT, а в версии Ruby 3.6 возможно заменит его. Как и YJIT новый JIT-компилятор написан на языке Rust. Оба JIT-компилятора созданы командой разработчиков из компании Shopify в рамках инициативы по увеличению производительности Ruby-программ, использующих фреймворк Rails и вызывающих очень много методов...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=63240
Насколько дикий оверхэд в этот раз? Ограничения? А вообще, я был уверен, RoR давно закопали, оказывается, где-то ещё тащат.
Ну не прям таки оверхэд. YJIT пацаны завозили не ради коммьюнити, а ради собственного Shopify, который от и до на рельсах написан. Дает ли YJIT буст перфоманса ? Дает. Дает ли это буст перфоманса другим Rails приложениям ? Дает. Ну и славно. Shopify в плюсе, другие проекты основанные на Rails тоже за счет OSS.Нанять 3-4 сишника для Shopify дешевле чем переписать все на некст условный.
Ну то есть, YJIT - это дикие костыли. И чтобы руби не тормозил, нужны костыли. Понятно. А владельцы Shopify не могли изначально взять тот же го или кваркус? Зачем они выбрали Руби, чтобы всё изначально тормозило?
Такие вопросы возникают из-за того, что технари квадратно-бытовой логикой пытаются объяснить бизнес-логику. У них, например, могла быть изначально сильная руби-команда - нафига тратить время и деньги на найм гошников, если можно сильно срезать косты? Ну и руби не так что бы мертв, он все ещё остаётся хорошей платформой в виде рельсы. А лет 7 назад так вообще был пик популярности и бизнес часто строился вокруг него.
Может потому что, когда шопифай появился, го вообще не существовало, даже ноды не существовало. ROR это первый фреймворк подобного образца, с которого потом уже пошли джанги, ларавели и им подобные.
Django и Ruby on Fails появились с разницей в год, и друг с другом практически никак не связаны. Django из Zope выросла, которую олды не помнят, а нубы не знают.
> Django и Ruby on Fails появились с разницей в год, и друг
> с другом практически никак не связаны. Django из Zope выросла, которую
> олды не помнят, а нубы не знают.Django это 1 в 1 ROR переписаный на питон.
Разрабы Джанго в цвет заявляли, что хотели сделать рельсы на питоне.
YJIT и ZJIT на RUST же написаны.
и это правильно
А ведь можно писать на языке, который сразу компилится в нативный машинный код. Зачем все эти свистопляски и приседания? Ну серьезно. Это как если бы Петр изобрел звездолет, а Витя изобрел кастрюлю для тех же целей -- исследовать вселенную. И вот, Витя теперь целыми днями думает, как бы заставить кастрюлю летать. С переменным успехом у него это получается, например, недавно изобретенная им техника ZJIT позволяет кастрюле подыматься на 100 метров от земли.
С практической точки зрения, идеальный вариант, отвечающий всем требованиям, предъявляемым к скриптам и серверным системам, это лисп, только многим людям почему-то не нравится на нём писать.
Потому что его синтаксис ужасен. Плюс на нем нет фреймворков корпоративного уровня. Идеальный язык (который еще не создан) -- это язык, который можно и скриптом, и компилять, и чтоб метапрограммирование (модифицировать AST на том же языке), и чтоб система типов была дружелюбна как явистам, так и хаскелистам (да), и чтобы инфраструктура/экосистема, хорошая пермиссивная лицензия, и конечно же си-подобный синтаксис. Вот. Лисп ничего этого не имеет. Ближайший к идеалу -- это раст.
Нормальный синтаксис, никак не хуже хаскел и раста с икон. Фреймворки корпоративного уровня есть в Racket, всё максимально дружелюбно жабистам.
> Нормальный синтаксис, никак не хуже хаскел и раста с икон(Удачи (искать (поставленную (не (в (том месте))) скобку)))
В других языках, в частности, в питоне, ситуация со скобками не многим лучше. Для этого есть подсветка синтаксиса и lsp.
> Для этого есть подсветка синтаксиса и lsp.Я понимаю посоветовать один из десятка инструментов для структурного редактирования lisp, вроде paredit/emacsовых плагинов... Но полагаться на подсветку/lsp в условном scheme это худшее предложение
Нет, когда у тебя все синтаксические конструкции состоят из скобок и в коде полно ))))))))), это не то же самое что и python/rust/любой другой язык с более различимыми конструкциями
>> Для этого есть подсветка синтаксиса и lsp.
> Я понимаю посоветовать один из десятка инструментов для структурного редактирования lisp,
> вроде paredit/emacsовых плагинов... Но полагаться на подсветку/lsp в условном scheme это
> худшее предложение
> Нет, когда у тебя все синтаксические конструкции состоят из скобок и в
> коде полно ))))))))), это не то же самое что и python/rust/любой
> другой язык с более различимыми конструкциямиА в чём, собственно, проблема? Подстветка синтаксиса разноцветная, просто смотришь, чтобы нигде не напутать при редактировании. При написании такой проблемы нет.
А в чём проблема? Запускаете автоформатирование, и сразу видно, что и где потеряно. Емнип в емаксе можно включить автоформатирование
У тех, кто про Лисп знает чуть больше, чем «гыыы скобатьки))))))» такая проблема возникает крайне редко. А у тех лисперов, котрые пользуются paredit (а это практически все лисперы) такой проблемы возникнуть не может в принципе. Зато вот те, кто про программирование слышал от пацанов за гаражами постоянно какие-то проблемы с синтаксисом.
> чтоб система типов была дружелюбна как явистам, так и хаскелистам (да)Со своим уставом в чужой монастырь не ходят. Явистскую систему типов оставь в яве, хаскелистскую - в хаскеле. Не можешь осилить нативную для языка систему типов - на выход.
Фшарп довольно точно подходит под описание. Правда чтобы писать ддд нужно каждый примитив обернуть в рекорд. Чтобы вербозно и наверняка будет тормозить
Это каким таким требованиям он отвечает? Особенно учитывая что он сам - абстрактная концепция, у которой есть несколько реализаций с совершенно разными свойствами. И ни одна из них не отвечает почти никаким требования современной разработке - инфраструктуры модулей нет, тулинга нет, нормального FFI нет, асинхронщины нет, эффективной компиляции нет. Да, до синтаксиса я даже не считаю нужным опускаться.
>отвечающий всем требованиям, предъявляемым к скриптам и серверным системам, это лиспТипизация? Нет, не слышали
Есть typed-racket
Ну конечно. Приседания и свистопляски это же не так интересно как мазохизм компиляции нативников под хотя бы пяток широко используемых операционок: винду, пингвинов, яблок, ведроидов да мобильных огрызков. И это еще без разных аппаратных вариантов x64, arm и прочего прочего. Это же так чудесно когда у тебя даже int-ы на каждой платформе разные :)
В интерпретируемых языках танцы с бубном возникают при установке множества зависимостей.
Проблема с зависимостями давным давно решена. Либо силами nix-а, либо пакетного менеджера самого языка. А вот проблему скачивания нужного бинарника вы так просто не решите. И если спрятать нужный бинарник за кнопкой в гугл-плее ещё можно, то как быть, когда нужно бинарника нет - вопрос открытый.
Когда по делу сказать нечего, начинают приводить аналогии.
Я и сказал по делу: испокон веков люди писали исходники на ЯП, а далее этот исходник сразу компилился в машинный код. Но затем появились люди, которые такие: а давайте интерпретировать исходники! Ну и начали это дело, сначала в бейсике интерпретировали строка за строкой, потом появились ЖВМ и прочие шняги (язык Ява проектировался под несуществующий гипотетический ЦПУ, способный нативно исполнять .class-файлы? шта? что за ибанариум?) А потом, когда эти хипстерочки столкнулись с тем, что интерпретация заметно тормознее компиляции в машинный код, они такие: а давайте делать JIT! То есть придумали ересь, а потом стали придумывать, как бы решать проблемы, созданные этой ересью. Если отказаться от интерпретации и байт-кода, то JIT и не нужен вовсе, так как такой проблемы, как "тормоза", нет: программа сразу задействует всю мощь ЦПУ, потому что компилится сразу в машинный код.
Ну вот врешь же.
Испокон веков люди писали даже не ассемблере а били дырки в перфокартах. Прям целые отделы девочек сидели и фигачили из дырок программы индивидуальные для каждого процессора.
И тут придумали ассемблер который вместо дырочек позволял писать комадочки и компутер сам бил дырочки в перфокартах.
А потом придумали компилятор который делал командочки еще проще, но ужас - он уже работал на "усредненном процессоре" и ни один компилятор на сегодня не задействует все возможности современных процессоров на 100%. Для использовать векторных операций все равно придется спуститься хотя бы до уровня ассемблера.
И о ужас тут придумали новые процессоры и все программочки перестали работать.
А джависты хмыкнули, за них сделали новую JVM и все их программки продолжили работать без единой правки.
> тут придумали новые процессоры и все программочки перестали работать.
> А джависты хмыкнулиНу да, ведь процессоры придумывают каждый понедельник. Раз в столетие перекомпилить прогу ничего не мешает. Это все равно лучше, чем иметь репутацию тормозного языка, который ява себе снискала вполне заслуженно.
Это тоже вранье. Тормознутая не Java а методика написания корпоративного ПО. Сотни прокладок и интерфейсов. Поверь если в том же C++ обложиться таким количеством виртуальных методов то чисто нативная программа точно так же будет сходить с ума от поиска нужных точек вызова функций.
Сама java во время выполнения быстро перегонит все интерпретируемую часть в бинарный вид.
Уж её то JIT за 30 лет существования вылизан почти до совершенства.
Сколько ни пробовал программы на Java и все они такие себе. Не говоря уже о том что для меня как пользователя изо дня в день запускать программу через кучу прослойки смысла не много.
Тобишь вы не пользуетесь мобильными устройствами. Не пользуетесь всякими "умными" умными девайсами. Не пользуетесь онлайн магазинами.
Да и что там перечислять - не пользуетесь банковскими картами.
Потому что в подавляющем большинстве они все так или иначе пользуют java. Даже если вы и не видите намека на нее. Подавляющая часть серверного ПО сделана на той самой "тормознутой" яве.
Ну а мордашка так и ладно, пусть она у вас будет без прослоек на нативном... электроне :)
>Это все равно лучше, чем иметь репутацию тормозного языка, который ява себе снискала вполне заслуженно.Вообще, то ява не сильно тормознутая, просто у неё жирная и супер стабильная JWM, в которую вливали деньги монстры типа оракла. Ява - отличный выбор там, где нужна надёжность. Самый безопасный язычок со статическими типами, не считая новомодного Раста. Ясное дело, локалхостам и стартапам всяким куда дешевле и рациональнее юзать пых или пихон, ибо обслуживание явы очень дорого, и васянам не по карману. А вот корпорации до сих пор выбирают яву.
>Ну да, ведь процессоры придумывают каждый понедельникЭто сейчас хорошо - везде x86 на сервере и десктопе, arm - экзотика для мобилок, одноплатников и огрызков, а всё остальное почти не встречается. Вы посмотрите сколько раньше было процессоров и операционных систем
>Раз в столетие перекомпилить прогу ничего не мешаетМешает. Для этого нужно как минимум иметь в штате специально обученного специалиста, который запустит компиляцию и исходники
>Это все равно лучше, чем иметь репутацию тормозного языкаСреди кого, среди месных ыкспердов, который на сишке г-кодят? В jvm максимум можно было ввести aot компиляцию, при первом установке, но тогда открыт вопрос, сколько бы эта первый установка длилась. Я уже отвык от долгой установки, как бывало в нулевых на винде. А так, да будет вам известно, торомозит не сама jvm, а программы на ней. Посмотрите на то, сколько игр под jvm. Взять ту же mindustry - rts, tower defense, данный жанр ну никак не уживётся с тормозами.
> командой разработчиков из компании Shopify
> в рамках инициативы по увеличению производительности Ruby-программ,
> использующих фреймворк Rails и вызывающих очень много методовТак и запишем - слепили серверную часть из когда-то раздуто-модного г.на, а теперь - "героически" решают заранее очевидные проблемы. Вместо того, чтобы изначально подумать головой, а не верить на слово модным статейкам от авторов, которые всё равно ни за что не отвечают
> использование LBBV в YJIT привело к тому,
> что проект ... развивался только сотрудниками ShopifyПричём, дураков подобных им, оказалось немного
> и даст возможность привлечь к работе новых участников
Теперь из кожи вон лезут, чтобы хоть кого-то постороннего впрячь в эту халтуру ибо тупость обходится слишком уж дорого
И что им нужно было взять?
Компилируемый язык, как не сложно догадаться. Например, Ocaml. Или, может быть какой-нибудь Standar ML. Если они готовы разрабатывать интерпретатор, то написать несколько библиотек для них точно не будет проблемой.
Здорово. Люди хоронят язык на котором есть библиотеки почти под любой чих и какие никакие вакансии с рылами, но при этом переписывать проект на Ocaml это типа ок.
>на котором есть библиотеки почти под любой чихВы так говорите, словно написание библиотек невероятно сложно. Солько лет уже пишется jit для руби? И как, догнали js? За это время уже давным давно можно было самостоятельно написать нужные библиотеки JIT, это развлечение для богатых. M$ с dot net, Google с Node, Sun/Oracle с jvm.
Пока одни клепали по-быстрому на RoR, другие думали головой, писали на OCaml, и так и не вышли на рынок, потому что первые уже весь рынок заняли и за это время выкатили в 10 раз больше фич.Да, теперь первые решают проблемы. А у вторых проблем нет, они обанкротились и пошли работать программистами к первым.
А где RoR широко используется со своими фичами? Пых с пихонами то понятно, а рельсы где?
GitHub, Gitlab
>Пока одни клепали по-быстрому на RoRОни уже наклепали, и теперь пытаются это оптимизировать
По быстрому клепают на питоне или ноде. И проблем никаких ни с поддержкой ни с поиском тех кто будет ей заниматься по случаю чегоЧто Рубин-на-рельсах, что Окамл с Хаскелем, с практической точки зрения - г.но не меньшее чем Пролог
Большой разницы между Django и RoR тогда не было, но тогда был хайп на RoR
Угу, как там assets pipeline в джанге, в каком году появился?
слушай, не знаю, я отдаю json-ы и msgpack-и, такую примерно штуку делал в последний раз году в 2012-м на похапе
> OCamlЭто что вообще такое? В первый раз слышу, если честно (гуглить лень, сорян).
Функциональня строготипизированный язык, с возможностью писать в ООП стиле. Благодаря выводу типов, почти не нуждается в явном указании типов. В современном python или php приходится чаще указывать типы, чем в Ocaml.
Об этом языке Copilot и ChatGPT хоть что-то знают? Если нет, то язык мёртвый. Я вот о нём впервые слышу.
> слепили серверную часть из когда-то раздуто-модного г.на, а теперь - "героически" решают заранее очевидные проблемыСлепили они бизнес с капитализацией $140 миллиардов, а когда они начали писать свой софт, проблемы были не очевидны, тогда опыта гиперскейлинга вообще не было практически ни у кого. А сейчас, когда и бабки есть, и люди — чего бы и не порешать проблемы-то?
Есть проект Crystal: по сути, компилируемый Ruby.
Проще перейти на него, чем руби "разогнать"
>Проще перейти на него, чем руби "разогнать"Не проще. Под него нужно портировать код, при этом, сделать это не всегда возможно. В итоге что разработка jit, что портирование на crystal требует очень много сил, очень медленное. Даже если переписать с руби на что-то другое, это тоже потребует много сил и будет очень медленно. Ловушка очень надёжная
На Ruby есть весь необходимый инструментарий, очень много Rails проектов, которые посложнее Hello world или апишки записной книжки. На Crystal почти ничего нет. Половина библиотек заброшены, львиной доли библиотек просто напросто нет.Если и говорить про какой-то переезд, то если только на elixir и то с натяжкой
Библиотеки нужны только для прототипов (помним что 99% стартапов разоряются в первые 3 года). Если проект взлетел его пишут всё с нуля кастомное.
Друг, поверь, легче будет переписать на турбо поскаль, чем с руби на кристал.
А чиво не сразу на Gambas?
У них всё на RoR. Для "перейти" надо сначала спортировать RoR на Crystal. Удачи
тупой не логичный язык, создатель которого сказал что ему пофигу на производительность. видать даже его достали эти адские тормоза. руби и питон короли тормозов. даже питон еще поживет за счет библиотек, а руби RIP
Питон идеален для задач вида "нарисовать график для статистического распределения" и для скриптов автоматизации вместо Баша. А вот РубинНаРельсах даже здесь неудобен.
> нарисовать график для статистического распределенияЭто ещё в школе на турбо поскале дети делают, нафига душить питона для такой простой задачи?
> Питон идеален для задач вида "нарисовать график для статистического распределения" и для скриптов автоматизации вместо БашаЧем больше задача, тем хуже для неё подходит питон. Добавь к графику ещё какую-то обработку, и всё, питон уже станет неудобен. А если знать любой взрослый язык, то проще изначально будет реализовать её на нём, чем выяснять, как это на питоне делается.
Интересно, в мире ещё остались вакансии на Руби? Вроде даже пых последний быстрее чем это. Какая ниша Руби и RoR?
Легаси его ниша.
Фанатики очередного "убийцы пыха" по недоразумению наплодили г-кода и теперь вынуждены его поддерживать.
На hh даже 99 вакансий есть!
Все с опытом 10+ лет, и чтоб швец, и жнец, и на дуде игрец.
Пыха всегда была быстрее рубей. Руби это рельсы и больше ничего.
Забавно, только вчера гуглил на реддите жив ли руби. Жив, но в роли кобола или джавы где-то глубоко в легаси.
Тот же GitHub на Ruby написан, и никто его переписывать на другой язык не будет.
А ещё в банках COBOL до сих пор используется и никто переписывать на другой язык не будет. Но значит ли это что язык жив и на нем надо делать новые проекты?
> Тот же GitHub на Ruby написанДавно переведён на микросервисы. Там и go и плюсы и чего только нет.
на джаве и новьё пишется, так то.
просто джава - язычок только для корпораций, из-за её прожорливости и сложности администрирования, по сравнению со смешным пыхом, где хостинг стоит копейки везде, и доступен каждому васяну.
Увы, но Java в компаниях начала сдавать свои позиции(
В пользу чего?
В пользу микросервисов на go и node js. Ещё знаю случаи, где с джавы перешли на C#.
> или джавы где-то глубоко в легаси.На жабе половина ондроед софта написана, если не больше.
И всякие новомодные котлины и скалы работают поверх JVM.
Так что не нужно тут затирать про легаси. Легаси - это конкретная Java 1.6 в каком-нибудь банке. А просто java живее всех живых.
> На жабе половина ондроед софта написанаПод iOS и Android сейчас почти в 99% случаев пишут на react native или flutter. От java там только виртуальная машина.
Никогда не понимал, зачем оно существует и зачем его создали. Есть же много других языков.
Ruby это рельсы. В свое время фреймворк этот был чем-то модным и молодежным, потом появились конкуренты на пхп, питоне, а еще чуть позже веб перестал быть монолитным, проекты состоят из микросервисов, которые могут быть написаны на чем угодно, ведь теперь вся отрисовка осуществляется на клиентах, а их дело только дергать api.
> конкуренты на питонеНу вообще джанго появился раньше.
>Пишу с 80286Как там дела с юникодом, ア ?
>а еще чуть позже веб перестал быть монолитным, проекты состоят из микросервисовТем временем куча страниц в вебе застряла в нулевых, на самописных велосипедах
> на самописныхЛогично, ведь если хочешь сделать хорошо, сделай сам. А вообще те страницы наверняка какие-то компании из B2B или B2G с редкими, но высокомаржинальными сделками. Там дизайн и cмyзи-технологии нафиг не нужны.
П.с. потому что львиная доля страниц ориентированная на конечных клиентов перешла на маркетплейсы, в инстаграм и телеграм. У меня жена продаёт всякие хендмейд побрякушки, давно ушла полностью в инсту (как и ВСЕ её конкуренты), хотя раньше когда-то был сайт.
> Оба JIT-компилятора созданы командой разработчиков из компании Shopify в рамках инициативы по увеличению производительности Ruby-программ, использующих фреймворк Rails и вызывающих очень много методов.Помнится dropbox тоже ускоряли питон через pyston, но потом перешли на go (или что-то у них сейчас там). Возможно разработчикам shopify просто стоит попросить LLM переписать их код на что-то более производительное?
Хороший кризис их вылечит. А пока можно набирать хайп рост акций под капитализацию путем утилизации программистов.
С одной стороны JIT экономит время на инициализацию незадействованных объектов, с другой стороны, требует отложенной инициализации частей системы, что несёт элемент непредсказуемости.
Чирков, убери комментарии, они не нужны. Дизлайков хватит.