В кодовую базу эталонной реализации языка 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 назад так вообще был пик популярности и бизнес часто строился вокруг него.
Шопифаю 19 лет. Какие 7?
Может потому что, когда шопифай появился, го вообще не существовало, даже ноды не существовало. ROR это первый фреймворк подобного образца, с которого потом уже пошли джанги, ларавели и им подобные.
Django и Ruby on Fails появились с разницей в год, и друг с другом практически никак не связаны. Django из Zope выросла, которую олды не помнят, а нубы не знают.
> Django и Ruby on Fails появились с разницей в год, и друг
> с другом практически никак не связаны. Django из Zope выросла, которую
> олды не помнят, а нубы не знают.Django это 1 в 1 ROR переписаный на питон.
Разрабы Джанго в цвет заявляли, что хотели сделать рельсы на питоне.
Из Zope вырос Pyramid, но он присутствует в следовых количествах
YJIT и ZJIT на RUST же написаны.
и это правильно
Shopify это пилит
Я настолько стар, что помню LAMP...
Были времена в 2000-е, когда монстры начинали так:
Facebook - Linux, MySQL, PHP, не понятно, что за web-server был сначала
Shopify - RoR + Apache
Booking.com - Perl
VK - LAMP 100%
Instagram - Django + PostgreSQL + Apache (?)Все это делали комерсы, а не инженеры. Инструмент выбирали по принципу бесплатно и надежно. Идея заработать кучу бабла всегда была на первом приоритет. А про вашу архитектуру и не думали.
Но был на заре 2000-х сервис в котором инженерная мысль победила, и команда избрала лучший по тем временам стек. Это был myspace
> Но был на заре 2000-х сервис в котором инженерная мысль победила, и команда избрала лучший по тем временам стек. Это был myspaceЛучший по мнению портала GetTheFacts, что ли?
Например, RedMine вполне живой и активно развивается. Особенно в РФ, после ухода Atlassian.
А ведь можно писать на языке, который сразу компилится в нативный машинный код. Зачем все эти свистопляски и приседания? Ну серьезно. Это как если бы Петр изобрел звездолет, а Витя изобрел кастрюлю для тех же целей -- исследовать вселенную. И вот, Витя теперь целыми днями думает, как бы заставить кастрюлю летать. С переменным успехом у него это получается, например, недавно изобретенная им техника ZJIT позволяет кастрюле подыматься на 100 метров от земли.
С практической точки зрения, идеальный вариант, отвечающий всем требованиям, предъявляемым к скриптам и серверным системам, это лисп, только многим людям почему-то не нравится на нём писать.
Потому что его синтаксис ужасен. Плюс на нем нет фреймворков корпоративного уровня. Идеальный язык (который еще не создан) -- это язык, который можно и скриптом, и компилять, и чтоб метапрограммирование (модифицировать AST на том же языке), и чтоб система типов была дружелюбна как явистам, так и хаскелистам (да), и чтобы инфраструктура/экосистема, хорошая пермиссивная лицензия, и конечно же си-подобный синтаксис. Вот. Лисп ничего этого не имеет. Ближайший к идеалу -- это раст.
Нормальный синтаксис, никак не хуже хаскел и раста с икон. Фреймворки корпоративного уровня есть в Racket, всё максимально дружелюбно жабистам.
> Нормальный синтаксис, никак не хуже хаскел и раста с икон(Удачи (искать (поставленную (не (в (том месте))) скобку)))
В других языках, в частности, в питоне, ситуация со скобками не многим лучше. Для этого есть подсветка синтаксиса и lsp.
> Для этого есть подсветка синтаксиса и lsp.Я понимаю посоветовать один из десятка инструментов для структурного редактирования lisp, вроде paredit/emacsовых плагинов... Но полагаться на подсветку/lsp в условном scheme это худшее предложение
Нет, когда у тебя все синтаксические конструкции состоят из скобок и в коде полно ))))))))), это не то же самое что и python/rust/любой другой язык с более различимыми конструкциями
>> Для этого есть подсветка синтаксиса и lsp.
> Я понимаю посоветовать один из десятка инструментов для структурного редактирования lisp,
> вроде paredit/emacsовых плагинов... Но полагаться на подсветку/lsp в условном scheme это
> худшее предложение
> Нет, когда у тебя все синтаксические конструкции состоят из скобок и в
> коде полно ))))))))), это не то же самое что и python/rust/любой
> другой язык с более различимыми конструкциямиА в чём, собственно, проблема? Подстветка синтаксиса разноцветная, просто смотришь, чтобы нигде не напутать при редактировании. При написании такой проблемы нет.
А в чём проблема? Запускаете автоформатирование, и сразу видно, что и где потеряно. Емнип в емаксе можно включить автоформатирование
У тех, кто про Лисп знает чуть больше, чем «гыыы скобатьки))))))» такая проблема возникает крайне редко. А у тех лисперов, котрые пользуются paredit (а это практически все лисперы) такой проблемы возникнуть не может в принципе. Зато вот те, кто про программирование слышал от пацанов за гаражами постоянно какие-то проблемы с синтаксисом.
> У тех, кто про Лисп знает чуть больше, чем «гыыы скобатьки))))))» такая
> проблема возникает крайне редко. А у тех лисперов, котрые пользуются paredit
> (а это практически все лисперы) такой проблемы возникнуть не может в
> принципе. Зато вот те, кто про программирование слышал от пацанов за
> гаражами постоянно какие-то проблемы с синтаксисом.Я не профи в lisp, но писал на нём достаточно долго. Paredit решает многие проблемы, но мне было очень неудобно с ним работать, потому что он слишком сильно пересекался с vim биндингами
Однако даже с ним в некоторых кодовых базах было тяжко, потому что во многих кодовых базах принято не использовать let там, где выражение не используется больше одного раза, в результате чего любая математика превращалась в огромное вложенное нагромождение скобок, которое реально было тяжело читать
В то время как в любом другом языке всё таки стараются избегать настолько большой вложенности, и условный let её не увеличивает
Ну так вы создали себе же проблему, вот в асм никаких скобок вовсе нет, а вам скобки для чего? Оказалось, что асм слишком растянут в длину и его надо как-то собрать в ширину, а собрав в ширину (в одну строку), необходимо как-то одно от другого разграничивать, вот и придумали заключать все в скобки (неважно какие, и в каких целях). И что теперь? потеряли счет скобкам?
>> Нормальный синтаксис, никак не хуже хаскел и раста с икон
>(Удачи (искать (поставленную (не (в (том месте))) скобку)))Ужас какой как-будто в сиподобных языках со скобками сильно проще
Удачи() {искать() {поставленную(можеттута()) {не {в() {том() месте()}}} скобку()}};
>>> Нормальный синтаксис, никак не хуже хаскел и раста с икон
>>(Удачи (искать (поставленную (не (в (том месте))) скобку)))
> Ужас какой как-будто в сиподобных языках со скобками сильно проще
> Удачи() {искать() {поставленную(можеттута()) {не {в() {том() месте()}}} скобку()}};Сиподобные языки не сжимают в одну строку чтобы у тебя в конце каждого выражения было "))))))))"
> не сжимают в одну строкуну не сжимай, а кто-то запрещал вложенные циклы или выражения в условиях? ну и чем же лисповые скобки от сишных будут отличатся? да ничем в том то и дело. И скобки вы ровно потому и ставите, чтобы в "одной строке" написать и сэкономить вертикальное пространство. Вам же асм именно этим и не нравился, что каждый шаг программы это отдельная строка, и не нужны никакие скобки.
> Вам же асм именно этим и не нравился, что каждый шаг
> программы это отдельная строка, и не нужны никакие скобки.Кому "нам"? Я ничего про asm не говорил, зачем мне приписывать непонятно что?
Почему для выразительного языка обязательно нужна настолько большая вложенность?
Haskell/Rust/C#/JS/где угодно есть выразительность без необходимости использовать инструменты которые занимаются только тем что балансируют скобки
> Кому "нам"? Я ничего про asm не говорил, зачем мне приписывать непонятно что?ну конечно же не вам лично, это собирательное. Хотя можете ответить лично от себя, почему у вас в асм нет скобок?
> Почему для выразительного языка обязательно нужна настолько большая вложенность?
А что, от выразительности языка зависит большая вложенность? Это необходимость того или иного алгоритма, и там где нужно 15 вложенных циклов, никакой язык вас от этого своим синтаксисом не избавит, не уменьшит количество скобок, кроме - асм, где этих скобок нет.
> инструменты которые занимаются только тем что балансируют скобки
Ну и зачем вам шуруповерт, который все равно завинчивает по одному шурупу за раз? Использование того или иного инструмента должно давать выигрыш, а не порождать новые проблемы. В аналогии с шуруповертом - зачем он если есть отвертка, он только создает проблемы и потребляет больше электричества, не говорю уже про потерю бит, и расход ресурса батареи.
Сильно проще. Во-первых типов скобок больше, и это упрощает дело. Во-вторых скобок меньше. Мне не надо городить скобки на скобках внутри let и добавлять уровень вложенности только для того, чтобы определить локальную переменную. Мне не надо каждую арифметическую операцию брать в скобки. Я легко могу написать x = y + z; не использовав ни одной скобки, в лиспе же без двух пар не обойтись: (setf x (+ y z)).
> Я легко могу написатьда вы легко можете писать по одному выражению на строку, как в асм, но сравнивать x = y + z; с (setf x (+ y z)) - не корректно, ибо программы на лиспе это один большой односвязный список выражений. Вот когда вы свои сишные программы начнете писать в одну строку вот тогда у вас и появятся ровно те же самые скобки как и у лиспа.
БНФ:
s_expression ::= atomic_symbol | "(" s_expression "." s_expression ")" | list
list ::= "(" s_expression { s_expression } ")"
atomic_symbol ::= letter atom_part
atom_part ::= empty | letter atom_part | number atom_part
letter ::= "a" | "b" | " ..." | "z"
number ::= "1" | "2" | " ..." | "9"
empty ::= " "
> чтоб система типов была дружелюбна как явистам, так и хаскелистам (да)Со своим уставом в чужой монастырь не ходят. Явистскую систему типов оставь в яве, хаскелистскую - в хаскеле. Не можешь осилить нативную для языка систему типов - на выход.
Фшарп довольно точно подходит под описание. Правда чтобы писать ддд нужно каждый примитив обернуть в рекорд. Чтобы вербозно и наверняка будет тормозить
Ближайший к идеалу это golang
Это каким таким требованиям он отвечает? Особенно учитывая что он сам - абстрактная концепция, у которой есть несколько реализаций с совершенно разными свойствами. И ни одна из них не отвечает почти никаким требования современной разработке - инфраструктуры модулей нет, тулинга нет, нормального FFI нет, асинхронщины нет, эффективной компиляции нет. Да, до синтаксиса я даже не считаю нужным опускаться.
>отвечающий всем требованиям, предъявляемым к скриптам и серверным системам, это лиспТипизация? Нет, не слышали
Есть typed-racket
Типизирован должен быть весь язык, а не его малое подмножество
> Типизирован должен быть весь язык, а не его малое подмножествоНу вообще лисп оригинальный, и CL и elisp, они про динамизм, чтобы можно было все менять на лету без сброса состояния. Там другая философия.
> это лисп, только многим людям почему-то не нравится на нём писать.От скобочек в глазах рябит. Ещё бы на расте предложили.
Ну, если хочется компилируемого и годный синтаксис, есть cython.
Ну конечно. Приседания и свистопляски это же не так интересно как мазохизм компиляции нативников под хотя бы пяток широко используемых операционок: винду, пингвинов, яблок, ведроидов да мобильных огрызков. И это еще без разных аппаратных вариантов 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-м на похапе
Ну, как вам сказать? ~20 лет назад ноды как-то того... не было. А python был... но как бы вам сказать? Второй да. С автобот-прости-это-не-ругательство - zope'ой. И ээээ... удачи вам её поддерживать в наши дни.
> OCamlЭто что вообще такое? В первый раз слышу, если честно (гуглить лень, сорян).
Функциональня строготипизированный язык, с возможностью писать в ООП стиле. Благодаря выводу типов, почти не нуждается в явном указании типов. В современном python или php приходится чаще указывать типы, чем в Ocaml.
Об этом языке Copilot и ChatGPT хоть что-то знают? Если нет, то язык мёртвый. Я вот о нём впервые слышу.
Я вот слышал про Caml, не более. OCaml как я и предполагал расшифровывается как Objective Caml. Видимо экзотика из серии Objective-C, Object Pascal и т.д.
Ocaml будет куда популярнее и современнее, чем caml. Так что экзотика это caml
Разумеется. Они, в отличии от всяких анонимов, тексты гигабайтами читают
> слепили серверную часть из когда-то раздуто-модного г.на, а теперь - "героически" решают заранее очевидные проблемыСлепили они бизнес с капитализацией $140 миллиардов, а когда они начали писать свой софт, проблемы были не очевидны, тогда опыта гиперскейлинга вообще не было практически ни у кого. А сейчас, когда и бабки есть, и люди — чего бы и не порешать проблемы-то?
Есть проект Crystal: по сути, компилируемый Ruby.
Проще перейти на него, чем руби "разогнать"
>Проще перейти на него, чем руби "разогнать"Не проще. Под него нужно портировать код, при этом, сделать это не всегда возможно. В итоге что разработка jit, что портирование на crystal требует очень много сил, очень медленное. Даже если переписать с руби на что-то другое, это тоже потребует много сил и будет очень медленно. Ловушка очень надёжная
На Ruby есть весь необходимый инструментарий, очень много Rails проектов, которые посложнее Hello world или апишки записной книжки. На Crystal почти ничего нет. Половина библиотек заброшены, львиной доли библиотек просто напросто нет.Если и говорить про какой-то переезд, то если только на elixir и то с натяжкой
Библиотеки нужны только для прототипов (помним что 99% стартапов разоряются в первые 3 года). Если проект взлетел его пишут всё с нуля кастомное.
Друг, поверь, легче будет переписать на турбо поскаль, чем с руби на кристал.
А чиво не сразу на Gambas?
У них всё на RoR. Для "перейти" надо сначала спортировать RoR на Crystal. Удачи
тупой не логичный язык, создатель которого сказал что ему пофигу на производительность. видать даже его достали эти адские тормоза. руби и питон короли тормозов. даже питон еще поживет за счет библиотек, а руби RIP
Питон идеален для задач вида "нарисовать график для статистического распределения" и для скриптов автоматизации вместо Баша. А вот РубинНаРельсах даже здесь неудобен.
> нарисовать график для статистического распределенияЭто ещё в школе на турбо поскале дети делают, нафига душить питона для такой простой задачи?
> Питон идеален для задач вида "нарисовать график для статистического распределения" и для скриптов автоматизации вместо БашаЧем больше задача, тем хуже для неё подходит питон. Добавь к графику ещё какую-то обработку, и всё, питон уже станет неудобен. А если знать любой взрослый язык, то проще изначально будет реализовать её на нём, чем выяснять, как это на питоне делается.
Интересно, в мире ещё остались вакансии на Руби? Вроде даже пых последний быстрее чем это. Какая ниша Руби и RoR?
Легаси его ниша.
Фанатики очередного "убийцы пыха" по недоразумению наплодили г-кода и теперь вынуждены его поддерживать.
На hh даже 99 вакансий есть!
Все с опытом 10+ лет, и чтоб швец, и жнец, и на дуде игрец.
Пыха всегда была быстрее рубей. Руби это рельсы и больше ничего.
vagrant, chef, puppet, маководский homebrew, jekyll - да, действительно. Рельсы-и-ничего-кроме-них.
Забавно, только вчера гуглил на реддите жив ли руби. Жив, но в роли кобола или джавы где-то глубоко в легаси.
Тот же 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зи-технологии нафиг не нужны.
П.с. потому что львиная доля страниц ориентированная на конечных клиентов перешла на маркетплейсы, в инстаграм и телеграм. У меня жена продаёт всякие хендмейд побрякушки, давно ушла полностью в инсту (как и ВСЕ её конкуренты), хотя раньше когда-то был сайт.
Не логично. Веб, это штука сложная, там XSS, там sql инъекция, там ещё что-то.
> Оба JIT-компилятора созданы командой разработчиков из компании Shopify в рамках инициативы по увеличению производительности Ruby-программ, использующих фреймворк Rails и вызывающих очень много методов.Помнится dropbox тоже ускоряли питон через pyston, но потом перешли на go (или что-то у них сейчас там). Возможно разработчикам shopify просто стоит попросить LLM переписать их код на что-то более производительное?
Хороший кризис их вылечит. А пока можно набирать хайп рост акций под капитализацию путем утилизации программистов.
> pystonЯ думал это мем.
>> pyston
> Я думал это мем.Нет, pypa.io тоже не мем. Вообще у них странные названия все: pyston, pip, pypa... Наводит на мысли.
> Вообще у них странные названия
> Наводит на мысли.Нормальные названия, если нет ассоциаций со словами на русском.
Федора для Raspberry Pi тоже нормально звучала для всех иностранцев, и только тут подняли бучу что мол скрепы поразгибаются.
>> Вообще у них странные названия
>> Наводит на мысли.
> Нормальные названия, если нет ассоциаций со словами на русском.
> Федора для Raspberry Pi тоже нормально звучала для всех иностранцев, и только
> тут подняли бучу что мол скрепы поразгибаются.Вообще есть анализ перед запуском, если кому-то важно, чтобы звучало нормально. Но для русского и китайского париться не нужно, а стоит называть как привыкли, и пофиг на иностранцев, а у нас как обычно.
Например, называть менеджер пакетов для питона -- ulitka, а то poetry... Работает то он как улитка.
С одной стороны JIT экономит время на инициализацию незадействованных объектов, с другой стороны, требует отложенной инициализации частей системы, что несёт элемент непредсказуемости.