Юкихиро Мацумото (Yukihiro Matsumoto), создатель языка Ruby, объявил о переводе под управление основной команды разработчиков языка Ruby (Ruby Core Team) GitHub-репозитория, в котором развиваются инструментарии RubyGems и Bundler для работы с каталогом пакетов rubygems.org...Подробнее: https://www.opennet.me/opennews/art.shtml?num=64070
Вопрос к экспертам - есть что годное и оригинальное на руби? Ну такое, что нельзя было бы написать на сях? Иными словами, какие задачи решает руби, зачем он существует когда есть другие языки?
Гитхаб.
Был... При рождении. Щас уже давно - нет
Никуда у них руби не делся.
По сути тут как и с Линуксом в целом - руби просто не повезло и толстосумы влили бабло в Питон, а не в него, а так он раньше почти во всем превосходил Питон и многие другие языки, сейчас держится на всяких легаси в основном.
Корпорации очень любят руби же. Питон это не благодаря, а вопреки. У 2 питона было плохо с юникодом, всё остальное. включая ffi и cython, определённо лучше. Именно на роли клея для си он и прижился в итоге.
совсем другой язык
интерпретируемый - подходит для скриптинга
популярен в Вебе из-за Ruby on Rails.
Много крупных веб проектов на этом написаныHomebrew тот же
> Homebrew тот жеСпрашивали
> годное
> нельзя было бы написать на сях
> Homebrew тот жеЭто его автор на собесе гугла не смог ревертнуть бинарное дерево на доске, а потом ныл в твиттере "как же так, я делаю годный продукт, а меня не взяли"?
вы кроме хелло ворлдов на сях что-нибудь писали?
Сейчас уже никакие, он медленно но верно умирает. Годах в 10х именно сообщество Руби задавало тренд в развитии фреймворков в том числе и в других языках
Любая программа за 1 секунду. Обучение 1 секунда. Установка 1 секунда. Настройка 1 секунда.
Утечка памяти 0 секунд
Дидактические - служит напоминанием
Puppet.
> какие задачи решает руби, зачем он существует когда есть другие языки?Когда ответишь на вопрос "Вот зачем существуешь ты, если есть другие Васяны?", тогда тебе все станет понятно.
Например, Metasploit Framework, puppet,chef, homebrew, gitlab, rails
Vagrant
Ruby существует потому, что когда-то людям хотелось писать бизнес-логику, а не инфраструктуру. Rails дал вебу MVC до того, как Django вообще родился, и показал, что фреймворк может думать за тебя.
На Си можно написать всё — вопрос в том, захочешь ли потом это сопровождать.
Ruby — не про “что можно”, а про “как приятно”. Сейчас это звучит почти архаично, но в своё время он сделал веб-разработку человечной.
ладно, а теперь напиши пузырьковую сортировку
Хоть я и люблю Ruby, но про Django зря вы так: он появился практически одновременно с Ruby on Rails. Можно считать, что одновременно.
redmine
В универе в обзорном курсе немного писали на Руби. В целом было ощущение неплохое, занятный язык. Но вот блин репутация у него исключительно умирающего, как тот курс закончился, я больше с Руби не встречался в жизни
Пацан шёл к успеху - но не получилось, не фартануло...
Правда теперь есть ненулевая вероятность, что "сообществу" придётся узнать о "небесп...свободности" инфраструктуры и куче других "скучных вещей", которые брала на себя корпорация...
> Пацан шёл к успеху - но не получилось, не фартануло....... Тут должна быть твоя "История успеха" в которой ты расскажешь, как фортануло тебе и тебя и твое поделие тоже знают миллионы Васянов, которым "не фортануло" .....
>> Пацан шёл к успеху - но не получилось, не фартануло...
> .... Тут должна быть твоя "История успеха" в которой ты расскажешь, как
> фортануло тебе и тебя и твое поделие тоже знают миллионы Васянов,
> которым "не фортануло" .....Ну, я конечно верю, что ты под отзывами о ресторанах фото своего вымени выкладываешь - но как-то знаешь? Не очень)
Значит, не фортануло и тебе, бедняга. Ну ничего, здесь на OpenNet ты можешь и дальше пытаться самоутверждаться, неудачник.
Конечно могу - более того, я даже похвастаюсь, что знаю что означает и откуда взялось слово "фарт" (Нет, ты неправильно предположил) и как оно пишется ).
Зачем? Если есть Python, а для более низкоуровневого си
А чем Руби хуже Питона? Ведь RoR более солидный фреймворк чем тот же Django. Другое дело, на руби намного меньше вакансий, что делает руби весьма нишевым язычком.
Загибай, Руби хуже Питона:1. В количестве вакансий
2. В количестве областей, в которых применяется
3. В количестве разработчиков в сообществе
и т.д....
Ruby — это язык, на котором можно выразить идею в коде почти как фразу.
Python — язык, на котором тебе объяснят, что нельзя так писать, потому что “не по PEP8”.
Разница между поэтом и канцелярским работником. Оба пишут тексты — но кого читают, угадай сам.
В естественном языке придумали пунктуацию - маленькие одиночные символы, которые не отвлекают от чтения слов точка а pascal запятая ruby спамят незначительными ключевыми словами запятая причём ruby делает это так неуверенно зпт что в ней одновременно есть и do-end запятая и фигурные скобки (неуверенность - наследие пёрла?).
А в чём измеряется его солидность?
В целом-то язык того же класса, что и Python, но из-за более развесистого и несколько эзотерического синтаксиса, позволяющего сделать одно и то же кучей слегка отличающихся в неочевидных деталях способов, проиграл ему конкуренцию. Ну и фактор случайности сыграл свою роль, наверно: Python получил популярность в научном сообществе, что позволило ему захватить множество ниш, а Ruby взлетел только в области веб-разработки и (немного) инструментов управления инфраструктурой. И то это заслуга всего нескольких продуктов, которые со временем были серьёзно подвинуты конкурентами.
Руби медленный по дизайну, так как в нем есть возможность переписывания кода во время выполнения.
Ну в руби хотя бы гила нет. Вот только не надо мне писать про субинтерпретаторы без гила в 3.14
Твои бы слова да Богу в уши. Может и не было бы гила.
Язык в чем то даже элегантный, но в то время когда я писал на нем пару небольших проектов была слабая поддержка у IDE - из за особеннойтей самого языка, нельзя корректно распарсить.
Ну и выполнялось все очень меееееедленно, так меееееедленно что после перенесли с руби на другую платформу.
Решил для себя что потерял время на изучение и использование.
Хочется по легкому наг*кодить - что угодно только не руби.
> была слабая поддержка у IDEЭто вы про RubyMine или про VIM?
Про vim или emacs, очевидно же. Это они синтаксисы парсят мешанинами регекспов, и при достижении определённого уровня сложности парсера, дальнейшие изменения в него не принимаются, потому что любое изменение неизбежно увеличивает количество багов, даже если оно и исправляет какой-нибудь баг.
Практически всё, кроме полноценных IDE, парсят синтаксис регулярками. Как минимум для подсветки. Тот же VSCode использует грамматики TextMate, основанные на регулярках. Для кода, где строк длиннее пары сотен символов нет и недолжно быть, это тупо быстрее чем строить AST. Для автодополнения, да, строится AST.
чего-чего? что за сказки?
> Практически всё, кроме полноценных IDE, парсят синтаксис регулярками.Ну какбэ речь именно об IDE и идёт.
> Как минимум для подсветки.
Подсветки мало для минимума. Минимум должен ещё содержать идентацию, что я вручную что-ли пробелы с табуляциями буду отсчитывать в началах строк? Может мне ещё нужно помнить, как в данном проекте принято отступы делать -- табуляциями или пробелами, и если табуляциями, то ко скольки проеблам приравнивается табуляция? А идентация уже требует выделения блоков кода, типа функций, циклов и тп. Со всякими интересными эджкейсами, типа else if, который должен вести себя будто новый if на том же уровне вложенности, что и предыдущий, а не вложен в else. И вот здесь-то, сложность парсера на регекспах взрывается. И я спорить готов, что это будет медленнее, потому что придётся многократно проходится разными регулярками по одному и тому же коду, чтобы посмотреть, что сматчится, и чтобы с разными уровнями вложенности разобраться.
> Тот же VSCode использует грамматики TextMate, основанные на регулярках.
Я не знаю, как там эти грамматики техтмате выкручиваются. Но насколько я помню свой краткий опыт использования VSCode, он не умеет выравнивать строки за меня. По-моему именно поэтому я и выкинул его и не использовал больше никогда. Из чего можно предположить, он не знает структуру кода, ну и соответственно эти грамматики техтмате бесполезны.
Реально же, если всё что ты хочешь, подсветить строковые литералы да ключевые слова, то действительно, регекспов тебе хватит за глаза и за уши. Но если ты хочешь отличать определение функции от декларации переменной... в C++, лол, где `type_name whatisthis();` может быть как декларацией функции, так и созданием переменной... в этом случае, регекспами можно, если хорошо упорствовать, но это будет код, про который никто не будет знать, как он работает, потому что ты забудешь через две недели, а никто другой разбираться не будет. Ты в нём не будешь разбираться, даже если припрёт, выкинешь и напишешь заново.
> Для кода, где строк длиннее пары сотен символов нет и недолжно быть, это тупо быстрее чем строить AST.
Кого волнует скорость парсинга? Она не влияет ни на что. В 90-х может быть это и было важно, и то не из-за скорости, а из-за оперативки, необходимой для хранения AST. А вот лапшу из регулярок совершенно невозможно мейнтейнить, в отличие от полноценного парсера.
Регулярки используют только потому, что так проще. Поначалу проще. Легко взять и запилить MVP. Но за пределы MVP выйти, внезапно, сложнее.
> Но насколько я помню свой краткий опыт использования VSCode, он не умеет выравнивать строки за меня.Значит опыт был очень краткий. Он отдает выравнивание внешним утилитам. Сам отвечает за области, где эти утилиты применять. С учётом версий git. Естественно всё это настраивается совершенно по разному.
Надо же, ниже по ветке целая дисскуссия развернулась.
Я использовал RubyMine от Jet Brains, наверное самая удобная среда разработки или по крайней мере популярная. Но это все не имеет значения по сравнению с тормознутостью платформы, не тормозило бы, можно и в нотепад кодить если есть необходимость.
Корректный парсинг руби кода и его анализ затруднены неоднозначным синтаксисом языка, не вдавался в тонкости проблемы, не было времени.
Когда обнаружились тормоза, постановили считать это макетом и перенесли сервисы в голанг, и после этого все стало быстро.
А еще чуть после перенесли с голанга сервисы на C++ Asio + обвязка с БД, что нас полностью устроило.
> Некоторые участники восприняли действия Ruby Central как захват GitHub-репозитория, раннее контролируемого сообществом, в результате которого доступа лишились заслуженные люди, делом заработавшие свою репутацию и более десяти лет занимавшиеся сопровождением RubyGems и Bundler.Да не было там уже никакого контролируемого сообществом репозитория. Всё уже было под контролем и финансированием Shopify. Там произошёл такой же корпоративный захват разработки и сдвиг сообщества на уровень бесплатных разработчиков/тестировщиков, как в других unix- и linux-проектах. Как видим, лицензия тут никак не влияет. Что вокруг GPL, что вокруг BSD рано или поздно появляются коммерческие волки, если проект хороший, и начинают диктовать свои условия.
А разработчики Ruby лишь пытаются снизить корпоративное влияние. Так что, это битва между коммерсами-разрабами и оригинальными разрабами.
Другое дело, что Shopify сильно вложилась в разработку JIT-компиляции и подняла производительность RubyVM. В то время как остальные мирно почивали на лаврах, пока Ruby загибался. Сейчас он наоборот начал восстанавливать свои утраченные позиции. И не в последнюю очередь благодаря Shopify, которая весь свой бизнес построила на связке Ruby/Rails и C++, и заинтересована, чтобы Ruby не загнулся и стал лучше.
Так что я даже не знаю какую сторону выбрать. Основную команду, которые плыли по течению. Или зубастую корпорацию, которая развивала Ruby вместо основной команды, а потом заграбастала у неё и сообщества репу с джемами в свои ежовые рукавицы и начала устанавливать свои драконовские порядки.
Ведь в дальнейшем корпорации начинают заниматься монетизацией услуг. Выше кто-то упоминал платные репозитории. Вот к этому всё идёт с Shopify.Альтернатива в любом случае будет, независимо от исхода конфликта. Слишком уж хороши Ruby/Rails, особенно для стартапов и, для маленьких команд и одиночных разработчиков.
Сравнить можно только с Python/Django, но они показались мне менее удобны. Некоторые вещи приходилось добавлять руками, в то время как в рельсах всё делалось через набор инструментов. Правда, я давно сравнивал. Поэтому это лишь моё личное мнение, основанное на старых сведениях. Возможно, за это время (около 8 лет), джанга стала удобнее. По крайней мере я видел порты различных рельсовских джемов на Python. Но не знаю, насколько хорошо они встроены в экосистему джанги.
Забавно, что я раньше предпочитал ручную прозрачную работу, а не магическое волшебство, где не всегда можно точно понять, что произошло, и почему сработало именно так. Но удобство и скорость разработки на рельсах поменяла моё мировоззрение. А учитывая, что это fullstack, то лучших вариантов, годных для быстрой разработки прототипов, я не нашёл.
Всё-таки, в нашей реальности платят больше за скорость разработки. Потому что, пока ты там что-то напишешь цельное на плюсах, за это время концепт или изменится, или отомрёт.
Ты сначала заработай, уперевшись до упора в лимиты, а затем набирай команду, которая тебе быстро раскидает тормозные части по микросервисам, хоть на го, хоть на руст. Рубишная бизнес-логика никуда не денется. А дальше можешь хоть на голом васме работать.