+1 мова у портфель. Чому варто вивчити Ruby

Привіт! Мене звати Влад Ганкевич, я Software Engineer в SoftServe. До компанії я приєднався цього року, щоб стати Ruby-інженером.

До того я зовсім не знав цієї мови та навіть не міг уявити, на якому проєкті буду працювати. Чому так? Я прийшов в компанію на ретренінг-програму. Це такий інтенсив, де головна твоя робота — вчитися. І це саме робота, яка триває 8 годин у будні та повноцінно оплачується.

Таким чином, за два місяці Ruby стала третьою мовою, яку я опанував, і першою, яку я вчив через ретренінг-програму. Кілька років до цього я працював на PHP на одному проєкті, поки його ж не вирішили переписати на Go. Буквально в процесі треба було переключитися на Go, і в підсумку я використовував його ще близько року.

Проте якось у SoftServe мені порадили спробувати Ruby та запропонували пройти ретренінг. На мою думку, розробнику варто розширювати свій портфель знань, щоб створювати цікаві розробки та рішення, незалежно від мови, на якій вони написані. Тож я подумав, що Ruby буде хорошим доповненням для мене та почав проходити.

Я вчив Ruby не супер швидко, але був дуже вмотивованим через кілька факторів. По-перше, я прийшов в компанію саме на проєкт з Ruby, не вчивши її до цього. Це був челендж, який хотілося пройти. По-друге, мені була цікава ця мова. Я знав, що на ній створюються глобальні проєкти як GitHub, Airbnb, Kickstarter. Як я вчив мову, що у ній мені ще сподобалося, які переваги та недоліки та чи варто вчити Ruby, поділюся у статті.

Ruby is not dead

Перед тим як вчити щось, треба зрозуміти, чи це того варте. У випадку з Ruby, одразу можна потрапити на дискусії, де обговорюють, що ця мова вмирає. Я з цим не згоден. Наприклад, фреймворк цієї мови — Ruby on Rails — чудово себе почуває у списку найбільш популярних фреймворків та посідає у ньому 13 місце вже два роки поспіль. Мій досвід також показує, що поки мову будуть підтримувати, а проєкти на ній створюватимуться, то вона буде жити. Але звичайно, грає роль і кількість таких проєктів. Проте я зараз працюю в проєкті, який використовує Ruby для своїх рішень протягом останніх 20 років. Думаю, це досить велика цифра, особливо для такої помірно поширеної мови.

Процес вивчення: теорія та практика

На цей проєкт я потрапив після того, як пройшов ретренінг-програму. Її особливості — ти можеш прийти в компанію, вивчити необхідну мову для роботи і пройти технічне інтерв’ю, щоб потрапити на проєкт. Це здається трохи ризикованим, адже йдеш працювати навіть ще не знаючи, наскільки тобі сподобається працювати на тій самій Ruby. Разом з цим, це чудовий шанс спробувати щось нове, не втрачаючи дарма час, адже ти вчишся прямо на роботі.

Така навчальна програма тривала приблизно два місяці, і за цей час я опанував необхідні основи та набив руку. Такий результат реальний, якщо присвячувати всі робочі 8 годин навчанню. Якщо ж виділяти кілька годин на день після основної роботи, думаю, процес затягнеться не менш ніж на півроку.

Загалом перші два тижні я вивчав основи мови, її особливості. Про це багато розповідав координатор програми, а також ділився корисними статтями, книгами чи просто цікавинками. Наприклад, David A. Black, Joseph Leo III — The Well-Grounded Rubyist, Sandi Metz — Practical object-oriented design, Metaprogramming Ruby: Program Like the Ruby Pros, Hal Fulton — The Ruby. Новини та спірні питання ми обговорювали у спільному чаті. Тож можна було проговорити якісь складнощі чи просто дізнатися нові факти про мову.

Паралельно з цим треба було практикуватися. Для цього я вирішував задачі, які брав з HackerRank, CodeWars та Exercism — сервісів, де розв’язання задачі можна порівняти з іншими користувачами. Інколи це демотивує, бо можеш розписати все на 50 рядків, а хтось те саме зробить в 1. Але це той момент, коли треба просто рухатися далі. Порада, яку я зараз дав би самому собі на початку вивчення, — не засмучуватися через такі випадки. Вони лише говорять про те, що є над чим працювати та вдосконалюватися.

Так проходило два місяці інтенсиву — ми поєднували теорію та практику, з цим могли допомагати також ментори. Також паралельно ми мали свій пет-проєкт — розробляли новинний портал, який створювали за готовими мокапами. Це можна порівняти зі завданням на іспиті — демо, яке ми мали зробити за кілька тижнів до кінця ретренінг-програми. Показували, хто що встиг зробити та які геми використовували. Після цього ми мали ще трохи часу підготуватися до технічних інтерв’ю, щоб отримати свої проєкти.

Я був дуже добре підготовлений і мав сильну підтримку свого ментора, тому технічне інтерв’ю не було для мене складним. Зараз, вже на проєкті, я продовжую поглиблювати свої знання з Ruby. Адже з проходженням програми навчання не закінчується. Я чудово опанував основи і можу почати розбиратися в нюансах.

Ruby: що вже створили та де загалом використовують

На Ruby вже створили Airbnb, Github, Kickstarter. Мова широко використовується у вебі. Через те, що розробка на Ruby не потребує багато часу, вона добре підходить і для стартапів чи проєктів, де треба швидко показати результат. Створити MVP на Ruby можна швидше, ніж на Java.

Що я ціную в Ruby:

1. Обидва оператори if і unless в умовних виразах. Звичайно ж, можна використовувати if з протилежним значенням виразу, але використання unless зазвичай призводить до меншого числа помилок.

2. Гнучкість. Є купа способів зробити одну й ту саму задачу і отримати потрібний результат. Тільки сам розробник обирає, який спосіб йому буде комфортнішим.

3. Псевдоніми (alias) для вже створених методів, а також дужки (чи навпаки прибирати їх для методів).

4. Числа, символи, булеві значення і все інше є об’єктом. Це означає, що можна писати так і економити час:

«YOU SHOULD NOT ALWAYS USE CAPITALS» .lowcase
замість такої реалізації:

# PHP Code

strtolower («YOU SHOULD NOT ALWAYS USE CAPITALS»)

5. Duck typing — це чудовий підхід, який також до душі частині РНР-спільноти. Замість того, щоб заявити: «Аргумент повинен бути екземпляром класу, який реалізує FooInterface», в результаті чого у FooInterface буде метод bar (int $ a, array $ b), можна сказати інакше: «Аргумент може бути чим завгодно, лише б реагував на метод bar. А якщо не буде реагувати, то придумаємо щось ще».

6. Метапрограмування — це чудова концепція, що використовується в Rails, і ви також можете застосовувати її у своїй роботі. Основна ідея полягає в тому, що додаток чи скрипт, виконуючись, створює функції або методи «на льоту», а також викликає їх. Найпростішим прикладом метапрограмування можна вважати attr_accessor — метод, який визначає методи getter і setter для атрибутів класу. Приклад використання:

Class Message
    attr_accessor :header, :title
end

Прикладом реалізації може бути:

def self.attr_accessor(*names)
  names.each do |name|
    define_method(name) {instance_variable_get("@#{name}")} - getter
    define_method("#{name}=") {|arg| instance_variable_set("@#{name}", arg)}  - setter
  end
end

Інформації щодо метапрограмування дуже багато. Якщо цікаво поглибитися, дуже раджу книгу Metaprogramming Ruby: Program Like the Ruby Pros.

7. Велика кількість доступних гемів для всього, що тільки можна уявити.

Загалом за час, поки я програмую на Ruby, бачу, що ком’юніті досить активне. Наприклад, не так давно додали 3.0 версію, яка стала одним з наймасштабніших оновлень. Його готували ще з 2015 року. Завдяки цьому у мові додали інструментарій для типування RBS та паралелізм, а також вперше з’явився планувальник легких fiber-потоків Fiber#scheduler.

Продуктивність теж покращили, наприклад, вставка великих частин коду відбувається у 53 рази швидше. Повний список оновлень ком’юніті опублікувало на свої сторінці. З найсвіжішого — в липні вийшло оновлення безпеки.

Недоліки (куди ж без них)

Я виділив кілька недоліків. По-перше, наскільки хороший Ruby для написання коду, настільки ж і важкий для читання. Зрозуміти, що виконує той чи інший блок коду, буває важко.

По-друге, найбільший недолік Ruby — це швидкість виконання та проблеми з багатопоточністю. В нових оновленнях мови ці недоліки пробують усунути, і тільки час покаже, наскільки це вдасться.

Крім цього, бувають складнощі з варіативністю, коли одну задачу можна зробити 3-4 способами. Тоді важко обрати оптимальний.

Загалом мову критикували у різний проміжок часу за продуктивність, відсутність типізації та інше. Однак Ruby покращується і можливостей стає більше, тож деякі недоліки вже давно не актуальні.

Вчити чи ні

Ком’юніті зараз досить добре справляється з підтримкою Ruby, враховуючи, що воно невелике. Крім цього, воно залишається основним драйвером розвитку мови. Тому зважаючи на останні оновлення та досягнення, можна сказати, що Ruby буде жити та набирати обертів.

Для інженерів я б порадив хоча б ознайомитися з основами Ruby. Ця мова — цікавий досвід, який розширює кругозір. Вона має в собі елементи інших мов, що може допомогти у вивченні Python чи PHP.

Це працює також навпаки — ті, хто знають, наприклад, PHP, може бути легше опанувати Ruby.

Крім цього, Ruby — чудовий спосіб доповнити свій портфель, але я б не радив її як першу. Щоб оцінити всі радощі, які надає мова і її інфраструктура, потрібно попрацювати з чимось іншим, більш типізованим і менш динамічним, на мою думку.

👍НравитсяПонравилось11
В избранноеВ избранном6
LinkedIn

Лучшие комментарии пропустить

Ничего хорошего в руби и рельсах на сегодняшний день нет. Отдал ему много лет своей жизни. Поддержка и развитие только для галочки. Никто не внедряет туда что-то новое. Символы были нужны 20 лет назад, когда на серваке было оперативы в мегабайтах, а не гигах. Сейчас же это наказание, особенно при работе с АПИ. DSL — это просто изврат, лично для меня. Учишь не ЯП, а чьи-то подделия. Программисты на руби тащат в код сотни разных гемов, хотя можно обойтись парой строк кода, в большинстве случаев. В итоге убежал в ноду. Тем более я и фронт пишу, так что работаю в едином стеке. А все что про руби можно сказать и именно это и говорят, так это то, что «Руби еще не умер».

Чому варто вивчити Ruby

щоб потрапити в дружню команду рубістів з Дніпра

Як людина, яка пішла з Ruby в Go можу сказати, що рубі доволі прикольна мова, яка дуже яскраво сяяла приблизно з 2010 по 2013, коли здавалося, що Rails зараз покаже всім як робити фреймворки і все таке. Так воно і було, однак рубі зайняло свою нішу як мова для mvp. Треба було розвиватися далі, але як? Коли мова не має інструментів для розвитку у сучасному світі. Коли почався повальний перехід з монолітів на мікросервіси рубі комьюніті все ще писало на Rails моноліти (бо тягнути Rails до мікросервісу — ну це жорсткий оверхед), коли почався тренд статичної типізації у рубі зробили sorbet — типу лібку для тайп чекінгу, в той час, як з’явився typescript та тайп чекінг як частина python. У мові майже відсутні засоби для профайлінгу та покращення перформансу, та і цим перформансом особливо ніхно не париться. Про багатопоточність взагалі мовчу, ось тільки у 3й версії підвезли актори, які, як на мене (після Go) виглядають просто смішно, проте, якщо об’єктивно, знаходяться приблизно на рівні async в пітоні — трохи тупо, незручно, іноді фейспалмно, але жити можна. Читати код на рубі... Це може бути ще той челендж, я взагалі не розумів, як люди відкривають сорци бібліотеки і щось розуміють... Доки не перейшов на Go (такої проблеми більше нема). Тоді стало просто очевидно, що метапрограммування, яке там з усіх щілинввилазить, це реальна проблема, бо неможливо зрозуміти як твоя складна програма буде працювати. Додайте до цього практичну відсутні тулінгу, націленого на інженера, наприклад, немає жодної ide, яка б хоч якось нормально підказувала, а не просто розмальовувала код. І моє найбільш улюблене, окрім того, що в мінорних релізах можуть запросто зламати backward compatibility, це те, як розвивалася мова. З рубі 2.3 (2015 рік) до 2.7(кінець 2019) не змінилося приблизно нічого, окрім JIT. Тобто, у нас в мові є реальні проблеми з перформансом, використанням системних ресурсів, особливо RAM і так далі, а ми за майже 5 років зробили 5 чи більше нових операторів для обертання сферичного коня в вакуумі і JIT. Звісно, десь рік тому вийшла версія 3.0, яка додала акторів, та, нарешті типізацію у мові. Але мій фаворит — це картинка (www.ruby-lang.org/...​2/25/ruby-3-0-0-released), де вони порівнюють рубі 3 (кінець 2020) і рубі 2.0( початок 2013) і кажуть, у нас перформанс в 3 рази більший... Після 8 років... Ну так, це «велике» досягнення. За 8 років то... Ух!
В якості завершення скажу, що, на мою думку, рубі стогнує вже з року так 2013, а то і раніше, тому я би не рекомендував його вивчати, особливо, як першу мову. Ні з академічної точки зору, ні з професійної. Реальна цінність рубі в його метапрограммуванні, яке одне з найсильніших серед інших мов, проте це ж і найбільша слабкість мови. На сьогодні python та typescript почуваються краще та більше перспективніше, ніж рубі. Схоже на те, що рубі поступово стає таким собі хаскелем, котрий цікаво потикати палочкою, подивитись на його концепції, але писати на ньому щось в продакшн — ні дякую.

У вас вже є досвід переписування з PHP на Go, ймовірно буде переписування з Ruby на Go.

Тому що Ruby On Rails це найкращий веб фреймворк з чудовим DX та швидкістю розробки.

На ньому приємно працювати.

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

softwaredoug.com/...​y-vs-python-for-loop.html
Цікава стаття, про відмінності Python та Ruby — „So much of how Ruby and Python differ comes down to the for loop.”

Вчив після php рубі, не зрозумів нащо така мова як рубі взагалі існує і які задачі вирішує. В неї немає жодної сильної сторони

не зрозумів нащо така мова як рубі взагалі існує

$тримай $в $курсі

Чекав що набіжать рубісти щоб розказати про переваги рубі

переваги рубі

Щоб було з чого копіювати Laravel, очевидно ж! :)

для начинающих точно не стоит. на жсе, питоне, жабе или дотнете гораздо больше шансов найти работу.

Стаття з оглядом фіч які з’явилися в Ruby нещодавно: Where is Ruby Headed in 2021?

These new features seek to reduce the distance between Ruby and other languages: to gain some of the type safety of statically-typed languages, the I/O throughput of async languages like Node, and the parallelism of channel-based languages like Go. But there are several factors that limit how far Ruby can go in these directions. The first is compatibility: the core team doesn’t want to break existing Ruby programs if at all possible. The second limiting factor is language design: Matz called Ruby a human-oriented language, and although type safety and performance are being prioritized, they won’t be pursued in a way that compromises what the core team sees as Ruby’s human-oriented design.
The point of these language improvements is not that they erase the advantages other languages have. When the most important factor in your system is I/O throughput, multicore processing, or type safety, you wouldn’t want to choose Ruby from the start: you would want to go with a language like Node, Go, or Haskell respectively.

Я когда-то пробежался глазами по синтаксису, и особо не нашёл причин её изучать. Ну синтаксический сахар, но чего-то нового, чтобы изменяло сознание, ... не нашёл :)

Ну початок статті звичайно цікавий — треба довести що Ruby ще не здох))

Колись на фрілансі в 2015 році отримав проект, який називався «Convert Ruby app to Java»
По великому рахунку в апці було 10-15 табличок, стандартні круди, геттери/сеттери + можливо з два десятка АРІ запитів
Вже не згадаю точно, але тоді ще було дофігіща проектів на spring-у з всякими web.xml і т.д. Spring Boot тільки недавно вилупився на цей світ
Але що мені запамяталося — наскільки в RoR аплікації все було neat-ово для того, щоб побудувати простий АРІ, особливо всякі дженерік круди. В джаві мені прийшлось зробити декілька рівнів абстракцій і всякі Class> для того, щоб замінити декілька речей, які в рельсах прописувались в якихось конфігах
Хоч в результаті мені здається, що ця найбільша перевага виявилась і найбільшою проблемою, що спонукала замовника переписати проект на Java :)

Ruby мав померти ще у 2005 разом з Perl та Tcl. Через Ruby on Rails агонія затягнулася.

Багато років тому мав справу, вже навіть забув для чого, для якогось скриптингу на проєкті юзався — мова як мова. А оце нещодавно зіштовхнувся з Vagrant, він там для конфігів використовується, і зацінив. Не знаю як для вебу, а для цього — дуже зручна виявилася штука. Такий собі гнучкий Perl з людським обличчям на якому справді зручно писати (на відміну від Python який не знаю, не зайшов чомусь)

Колего! В мене також з пітоном чомусь не складається. Думаю, він не здох виключно через NumPy.

Через pyspark та pandas і численні бібліотеки для ds & ml

Ну я ж узагальнив. Але з NumPy все почалося.

Гарна стаття
Трохи надкритична, бо більшість претензій легко вирішуються чи просто перебільшені
І я навіть згоден з абзацем What Would Make Python Tolerable

Тільки от якщо все буде поліпшено, то це буде інша мова з іншою кривою входження
Або це буде луа чи го

Лучше Rust или Haskell учите, сможете смарт контракты писать под Cardano, Solana и тд, там рейты от 100$ в час стартуют.

можно поподробнее про 100$ в час рейты? И количество заказчиков

И цена ошибки на 50 млн баксов как в Дао было.
И откатить\пофиксить ничего нельзя, только форкнуть всю блокчейн цепочку создав свою «классик» валюту. Нехай щастить.

В solana можно редеплоить смарт контракты))

«То, что мертво, умереть не может» ©

«Панк не умер, он просто так пахнет» ©

В треді парад людей які все життя страждають та ніколи не писали на фреймворку та мові яка зроблена для людей а не для комп’ютерів.

Їх можна зрозуміти—це той самий випадок несвідомої некомпетентності. Поки не почнеш писати то не зрозумієш наскільки Ruby в цілому та Rails в конкретному крутіше ніж практично всі популярні інструменти які пропонує нам ринок.

той самий випадок несвідомої некомпетентності. Поки не почнеш писати то не зрозумієш наскільки Ruby в цілому та Rails в конкретному крутіше

А есть ещё ряд людей, которым просто не «заходит» подход с convention over configuration и неведомой «магией» под капотом. И не из каких-то там «религиозных» соображений, а потому, что на своём печальном опыте неоднократно убеждались, что инструмент, отлично подходящий для задачи «быстро склепать MVP», потом превращается в головную боль, как только возникает необходимость выйти за рамки сценариев использования, предполагаемых авторами.

Помнится, такие же песни в 2000м году пели про ColdFusion. Да, для своих задач он был вполне неплох, но так и не вырос из «штанишек» конструктора «слепи сайт по-быстрому без регистрации и СМС».

потом превращается в головную боль, как только возникает необходимость выйти за рамки сценариев использования, предполагаемых авторами.

А ви робили проекти на Rails? Які проблеми у вас виникали?

В мене просто вже давно купа проектів працює та гроші приносить і я не мав жодного головняка, от цікаво чого ж людям не вистачає, до того ж від Rails все що можна відстібнути відстібується без проблем, хотілось би дізнатися що за такі зарамочні сценарії.

Як людина, яка пішла з Ruby в Go можу сказати, що рубі доволі прикольна мова, яка дуже яскраво сяяла приблизно з 2010 по 2013, коли здавалося, що Rails зараз покаже всім як робити фреймворки і все таке. Так воно і було, однак рубі зайняло свою нішу як мова для mvp. Треба було розвиватися далі, але як? Коли мова не має інструментів для розвитку у сучасному світі. Коли почався повальний перехід з монолітів на мікросервіси рубі комьюніті все ще писало на Rails моноліти (бо тягнути Rails до мікросервісу — ну це жорсткий оверхед), коли почався тренд статичної типізації у рубі зробили sorbet — типу лібку для тайп чекінгу, в той час, як з’явився typescript та тайп чекінг як частина python. У мові майже відсутні засоби для профайлінгу та покращення перформансу, та і цим перформансом особливо ніхно не париться. Про багатопоточність взагалі мовчу, ось тільки у 3й версії підвезли актори, які, як на мене (після Go) виглядають просто смішно, проте, якщо об’єктивно, знаходяться приблизно на рівні async в пітоні — трохи тупо, незручно, іноді фейспалмно, але жити можна. Читати код на рубі... Це може бути ще той челендж, я взагалі не розумів, як люди відкривають сорци бібліотеки і щось розуміють... Доки не перейшов на Go (такої проблеми більше нема). Тоді стало просто очевидно, що метапрограммування, яке там з усіх щілинввилазить, це реальна проблема, бо неможливо зрозуміти як твоя складна програма буде працювати. Додайте до цього практичну відсутні тулінгу, націленого на інженера, наприклад, немає жодної ide, яка б хоч якось нормально підказувала, а не просто розмальовувала код. І моє найбільш улюблене, окрім того, що в мінорних релізах можуть запросто зламати backward compatibility, це те, як розвивалася мова. З рубі 2.3 (2015 рік) до 2.7(кінець 2019) не змінилося приблизно нічого, окрім JIT. Тобто, у нас в мові є реальні проблеми з перформансом, використанням системних ресурсів, особливо RAM і так далі, а ми за майже 5 років зробили 5 чи більше нових операторів для обертання сферичного коня в вакуумі і JIT. Звісно, десь рік тому вийшла версія 3.0, яка додала акторів, та, нарешті типізацію у мові. Але мій фаворит — це картинка (www.ruby-lang.org/...​2/25/ruby-3-0-0-released), де вони порівнюють рубі 3 (кінець 2020) і рубі 2.0( початок 2013) і кажуть, у нас перформанс в 3 рази більший... Після 8 років... Ну так, це «велике» досягнення. За 8 років то... Ух!
В якості завершення скажу, що, на мою думку, рубі стогнує вже з року так 2013, а то і раніше, тому я би не рекомендував його вивчати, особливо, як першу мову. Ні з академічної точки зору, ні з професійної. Реальна цінність рубі в його метапрограммуванні, яке одне з найсильніших серед інших мов, проте це ж і найбільша слабкість мови. На сьогодні python та typescript почуваються краще та більше перспективніше, ніж рубі. Схоже на те, що рубі поступово стає таким собі хаскелем, котрий цікаво потикати палочкою, подивитись на його концепції, але писати на ньому щось в продакшн — ні дякую.

У мові майже відсутні засоби для профайлінгу та покращення перформансу, та і цим перформансом особливо ніхно не париться.

Це при тому що в Rails ще з бородатих років по-дефолту увімкнені логи SQL запитів та всіх таймінгів які дозволяють легко побачити та виправити 99% потенційних проблем—такого немає в жодному фреймворку.

Додайте до цього практичну відсутні тулінгу, націленого на інженера, наприклад, немає жодної ide, яка б хоч якось нормально підказувала

Кек, Idea чудово все показує.

О, ну тепер заживемо, по логах перформанс міряти, особливо з купи інстансів. А, ну так, моноліти же ж.

Про ідею: спробуйте зробити go to definition на методі, який має доволі generic ім’я, типу get або save, скажете потім скільки варіантів висввтилося. Потенційний nil pointer — теж проблема

ХЗ для ms sql есть sql management и в нем профайлер который предоставляет кучу инфы по логгированию запросов в скл, при этом запрос все равно тюнить в этой же менджмент студии а без нее ты ничего не увидишь(запрос то в сиквеле а не в фреемверке выполняется).
А время выполнения сторчки кода в вижуал студио показывает просто в самом коде в режиме дебаг и никаких фреемверков не надо.

Я думаю ти не дуже розумієш про що я кажу, бо на тексті це може бути неочевидно. Я планую робити презентацію «Spring Boot vs Ruby on Rails» де всі ці моменти наочно поясню.

ХЗ для ms sql есть sql management

В mysql теж є slow queries log і можна його дивитися але це зовсім не те.

Вова имеет в виду показ самих SQL запросов, которые сгенерила ORMка, и общего времени их выполнения. Я такое и в каком-то из PHPных фреймворков видел, причём тулбар с показом всей отладочной инфы показывается внизу самого Веб-приложения.

Штука прикольная, да, но лично для меня не выглядит киллер-фичей. Бороться с долго выполняющимися запросами приходилось не так уж и часто, чтобы для этого было недостаточно «родных» инструментов СУБД.

Епт, ну так скл профайлер же все это и показывает, перехватывает запросы котрое генерит твоя приложуха(хоть орм хоть смописный dal) и показывает тебе живой скл запрос в базу и там же время выполнения...Что так такого магического? Причем никаких фреемверков не надо. Можно даже настроить фильтра всякие чтобы профайлер не выкидывал все запросы, которых может быть много, можно подключаться к разным энвам и там мониторить запросы и прочее.

Ну и внизу странички время запроса это туфта а не инфа, тормозить может не скл, а говнокод который мапит данные из таблицы, конекшен тормозной и дата сет оч большой...причин море...И в любом случае нужно влазить в отроха кода и скл квери план смотреть чтобы погимать где индыксы присунуть например...

А время исполнения строчки кода в видуал студио показывает прям возле этой самой строчки в дебаге, шаг за шагом показывает сколько ушлов времени...

И в самом скл сервере можно отдельно логи базы шерстить через эту же менджмент студио, вобщем я все также без дупля в чем магия этого фреемверка.

Штука прикольная, да, но лично для меня не выглядит киллер-фичей.

Така штука не одна, їх багато та в сумі вони дають 100х-кращий developer experience ніж будь що інше.

Про багатопоточність взагалі мовчу

Вот только jruby и прочие рубиниусы много лет в production-ready состоянии — если бы «проблема многопоточности» была такой глобальной как о ней любят вещать хейтеры (зачастую еще и не всегда отличающие конкаренси от параллелизма), то какая-то из реализаций без GIL уже давно бы зохватила вершину горы. Но этого не происходит почему-то. Возможно потому, что в типичных юзкейсах где применение руби целесообразно, это не самый решающий фактор?

і кажуть, у нас перформанс в 3 рази більший... Після 8 років... Ну так, це «велике» досягнення. За 8 років то...

Хейтеры такие хейтеры. Чтобы вырасти в три раза за 10 минорных релизов, нужно с каждым минорным релизом улучшать перформанс на примерно 12% в среднем (ваш кэп). А теперь добавь сюда необходимость сохранить полную обратную совместимость и получится что то, что ты обесцениваешь своими кавычками на самом деле охрененно проделанная работа, которую еще попробуй повтори...

Справа не в хейті, а в об’єктивній оцінці ситуації. Наразі у рубі немає жодної переваги перед іншими мовами, а мейнтейнери не дуже поспішають щось робити: або стогнують або наздоганяють інші мови.
Стосовно багатопоточності та канкаренсі: до 3.0 не було жодного з них у рубі, завезли акторів — аля канкаренсі вже щось. Багатопоточність сьогодні надає доволі сильний буст в оптимізації роботи для широкого кола юзкейсів, але найбільше впливає її наявність, що коли треба зробити грамотно і швидко все, то тут можна на пустому місці отримати крутий буст із нічого. Нагадаю ще, що зараз вже немає одноядерних процесорів взагалі.
Стосовно перформансу: ну серйозно, порівняйте перформанс будь-якої мови за 8 років, там будуть схожі результати.
JRuby... І багато його використовують? Знаєте чому ні? Бо є мови з більш зручною системою багатопоточності та ще й з канкаренсі зверху

Справа не в хейті, а в об’єктивній оцінці ситуації... Стосовно багатопоточності та канкаренсі: до 3.0 не було жодного з них у рубі

Для объективной оценки ситуации желательно все же знать матчасть, а вы ее очевидно не знаете: многопоточность в руби есть со времен царя гороха, и в реализациях без GIL потоки в руби параллелятся из коробки. Но даже в MRI в отдельных I/O-тяжелых сценариях многопоточная архитектура может дать кратный буст... Я так понимаю ваше знакомство с руби ограничилось шапочным знакомством с рельсами?

тут можна на пустому місці отримати крутий буст із нічого

А можно и не получить — если задача не параллелится по своей природе... Это бессмысленный разговор вне контекста конкретной решаемой задачи.

Ще раз, чи багато ви бачили, щоб хтось використовував НЕ MRI? Скільки це відсотків від усього рубі комьюніті? 1?
Стосовно тредів: так, можна заспавнити треди, і, навіть, процеси, але на скільки це зручно? Які є механізми синхронізації? Скільки справжніх багатопоточних програм ви бачили? Не рахуючи, наприклад, http сервери, а так, щоб інженер сів і написав сам щось для бізнесу?
Чомусь ніхто не обирає рубі як мову для серйозних багатопоточних задач.
Ну і взагалі об’єктивно, станом на сьогодні, немає жодної причини обирати рубі для нового проекту.
Швидкість розробки — вже усі інші мови давно наздогнали: нода, спрінгбут, пітон, та навіть го, а ще не забуваємо про php.
Зручність написання коду — я б не сказав, те що можна одну операцію зробити 5 способами така собі перевага. Читати код може бути доволі складно, як я вже казав: метапрограммування та інше.
Швидкість роботи — будемо чесними це не про рубі, а об’єктивно, він приблизно на рівні з іншими скриптовими мовами.
Туди ж і використання системних ресурсів.
Людей знайти важче, ніж на джаву, пітон чи js.
То чому б мені обирати рубі для наступного проекту? Після майже десятиріччя стогнаціі мови, звісно важко відповісти на це питання

Стосовно тредів: так, можна заспавнити треди, і, навіть, процеси, але на скільки це зручно? Які є механізми синхронізації?

О, ну наконец-то мы выяснили очевидное — оказывается, многопоточность в руби есть, просто «не такая». Ну ок, хоть что-то.

Скільки справжніх багатопоточних програм ви бачили? Не рахуючи, наприклад, http сервери, а так, щоб інженер сів і написав сам щось для бізнесу?

Так а почему не считая-то? Многопоточные пума и сайдкик — одни из самых популярных решений в руби песочнице. Не странно ли для ЯП в котором «нет многопоточности»? Касательно «чтобы инженер сам написал» — да без проблем, если задача того требует. Таких задач немного, но они есть — интеграции с внешними системами (не транзакционные, а когда нужно буквально синхронизировать большие массивы данных), парсеры и вообще любые I/O-bounded задачи. Понятно что срендестатистический кодерок с ними сталкивается относительно редко, но это возвращает нас к вопросу типичной области применения, а не к возможностям языка как вы пытаетесь доказать (недоказуемое).

Швидкість розробки — вже усі інші мови давно наздогнали...Швидкість роботи — будемо чесними це не про рубі, а об’єктивно, він приблизно на рівні з іншими скриптовими мовами.

Внимательно перечитайте свою аргументацию. Вы заметили, что вы много раз повторили «на уровне», но при этом продолжаете гнуть линию «руби не нужен»? В песочнице многокритериальной оптимизации есть такое понятие как «оптимальность по Парето» (и оттуда же «множество недоминируемых альтернатив») — ну вот это практически оно. У вас есть выбор из нескольких ЯП, в равной степени применимых для данного класса задач, каждый из которых в чем-то превосходит конкурентов, в чем-то уступает. То есть любой выбор будет определенным компромиссом и пессимизацией одних критериев в пользу других. Весь остальной хейт — банальная предвзятость.

Чомусь ніхто не обирає рубі як мову для серйозних багатопоточних задач

Цікаво, що воно таке «серйозні багатониткові задачі»? Там де я бачу щось серйозне, там і його скриптові конкуренти не сильно-то обирають. Ті ж OpenCV, OpenCL такого типу, мають плюси під капотом, з якогось там Python хіба опціональний фронтенд, один з.

Багато з чим не згідний.

> коли почався тренд статичної типізації у рубі зробили sorbet

Ви самі ж потім згадуєте нативний RBS, тому дивне порівняння.

> У мові майже відсутні засоби для профайлінгу та покращення перформансу

Як мінімум RubyMine має вбудований профайлер, чи він хороший чи поганий не знаю. Про швидкодію незрозуміло — програма сама себе не оптимізує в жодній мові.

> я взагалі не розумів, як люди відкривають сорци бібліотеки і щось розуміють...

Як в будь-якій мові, до чиєї ідіоматики треба звикнути.

> метапрограммування, яке там з усіх щілинввилазить, це реальна проблема, бо неможливо зрозуміти як твоя складна програма буде працювати

Зазвичай, проблема виникає тільки у власному коді проєктів, де метапрограмування використали недоречно.

> немає жодної ide, яка б хоч якось нормально підказувала, а не просто розмальовувала код

Хіба це не стосується всіх динамічних мов? Той же RubyMine вже розуміє RBS, тому надіюся, що питання тільки в оновленні екосистеми.

> окрім того, що в мінорних релізах можуть запросто зламати backward compatibility

Звучить, як вигадка :)

> не змінилося приблизно нічого, окрім JIT

Тобто JIT це дріб’язкова потуга?

> і кажуть, у нас перформанс в 3 рази більший... Після 8 років...

Ви ж не очікуєте, що розробники винайдуть нові закони фізики й посунуть алгоритмічну стелю можливого.

Той же RubyMine вже розуміє RBS

+

Есть еще такая штука как YARD/rdoc в сигнатурах методов(да и просто в любом произвольном месте) — @type @param @option @return @raise и прочими тайп хинтами которые дают очень удобный и продвинутый автокомплит но этим почему-то очень мало рубистов пользуются.

но этим почему-то очень мало рубистов пользуются

Потому что мало рубистов пользуются IDE?

Вот из обработанных скриптом результатов опроса 2019-го года на StackOverflow (грубо, ибо там в один пункт намешаны по многу языков и редакторов без чёткой корреляции, но общую картину даёт):

290.763402 — VS Code
256.679824 — Vim
191.220876 — Sublime Text
123.898133 — Atom
85.598129 — IntelliJ
67.549815 — RubyMine
50.632506 — Emacs
47.935964 — Visual Studio
44.175606 — XCode
43.630965 — Notepad++

Схоже на те, що рубі поступово стає таким собі хаскелем,

Скорее перлом.

Створити MVP на Ruby можна швидше, ніж на Java

Але чи швидше ніж на Groovy/Grails? ;-)

Хз, я думав шо цей кусок нода зїла вже давно о_0

А Нода вже вміє більше ніж 1 кор юзати? :D

Модуль worker_threads. Стабилизирован еще в 11-й версии.

2018-10. Too little too late.

Але добре хоч так

Play Framework v1 робив в Java те ж що робить NodeJS ще в 2008-му. А потім з’явились VertX, RxJava, Project Reactor і т.д.

Play Framework v1 робив в Java те ж що робить NodeJS ще в 2008-му. А потім з’явились VertX, RxJava, Project Reactor і т.д.

согласен, технически JVM очень хорошо. Сам люблю, в том числе Java. НО мне видится, что nodejs стал развиваться так активно и массово по совсем не технической причине:
Он появился как ответ на задачу «как нам дать в руки ребят с компетенцией JS для браузера» инструмент для разработки backend и при этом вот минимально доучивать. И с этой точки зрения он отлично справился с задачей, максимально эффективно использовав разработчиков, при этом дав в руки относительно приемлемый тех. инструмент !

Тобто задача — економити, наплодивши full stack (fool stuck :-) ) девів, які і швєц, і жнєц, і на дудє іґрєц (ще по ops частині піднатаскати і взагалі один взаємозамінний гвинтик на всі випадки).

Жадібно-утопічна ідея, яка зводиться до того що одна людина буде добре розбиратись в декількох різних напрямках одночасно. Але в певних кейсах мабуть таки економить гроші — не сперечаюсь.

Жадібно-утопічна ідея

кількість вакансій — фулстек Java+React/Angular, C#+Angular наводить на думку що
Антон Кекс — The world needs full-stack craftsmen
youtu.be/qd9N9eU1Qn0

може щось знає?

а для php — Laravel+Vue — то більшість вакансій

так що Нода — відгризатиме і надалі сфери де була тільки Java та C#
та й пітон з пхп — те ж :)

З Java та C# буде теж саме що й з С++, який вони витіснили.
Звісно, для сапорту потрібно буде ще довго чимало програмістів.

Але я вже зараз коли бачу як стартують нові проекти на них перепитую:
Вам точно потрібні збільшені терміни розробки, та купи недешевих джавістів/дотнетчиків? До яких, звісно, треба буде ще додавати фронтендерів на реактах з ангулярами?
А чули ви такі словосполучення — «дефіцит програмістів», «ринок кандидата»?

ну ок, як конче необхідно — то уперьод!

Play Framework v1 робив в Java те ж що робить NodeJS ще в 2008-му.

і там і залишився, у «2008ому» а на Ноді пишуть зараз :)

я пам’ятаю той хайп по ньому. :)
було ж очевидно що фреймворк на Scala аж ніяк не зможе конкурувати на рівних з рельсами, а потім з джангами та ларавелами.

«З Java та C# буде теж саме що й з С++, який вони витіснили.
Звісно, для сапорту потрібно буде ще довго чимало програмістів.

Але я вже зараз коли бачу як стартують нові проекти на них перепитую:
Вам точно потрібні збільшені терміни розробки, та купи недешевих джавістів/дотнетчиків? До яких, звісно, треба буде ще додавати фронтендерів на реактах з ангулярами?
А чули ви такі словосполучення — „дефіцит програмістів“, „ринок кандидата“?
»

Фу,оце низькорівнева пропаганда. За джаву не знаю, а ось шарп з нет 6 супер популярні і купа молоді їх вивчає тепер. Також новий .Нет лідер по улюбленим фреймворкам. Доки пхпсти живуть надією що нет загнеться, він стає кросплатформенним і мультифункціональним. Пхпште собі далі інтернет магазини і не заважайте серйозним дядькам що пиляють Нет.

а ноджсники типу дешеві?

Один фулстек — дешевший за двох спеців, та ще й економія на менеджменті виходить.

А далі фактор — швидкість розробки.

Звісно, є фактори які можуть бути вагомішими за названі

фулстеки є і з джавою і з шарпом, часто дешевші ніж з ноджс

звісно що є.

а от чи дешевше... суто середній бекендер джавіст так, шидше дешевше фулстек нодера, аніж дорожчий
а от фулстек джавіст — сумніваюсь що в середньому дешевше

і далі — треба ж рахувати скільки за однаковий проміжок часу видасть нодщик та джавіст. та скільки треба нодщиків, а скільки джавістів щоб «вкрутити лампочку»
це важко, бо дуже залежить як від проекту, так і від кваліфікації.

життя россудить :)
наприклад php хейтят усі, від народження, а він живе. і тілько нещодавна TIOBE зафіксували що здається випаде з 10ки. Пітон та Джс його вишхтовхують.

А що «тру програмісти» кажуть про Джс? ;)

З Java та C# буде теж саме що й з С++, який вони витіснили.

Та Рубісти вже десь 10-12 років тому казали що зараз Рубі всіх закопає, ховайте свою Джаву. От все чекаєм ;-)

Я й тоді посміхався такої їх наївності :)
Потім скалісти було теж, казали що всі з джави побіжуть на скалу

Джаву закопує не якась конкретна мова, а головний тренд з 60-их — швидкість розробки. І коли те з чого реготали розвивається, але зберігає цю перевагу — то й маємо.

Джаві звісно ніщо не загрожує, ніхто переписувати з неї не буде. з коболу навіть не все переписано і не планується.

Мова про те що обирати її для проекту — сенсу меншає с кожним роком

О, знову ця шарманка — Джава це Кобол! Точно те саме що 10 років тому казали, слово в слово. Я вже думав це з моди вийшло — але схоже це останній аргумент на всі часи :D

Ну так, який-небудь Spring Boot зовсім не пришвидшив розробку, так тєжко на Джаві писати просто амба — дайте Рубі з рельсами, бо Groovy з Grails-ами то тєжко...

Так Джава і є сучасний кобол :) що змінилося за оті роки?

Звісно спрінг бут пришвидшив розробку. Тільки з чого ви вирішили що тільки в Джаві з’являються інструменти та підходи що її пришвидшують :)

І де я казав про тяжко писати? Не тяжко. Джава проста мова.
Просто більшає кейсів коли так само не тяжко але швидше писати на іншій мові.

і там і залишився, у «2008ому» а на Ноді пишуть зараз :)

Nope, не залишився — був і Play 2, але там зробили ставку на Scala, але на Scala конкурентом Play стала Akka. Play 1 був на Java, там Scala не було взагалі.

було ж очевидно що фреймворк на Scala аж ніяк не зможе конкурувати на рівних з рельсами

А, ну так — Фортнайт на Akka з 250 мільйонів юзерів це ніщо, от на рельсах 250 мільйонів юзерів тягне... щось тягне?

Залишився, бо використання Play маргінальне навіть у Джава світі.

А те що на Джаві не можна написати драйвер відеокарти, ніяк не зашкодило її поширенню.
це я до вашого аргументу блондинкі про 250 мільйонів юзерів.
Який відсоток програмістів світу задіяно у таких проектах? Я чув що там буває замість джави і с++ та rust використовують. Бо джава тормозить та пам’ять жере занадто ;)

То як зашкодила тормознутість джави та любов JVM до пам’ яті?

Іншими словами ви використовуєте ті ж самі критерії що застосовувались критиками Джави.
То може ці аргументи протухли, щоб на них щось обгрунтовувати, нє?
Ну якщо вони не спрацювали у бік джави, то чому вони спрацюють у бік «пітонів, пихів, рубі, нод та го»

використання Play маргінальне навіть у Джава світі

Ах ці маргінали з LinkedIn...

Тобто ви не розумієтеся на різниці між поодинокимі випадками та середніми значеннями.
не бачу тоді сенсу обговорювати технічну тему з гуманітарієм

середніми значеннями

А на основі яких даних ви розрахували своє «середнє значення»? Ви маєте інсайди у всіх великих і середніх компаніях і можете точно сказати хто що де і скільки використовує? Заздрю!

Для цього треба не інсайди а статистика. І вона є, публічна. Гугл вам у поміч.

Статистика на основі чого? Опитувань на Stackoverflow?

На купі всього. Від аналітики по вебу, до досліджень трудових ресурсів.
Все є в інеті.
Опитування на будь якому сайті, то вже такє собі, хоча теж можна додати до більш вагомої.

Те що чимало колег носа не висовують з нори свого особистого досвіду, мене не дивує. Як і те що такі впевнені що по іншому і не буває «всі в норі як Я!»

Гугліть та думайте. За вас це ніхто не зробить.

Все є в інеті

Заява в дусі «по телевізору сказали». Яке джерело? Де саме «в неті»?

Навіть на доу дещо є з того, вам невідомого інтернету :)
Відкрийте для себе той всесвіт аналітики по айті як галузь :)

Тобто джерел навести ви не можете. Зрозуміло.

Їх повно. Якщо ви попрацюєте головою — то самі швидко знайдете. А як не можете шукати відповіді у аналітичних дослідженнях — то вони, ці джерела вам не допоможуть.

Ви ж в айті не перший рік, чи не так? А вимагаєте дати «вам лінк на вікіпедію» :)

А ви на волі перший рік мабуть, до цього в жовтому будинку проживали.

«В Інтернеті є» це те саме що «по телевізору сказали», без вказання каналу і програми.

Статистика в кожного своя, на біс зна чому заснована, і у всіх відрізняється. Хочете послатись на якусь конкретну то мусите навести посилання.

В ВНЗ писали колись хочь якісь роботи? Посилання на джерела в них наводили, чи просто писали «загальновідомо що ...»? Не довчили вас там я бачу.

Навіть на згаданій вами Вікіпедії обов’язково мають бути посилання на джерело інформації — інакше модератори потруть вашу «отсєбятіну». FYI

Покажу вам приклад як треба. Бо бачу ви просто не вмієте.

Берете конкретне посилання.
Наприклад en.wikipedia.org/...​_in_most_popular_websites (на Вікіпедію до того ж — все як ви хотіли :D )

Вказуєм конкретний розділ чи секцію — як от «Back-end (Server-side) table in most popular websites» в цьому випадку.

І вказуєм що там суттєво для суті розмови. В нашому випадку те, що Ruby використовують лише 2 компанії (Twitter та Facebook), а Scala — 4 (ті ж самі + Ebay та LinkedIn). Тобто в два рази більше.

Отже Ruby програє конкуренцію Scala, всупереч вашим голослівним заявам. Доведено статистикою, все як ви хотіли :-)

А далі ще згадуєм що ні Фортнайт ні Нетфлікс сюди взагалі не попали ;-)

Вчіться як треба.

ок, нехай я залишусь йолопом та повним бовдуром :D

На Netflix теж є Рубі )
www.youtube.com/watch?v=L7Q2e0i2osc

І ще в багатьох — багатьох відомих компаніях) Тому думаю, років 10 ще буде багато роботи, а судячи по коментах, знаходити людей буде все важче і важче.

250 мільйонів юзерів це ніщо

І це справді абсолютне ніщо. Бо PHP тягне 1млрд юзерів фейсбука. Відповідно що — правильно, PHP у 4 рази кращий за Akka.

Вам не надоїло міфи поширювати? В Фейсбука не PHP — в них не Zend рушій, і ті залишки похапе це як псевдокод.

Ну тобі ж не набридло поширювати міфи про 250кк, коли по факту було 13 млн і при тому заздалегідь відомо що буде надзвичайно високе навантаження.

twitter.com/...​/1253524351376330752?s=20
13 млн юзерів в один момент часу. Те що ти сюди тягнеш ми вже з’ясували, що в такому випадку що фейсбучний пхп що інстаграмний Python-Django просто анігілюють твої потуги показати якусь перевагу.

фейсбучний пхп

Знову і знову ті самі балачки. Немає в ФБ ніякого справжнього похапе, заспокійтесь вже.

Але є Cassandra, Hadoop, Memcached — про них ви чомусь забули.

Fortnite використовує виключно Akka на bare metal?

Якщо вам цікаво взнати про архітектуру Фортнайт — загугліть. Я тут до чого?

Просто факт є фактом — AKKA використовується в Fortnite. В Fortnite багато користувачів. Нехай не найбільше в світі — але таки багато. Тому це не є якась маргінальна неактуальна технологія, аж ніразу. І заяви про те, що AKKA «не може конкурувати з рельсами» відповідно дійсності не відповідають — от, живе, конкурує. І не тільки в Фортнайт а і в тому ж таки Netflix.

Чекаю тепер ваших «розумних» коментарів про те, що Фортнайт — ніщо, і Нетфлікс — ніщо, бо є ФБ і Інстаграм, які також Рельсів не використовують — але вони більші, і з цього якось випливає що AKKA не конкурент Рельсам :D, і взагалі нікому не конкурент — всім писати на похапе бо «в Фісбуці 100% натуральне похапе» :D

Просто факт є фактом — AKKA використовується в Fortnite. В Fortnite багато користувачів. Нехай не найбільше в світі — але таки багато. Тому це не є якась маргінальна неактуальна технологія, аж ніразу. І заяви про те, що AKKA «не може конкурувати з рельсами» відповідно дійсності не відповідають — от, живе, конкурує. І не тільки в Фортнайт а і в тому ж таки Netflix

Міняємо назви технологій і компаній — суть не змінюється, навіть якщо туди підставити рубі.

інстаграмний Python-Django просто анігілюють

І Netflix «просто анігілюють»?
А там же та ж AKKA, і Kafka, і тд.
І ніяких Django.

Добре, ти вже починаєш розуміти свою помилку.

Фортнайт на Akka з 250 мільйонів юзерів це ніщо,
Але є Cassandra, Hadoop, Memcached — про них ви чомусь забули.
і Kafka, і тд.

Ще трошки і ти дійдеш до розуміння того, нащо існують різні інструменти, чому акка є ультимативним рішенням лише для мавп з молотком у яких все навколо цвяхи та чим відрізняється одномоментне навантаження від розподіленого у часі.

По перше, Олекс, не тикай мені, нахаба. По друге, помилка у тебе — я ніде і ніколи не писав що AKKA це золотий молот на всі випадки життя.

Було зроблене конкретне твердження:

було ж очевидно що фреймворк на Scala аж ніяк не зможе конкурувати на рівних з рельсами

Яке я аргументовано спростував.

А ти вліз в чужу розмову, навіть не розуміючи про що йдеться.

Йди знайти чисельні продукти сильно більші за Нетфлікс і Фортнайт який бігає на RoR — тоді пиши про конкуренцію чи її відсутність між AKKA і RoR.

А так ти вліз щоб сказати що «АККА не єдине рішення для всіх на всі часи?»
Так це і без тебе відомо, ніхто тут такого не казав. Ти вигадав цей straw man і спростовуєш тезу, яка тут сказана не була, а існує лише в твоїй голові. Попутно видаючи бздури про PHP в Facebook.

Ну там не php, а схожа на JVM машина для Hack (типизований php)

Але то такє. Коли проблематика програмування зводиться до швидкодії програм, то можна виходити з дискусії :)

Наприклад, фреймворк цієї мови — Ruby on Rails — чудово себе почуває у списку найбільш популярних фреймворків та посідає у ньому 13 місце вже два роки поспіль

По ссилці побачив список, де RoR 13-й з 18-и. Ну так собі досягнення, якщо чесно.

React.js — 40.14%
jQuery — 34.42%
Express — 23.82%
Angular — 22.96%
Vue.js — 18.97%
ASP.NET Core — 18.1%
Flask — 16.14%
ASP.NET — 15.74%
Django — 14.99%
Spring — 14.56%
Angular.js — 11.49%
Laravel — 10.12%
Ruby on Rails — 7.04%
Gatsby — 3.97%
FastAPI — 3.88%
Symfony — 3.85%
Svelte — 2.75%
Drupal — 2.39%

insights.stackoverflow.com/...​chnologies-web-frameworks

Скажу за себя:
для меня ruby и соот. экосистема — это прежде всего инструмент быстрой реализации бизнес концепций для заказчика. Который затем, если реализация будет интересной, она разрастется, распадется на микросервисы, будет частично переписана на других ЯП ( к примеру — на Golang) и так далее. И при этом это можно сопровождать не за косм. ресурсы команды.

Мне кажется так обычно и происходит, на другой язык (в том числе и Golang) можно переписать критичную нагруженную часть, где нужна скорость, когда проект выстрелит. А остальное остается на Ruby, без надобности не переписывают обычно весь проект, ведь как Ruby, так и Ruby on Rails вполне развиваются дальше.

Ruby 3.0 Вышел менее года назад (в декабре 2020) (последняя версия Ruby 3.1.0 — 9 ноября 2021) + Ruby on Rails 7 готовится к релизу. И новые фичи завозят

То что проект на Rails 10 лет назад и сейчас довольно похожи — это не из-за того, что не выходят новые версии, это так задумано для того чтобы поддерживать легче было и обновлять.

прежде всего инструмент быстрой реализации бизнес концепций для заказчика
частично переписана на других ЯП ( к примеру — на Golang)

python-django?

Плюс одним должен быть хацкелл, пролог или эрланг. А так императивщина-императивщиной

Вчіть C# - він вбирає в себе все найкраще з усіх мов. Там уже можна писати без класів, прямо в початок файлу бити команди!

Блін,не туди написав. Де тут Доу для клієнтів, щоб вони більше проектів на неті робили? .Нет має панувати!

У тебя в F# опечатка вкралась... %)

У Руби хоть ООП ближе к трушному Smalltalk и очень элегантный синтаксис. Из императивных динамических языков его лучше всего учить.

я бы даже так сказал
в качестве первого языка в колледжах на замену Паскалю нужен не Python, а Ruby

беда же с ним случилась как уже писали — метапрограммирование
Оно казалось отличной вещью: макросы в Лиспе, хайп в узких кругах вокруг Nemerle

Но, практика показала, что есть у такого подхода и недостатки

Нужно ж понимать, что программирование — НЕ математика, аналитически предсказать какие вещи, фичи ЯП и паттерны программирования будут хорошими а какие плохими — невозможно.
Только годы использования, разными командами, в разных проектах и являются тем самым — экспериментом, который подтверждает гипотезу, или отправляет в архив истории развития
Примерно как в медицине — на мышах то все отлично, а что показывают клинические испытания?

Та же Джава — а давайте вспомним первоначальный подход Гослинга — Object.wait() Object.notify()
это ж любимые вопросы на собесах по Джаве — а зачем эти методы вставлены в аж самый корневой класс Object?

www.baeldung.com/java-wait-notify
it’s worth mentioning that all these low-level APIs, such as wait(), notify() and notifyAll(), are traditional methods that work well, but higher-level mechanisms are often simpler and better — such as Java’s native Lock and Condition interfaces (available in java.util.concurrent.locks package).

Object.wait() Object.notify()
это ж любимые вопросы на собесах по Джаве — а зачем эти методы вставлены в аж самый корневой класс Object?

Это какойто костыль котрый они всунули из за ограничений (и видимо перформанса) ранних жвм.
И действительно если подумать, лет 15 назад вейт и нотифи были важными и нужными вопросами на собеседовании. В современных жвм\прочей инфраструктуре подоробности знать и не нужно.

Кстати про ералнг те же лет 10 назад было столько разговоров, мол еще чуть-чуть и убъет и жаву и тоднед. А ща совсем ниче не слышно, видимо «сгинул» вместе с руби...

Erlang/OTP — это довольно специфическая штука для решения определённого класса задач; считать её «убийцей» любой из платформ разработки общего назначения было бы весьма странно.

С чем бы Erlang/OTP действительно мог бы потягаться — это с Akka и Orleans, но здесь с Erlang сыграло злую шутку то, что он замешан на функциональной парадигме чуть менее, чем полностью. И, видимо, даже завоз нового и, кстати, Ruby-подобного языка Elixir не сильно-то помог в плане роста популярности.

Есть ещё такая интересная штука, как Phoenix Framework — этакий AJAX на стероидах — но попробуйте «продать» AJAX и server-side rendering, да ещё и на экзотической платформе, если умами разработчиков правят SPA на фронте и множество более раскрученных платформ на бэке.

но здесь с Erlang сыграло злую шутку то, что он замешан на функциональной парадигме чуть менее, чем полностью.

Он какраз не особо «функциональный». Рекурсия и паттерн матчинг, это не то чем стоит детей в школе пугать.

Ну, как минимум, в Эрланге нет mutable переменных, без которых писать в императивном стиле становится очень и очень затруднительно.

Все с ним нормально — в тематических чятиках вакансии с эликсиром/эрлангом на борту идут очень плотным потоком... А вот кодерков, похоже, не хватает — достаточно часто готовы брать без знания платформы и учить на лету.

ну лет 10 назад куча разговоров, в том числе тут на доу было, и какието вакансии мелькали. Щас совсем глухо-тихо.

Тому що Ruby On Rails це найкращий веб фреймворк з чудовим DX та швидкістю розробки.

На ньому приємно працювати.

в каком месте он найкращий. Вы в котором году застряли?

в каком месте он найкращий

У всіх місцях.

Вы в котором году застряли?

У вас є конкретні претензії?

У вас є конкретні претензії?

Да конкретная претензия — он на рубях, а руби язык-помойка.

Ок, значить до rails претензій нема, а ви робили проекти на рубі? Що конкретно вам не сподобалось?

Не розумію навіщо вчити ще одну таку ж мову як знаєш. Вчити стронг тайпед після скриптової, або навпаки — гуд. Вчити го для системного програмування — гуд. А чергову веб мову щоб писати те саме просто на новій?

Как говорится
>A language that doesn’t affect the way you think about programming, is not worth knowing.

Поэтому учить нужно LISP :)

У рубі досіть цікаво влаштована об’єктна модель, метапрограмування, блоки. Той самий код на пхп і на ідіоматичному рубі може досить сильно відрізнятись.
І мабуть ви мали на увазі статичну типізацію, тому що рубі як і пайтон як раз strongly typed.
Рельсу замість Ларавеля мабуть і не така хороша ідея вчити, хоча мені важко сказати.

Чому варто вивчити Ruby

щоб потрапити в дружню команду рубістів з Дніпра

наскільки хороший Ruby для написання коду, настільки ж і важкий для читання. Зрозуміти, що виконує той чи інший блок коду, буває важко.

Сначала вы заносите легкость метапрограммирования в плюсы а потом в минусах о том что код получается тяжелых для понимания :)

Идея языка хорошая, но пока на нем даже кормят не везде.

не особо хороша, фич маловато будет.

Мне просто импонирует синтаксис по типу руби или питона, но скриптовые языки заметно сливают компилируемым в производительности иногда на порядок или даже два.

Пробовали в проде еще до релиза 1.0 для одного мееееедленного, но не критичного процесса (в смысле могли позволить эксперименты) — буст ожидаемо колоссальный по сравнению с руби... Но незрелость экосистемы (например пришлось писать драйвер для кассандры самим) + адово медленная компиляция (по состоянию на примерно 2 года назад — возможно уже получше) таки отрезвляют. Хотя проект классный, надеюсь не канет в Лету...

Спасибо за отзыв очень интересовало как он в реальном проекте себя показывает. Они вроде обещали что можно включать либы на С/С++ неужто там не нашлось подходящей для кассандры ?

Руби сдох и Рельсы поросли травой, игнорируйте статью и расходитесь по родным мовам.
А то ты гляди, Go обогнал Ruby по количеству людей с ЗП выше 5k$ — куда это годится...

Руби сдох и Рельсы поросли травой

У ваших фантазіях.

Видимо я недостаточный акцент на иронии сделал. Ну ок.

У вас вже є досвід переписування з PHP на Go, ймовірно буде переписування з Ruby на Go.

Я виділив кілька недоліків. По-перше, наскільки хороший Ruby для написання коду, настільки ж і важкий для читання. Зрозуміти, що виконує той чи інший блок коду, буває важко.

Цього вже цілком достатньо для відмови від використання в ентерпрайзі. Бо саме на читання коду витрачається 90% часу.

А пацани (з Shopify, Stripe, GitHub, GitLab) то и не знали что Ruby нельзя использовать в больших проектах.

Те що вони його колись обрали ще означає, що вони зараз не шкодують про це. І тим більше, що вони б зараз його ж обрали, якби починали все з нуля.

Мне пара компаний (с уже имеющимися продуктами) писала, что начинают новые проекты с нуля в конце года на Ruby. Что-то они знают про преимущества руби и рельсов для быстрого старта.

Что-то они знают про преимущества руби и рельсов для быстрого старта.

Чогось маю сумніви що це щось інше ніж просто гармонізація з існуючим стеком чи рубісти в штаті, яких потрібно чимось зайняти.

Або, як колись чув історію, що прийшов новий СТО, який колись щось писав на ноді, то намагався все в компанії на ноду перевести. Аргументи типу: стильно, модно, молодіжно.
Ну, і як завжди, виключення — підтвердження правила. А скільки компаній почали проекти НЕ на рубі?)

Чогось маю сумніви що це щось інше ніж просто гармонізація з існуючим стеком чи рубісти в штаті, яких потрібно чимось зайняти.

Естественно вы сомневаетесь, и думаете, что от руби все «уходят», вы же это делали еще до моего комментария. Я же говорю просто о том, что мне предлагали.

+1 мова — це завжди дуже добре.
Особливо заслуговує на повагу, якщо це — державна мова.
Адже українська мова — це престижно та перспективно.
Чудова стаття. Пишіть ще.

Ничего хорошего в руби и рельсах на сегодняшний день нет. Отдал ему много лет своей жизни. Поддержка и развитие только для галочки. Никто не внедряет туда что-то новое. Символы были нужны 20 лет назад, когда на серваке было оперативы в мегабайтах, а не гигах. Сейчас же это наказание, особенно при работе с АПИ. DSL — это просто изврат, лично для меня. Учишь не ЯП, а чьи-то подделия. Программисты на руби тащат в код сотни разных гемов, хотя можно обойтись парой строк кода, в большинстве случаев. В итоге убежал в ноду. Тем более я и фронт пишу, так что работаю в едином стеке. А все что про руби можно сказать и именно это и говорят, так это то, что «Руби еще не умер».

Программисты на руби тащат в код сотни разных гемов, хотя можно обойтись парой строк кода, в большинстве случаев. В итоге убежал в ноду.

Вот тут я если честно разницы не заметил. Очень много проектов на ноде попадались когда зависимости на несколько экранов.

К сожалению, это уже проблема больше специалистов, а не ЯП. Но лично для меня нода развязала руки. Я строю архитектуру с нуля так, как я хочу, а не как мне велит RoR way. Я ради интереса спрашивал у некоторых сениоров, как во фреймворке в контроллер прибегают парамсы, и как middleware обрабатывают запрос. Так все глаза пучили, не понимая чего я хочу. Прибежали мол в метод и прибежали, бери да пользуйся, чего еще тебе нужно ((( Конечно же для такиех спецов и нужен фреймворк-комбайн. И ЯП тут уже уходит на задний план.

Я строю архитектуру с нуля так, как я хочу,

с этого месте поподробнее пожалуйста.
сколько человек в команде ? кто сопровождает Ваш код ? кто будет сопровождать завтра ? Каковы затраты на обучение нового сотрудника в понимание Вашего личного видения архитектуры обработки запроса ? какова стоимость мотивации нового сотрудника разбираться с Вашим личным видением порядка обработки ?

как во фреймворке в контроллер прибегают парамсы, и как middleware обрабатывают запрос

то мешало Вам сходить в исходный код rails gem’a ?
Это можно сделать одним щелчком из ide
начать прямо с ActionController::Base
и смотреть по модулям, там прямо видна реализация откуда берутся параметры, где вытаскиваются, как фильтруются и так далее

сколько человек в команде

Четверо.

кто сопровождает Ваш код

Команда разработки.

Каковы затраты на обучение нового сотрудника в понимание Вашего личного видения архитектуры обработки запроса

Минимальны. Ежедневные митинги у нас практикуются давно и так. О процессах писал здесь habr.com/ru/post/524460

какова стоимость мотивации нового сотрудника разбираться с Вашим личным видением порядка обработки

Это личный выбор каждого. Нет мотивации идти в ногу с кор командой, значит нам не по пути.

то мешало Вам сходить в исходный код rails gem’a

Я не про себя писал. Да и зачем это нужно? Ведь это техническая деталь реализации. А вот логика одна и та же для всех ЯП и фреймворков, как и много чего другого.

Это можно сделать одним щелчком из ide

Спасибо кэп. В следующий раз обязательно спрошу у вас совета.

Так можно же и на Руби так писать, без Рельс

К сожалению, это уже проблема больше специалистов, а не ЯП.

Тоді до чого ваш комент про те що прогрімсти на Rails тягнуть купу залежностей? Всі тягнуть купу залежностей, причому настільки дегенеративних як is_even.

Я строю архитектуру с нуля так, как я хочу, а не как мне велит RoR way.

Не дуже розумію що ви там таке будуєте. RoR way за 15 років довів свою спроможність вирішувати задачі усіх масштабів.

Ну а якщо вже у вас сильно дупа горить від params які невідомо як приїздять у контролер, то можна взяти Sinatra, Grape і так далі.

Конечно же для такиех спецов

Запитайте в «реакт розробника» як зробити html сторінку без реакту, те саме почуєте.

Ваші претензії не до фреймворку та мови, а до людей. Звісно мова та фреймворк в залежності від рівня абстракції ховають багато деталей, але якщо у вас пече від розробників які не знають як встромити в Rails новий міддлвер, то переходьте на низькорівневі мови де кожен мусить знати що таке вказівник та чистити після себе вилкою хіп, бо інакше не зможе писати.

Программисты на руби тащат в код сотни разных гемов, хотя можно обойтись парой строк кода, в большинстве случаев. В итоге убежал в ноду.

Эти два предложения рядом вызывают гомерический хохот если честно. Это же в экосистеме руби есть пакеты в стиле is-odd/is-even/uppercase/... с миллионами скачиваний... Ой, стоп. Экосистема руби прекрасна (возможно, это лучшее что есть в руби вообще :)), а если пипл тащит в проект ненужные зависимости — это говорит не о ЯП, а об организации процесса (его отсутствии).

В своей жизни я писал на C++, Delphi, PHP, Python, Java, немного на Go и Rust, Crystal, N. Более 10 лет на JS. Более 5 лет на Ruby. Такого слова для инструмента, как «экосистема прекрасна» и т.д. в моем лексиконе не существует. Такого рода эпитеты могут писать только специалисты, которые сидят в едином стеке и их все устраивает.

P.S. Это же прекрасно, когда вместо подключения только необходимых файлов в каждом конкретном случае, RoR тащит в память всю папку app через авто подключение. Сарказм, если что. Попробуйте с graphQl поработайте на RoR, может энтузиазма поубавится.

В своей жизни я писал на C++, Delphi, PHP, Python, Java, немного на Go и Rust, Crystal, N. Более 10 лет на JS. Более 5 лет на Ruby. Такого слова для инструмента, как «экосистема прекрасна» и т.д. в моем лексиконе не существует. Такого рода эпитеты могут писать только специалисты, которые сидят в едином стеке и их все устраивает.

А такого рода манипуляциями занимаются только люди, которым нечего ответить по существу :) Это же вы выше высказались о нездоровой ситуации с зависимостями? Вот это и обсуждается, а не ваши фантазии на тему кого что устраивает.

Это же прекрасно, когда вместо подключения только необходимых файлов в каждом конкретном случае, RoR тащит в память всю папку app через авто подключение.

Ну да, ведь это самое «подключение только необходимых файлов в каждом конкретном случае» — оно же бесплатное наверное... ой, стоп. Ну и показательно, что вместо обсуждения ЯП и экосистемы вы скатились в обсуждение рельс :) Это же так легко — пинать фреймворк, который изначально позиционируется как opinionated, с идеей «conventions over configuration» возведенной практически в абсолют.

Ой, я извиняюсь, а разве Ruby существует вне RoR? А разве RoR не презентовал себя, как новый мощный АПИ для бэкенда? Какова вообще доля Синатры или вообще чистого Руби? А про кучу технологий я написал лишь для того, чтобы подчеркнуть, что я стараюсь объективно посмотреть на инструмент, а не с точки зрения «синдрома утенка». После пыхи мне руби тоже показался приятным. Но ровно до тех пор, пока я на нем, естественно с командой, не сделал громадный сервисный маркетплейс со своей системой CRM, бухгалтерией, своим платежным SDK и кучей еще всего. И то, как комманда профессиональных спецов (8 человек) пыталась с этим справиться, повергло меня в непроходящий, до сих пор, ШОК! За три года это все превратилось в такой легаси, что народ, который это писал, сам начал разбегаться с проекта, кто куда. А главное, писали-то грамотно, покрывали тестами. Но сам дизайн языка превратил миллионы строк кода в нечитаемый ужас. Кстати, что такое абстрактный подход и атомарность, многие рубисты вообще никогда не слышали. В итоге, миллоны примесей, безумное сделование DRY, которое приводило к вечным проблемем в коде, так как в одном месте нужно было немного логику поменять, а вдругом оставить старую. Что такое стейт машина и нафиг она нужно, большинство вообще слыхом не слыхивали и в скедуле лепили сравнение времени для экшена джобы прямо на текушее время. Что-то не отработало (скедул в дауне, например), все, досвидание. Джоба больше никогда не выполнится. Всю бизнес логику несут в модели, так как рубистов так научили. Что такое статические словари и зачем они нужны, вообще никто не знает, все несут в базу, устраивая там помойку и еще миллион чего. И все это, типа, НОРМА для Руби, так как спецов так делать научили умные книжки. Я могу много чего рассказывать, но нет в этом смысла. На хабре была большая статья о устеревшем дизайне руби со всеми пояснениями.

Всю бизнес логику несут в модели...

...джуны

В итоге, миллоны примесей, безумное сделование DRY, которое приводило к вечным проблемем в коде, так как в одном месте нужно было немного логику поменять, а вдругом оставить старую.

Все это очень косвенно касается самого языка. Если вы (не лично а команда) «безумно следовали DRY» и не смогли в OOD — при чем тут язык? Что в дизайне языка заставляло вас так делать?

Что такое стейт машина и нафиг она нужно, большинство вообще слыхом не слыхивали и в скедуле лепили сравнение времени для экшена джобы прямо на текушее время.

Я немножко потерял нить ваших рассуждений. То есть руби плохой язык потому что кодерки не знают что такое стейт машина, не сумели в дизайн и вот это вот все? А вот если бы они перешли все на благословенную ноду, то все сразу бы исправилось? Рили? Вам бы отделить мух от котлет в своей аргументации: проблемы ЯП это одно, а квалификация людей которые вам попадались — ну вот совсем ортогональная штука.

И все это, типа, НОРМА для Руби

Простите, но это буллшит.

а разве Ruby существует вне RoR?

да, существует
к примеру м-сы на Hanami люди активно пишет

разве RoR не презентовал себя, как новый мощный АПИ для бэкенда?

Вы вводите заблуждение аудиторию
Rails всегда был и есть инструмент максимально быстрой разработки. в том числе backend. при условии выполнения некоторых ограничений
всем было понятно, что если кто-то соглашается и принимает правила инструмента — очень быстро можно реализовать в рамках этих правил.

И то, как комманда профессиональных спецов (8 человек) пыталась с этим справиться, повергло меня в непроходящий, до сих пор, ШОК! За три года это все превратилось в такой легаси, что народ, который это писал, сам начал разбегаться с проекта, кто куда.

нет у Вас проф. специалистов, если Вы ухайдокали проект до такого состояния за 3 года. и Ruby тут не причем, вопрос в том, налаживали ли в команде процессы работы с тех. долгом
— если Вам не давали исправлять ТД, то почему Вы на это повелись
— если давали, то на что потратили время ?

А главное, писали-то грамотно, покрывали тестами.

пока что Ваши рассуждения говорят о том, что на проекте была толпа людей, которые не владеют инструментом

просто как пример:

безумное сделование DRY

говорит о том, что программировали на ruby на уровне не выше новичка
потому что уже мидл четко знает, что DRY — не символ веры, а инструмент, который порой вреден.

Всю бизнес логику несут в модели, так как рубистов так научили.

так делают только джуны
уже мидлы знают что такое сервисы, что за логику в модели надо бить по рукам и так далее. про этом написано 101 доклада. видео и так далее

Что такое стейт машина и нафиг она нужно, большинство вообще слыхом не слыхивали

Да, джуны, которые лепят CRUDы по шаблону в ресьсах про такое не в курсе. но конечно же виноват ruby ...

И все это, типа, НОРМА для Руби, так как спецов так делать научили умные книжки.

Ваши претензии можно применить к любому языку и инструменту.
Node.js + Express
Java + Spring
и так далее.
если вспомню про реакт ... просто заменить название и будет 1 в 1

А у меня к вам есть вопрос. Вот скажите, есть какая-то галлера, которая набирает под легаси проект джунов рубистов (или не важно, какой ЯП). Нет там никаких гуру. Соответственно эти спецы сами чему-то и как-то учаться. Идут годы. Вроде таски они закрывают, клиент и галлера, вроде довольны. В финале мы имеем спецов с опытом 5-7 лет в одном едином стеке. Отсюда вопрос, какой уровень квалификации таких людей? Почему люди не пробовали себя в других стеках и яро защищают свой текущий стек? Как такие люди должны обучаться и у кого, как им понять где полезная и нужная информация, а где бред?! Почему многие любители AR не в состоянии простой SQL написать? Где эта грань перехода от джуна к мидлу и от мидла к сениору? Почему галлеры раздают всем лычки сениоров и продают джунов, как сениоров? Как вообще во всем этом звездице разобраться молодому и начинающему специалисту?
Ну а что касается руби, то начинать новый и большой проект на руби в 2021 году, когда все новые статьи начинаются с того, что руби еще не умер, то это попахивает не очень хорошо. По поводу ноды я вообще ничего не говорил о том какая это хорошая платформа. JS есть JS, со всеми своими проблемами. Но лично для меня есть тут неоспоримые плюсы, и единый стек с фронтом (Реакт), один из них.

А у меня к вам есть вопрос.

Все приведенные Вами аргументы актуальны для любого популярного инструмента с невысоким базовым порогом вхождения и потому очень бы хотелось бы чтобы шло оперирование фактами.
к примеру, если Вы бы сказали, что:
— аллокатор в ruby так себе
— первая реализация jit — так себе
и так далее. Это была бы КРИТИКА. но Вы занялись непонятно чем

В финале мы имеем спецов с опытом 5-7 лет в одном едином стеке.

Точно такую-же претензию вопрос я могу адресовать к любому иному инструменту. Сколько раз разбирался спец. кейс работы на legacy проектах, к примеру: сидит такой персонаж на Java N и ... но для Вас опять же виноват ruby. Очень «честный» подход

Как такие люди должны обучаться и у кого, как им понять где полезная и нужная информация, а где бред?!

Как все остальные во всем мире. есть статьи, есть online дискуссии, есть os код, есть и конференции и так далее. Мы де в детском саду, чтобы нас за ручку водили.

Почему многие любители AR не в состоянии простой SQL написать?

это конечно ruby виноват в том, что джун rails не подумал про самообучение и не посмотрел SQL ?
а ruby также виноват, что джун node.js освоивший только TypeORM не знает SQL ? и а проблемах тонн говонокода на Flask также Ruby виноват ?

Почему люди не пробовали себя в других стеках и яро защищают свой текущий стек?

тоже самое можно сказать по любому популярному инструменту и экосистеме.

Где эта грань перехода от джуна к мидлу и от мидла к сениору? Почему галлеры раздают всем лычки сениоров и продают джунов, как сениоров? Как вообще во всем этом звездице разобраться молодому и начинающему специалисту?

Это не имеет отношения к платформе. Мы не проблемы галер тут разбираем, если Вы не заметили.

Но лично для меня есть тут неоспоримые плюсы, и единый стек с фронтом (Реакт), один из них.

на этом можно и закончить. Вы овладели инструментом JS и он Вас устраивает как FS инженера, решая Ваши проблемы. И чудно, для чего пинать ruby в таком стиле, как это сделали Вы — ума не приложу.

тонн говонокода на Flask

Винен маркетинг фласка який чомусь називав фласк фреймворком

він спочатку мікро а потім іноді може вже бути і фреймворк.

Никто не внедряет туда что-то новое

А що нове потрібно?

Асинхронна робота з DB?
Будь-який інший persistence паттерн ніж active record?
Це перше що приходить до голови.

Я не в курсі, може там це все давно є — я просто не рубіст ніразу.

P.S. Чому треба ще щось крім active record, принаймні його «коробочної» імплементації. Приклад з життя — є солюшн в якому є мультітенансі, і кожен тенант це якась окрема клієнтська компанія, дані якої не мають виходити за межі її регіону. На практиці це означає що кожна компанія має свою якусь реляційну (хоча і не обов’язково реляційну) БД в свойому регіоні в AWS чи іншому клауд провайдері (нехай Amazon чи GCP — не суттєво). Тобто в одного тенанта все лежить в БД яка хоститься в Австралії, в іншого — в БД яка «живе» в Британії, тп.

Але перзистенс шар один, і просто під капотом в залежності від того, під яким тенантом виконується якась робота переключається конекшн до бази.

На Java ми таке реалізували навіть маючи перзистенс на ORM Hibernate, хоча треба було пів дня почухати голову як зробити це так щоб і страшний Hibernate працював коректно коли від ним JDBC датасорс перемикається на датасорси для різних баз (благо він має для цього певні екстенш пойнти).

А от чи можна таке зробити на Ruby, і наскільки боляче це буде? Це один приклад.

P.P.S. А як в Рубі з багатопоточністю — є взагалі, є якісь структури для багатопоточної роботи як в java.util.concurrent, типу черг, atomic примітивів, copy-on-write списків, thread local-ів, засобів синхронізації типу latch, read-write локів?
А з асинхронними сокетами як справи? А з асинхронщиною і реактивним програмуванням?

Будь-який інший persistence паттерн ніж active record?

Ціла купа.

Асинхронна робота з DB?

Не впевнений що десь є нормальні реалізації цього

Але перзистенс шар один, і просто під капотом в залежності від того, під яким тенантом виконується якась робота переключається конекшн до бази.

Вже давно зроблено в ActiveRercod

я просто не рубіст ніразу.

То які претензії?) Бібліотеки та фреймворки розвиваються, а людина яка бомбанула, ну в неї якісь свої причини.

Ціла купа.

Наприклад?

P.P.S. А як в Рубі з багатопоточністю — є взагалі, є якісь структури для багатопоточної роботи як в java.util.concurrent, типу черг, atomic примітивів, copy-on-write списків, thread local-ів, засобів синхронізації типу latch, read-write локів?
А з асинхронними сокетами як справи?
А з асинхронщиною і реактивним програмуванням?

Наприклад?

www.ruby-toolbox.com/categories/orm

Але я наприклад не можу придумати навіщо мені щось з цього використовувати якщо є ActiveRecord.

А як в Рубі з багатопоточністю

Братан, є, але тут ви не за адресою чесно кажучи. Ще б запитали чи є в Ruby unsafe.

навіщо мені щось з цього використовувати якщо є ActiveRecord

softwareengineering.stackexchange.com/...​-the-activerecord-pattern

тут ви не за адресою

Чому ж? Рубі лише на одноядерних процах ранають? o_O

А реактивщина теж не за адресою? Ну ок :-)

Рубі лише на одноядерних процах ранають? o_O

Ні, але очевидно що там немає таких хороших примітивів для багатопоточності як в Java. Нещодавно додали Ractor які щось типу тредів в джаві, але я ними не користувався і не можу сказати воно добре чи погано. Це до того чи щось нове додається чи не додається. Додається. Асинхронність теж є. Якщо сильно кортить то можна замість MRI взяти JRuby та отримати всі бонуси екосистеми JVM.

Ну ок :-)

Взагалі у вас дивні питання. Рубі ніколи не цінувався за бенчмарки або надзвичайно хорошу підтримку асинхронності та багатопоточності. Рубі цінується за developer experience та швидкість розробки. Якщо ви подивитися на бенчмарки то виявиться що Rails хіба б не найповільніший серед своїх друзів, але це не заважає будувати на ньому рішення будь-яких розмірів.

softwareengineering.stackexchange.com/...​-the-activerecord-pattern

У вас є конкретні пред’яви? Бо я можу навести вагон критики що ORM це погано бо тупі розробники не розуміють що таке N+1, але ж воно ніяк не заважає розважливим розробникам писати нормальний швидкий код.

p.s.: я Java розробник але писати на java/scala мені неприємно. Ruby та Ruby on Rails просто на іншому рівні знаходяться у порівнянні з тими інструментами які нам дають Java або інші екосистеми. Поки не почнеш писати—не зрозумієш.

У вас є конкретні пред’яви?

Спробуйте відкрити посилання і прочитати що там написано :-)

Конкретні пред’яви у конкретно вас будуть?

В мене не пред’яви. Є відомі обмеження в ActiveRecord — вони описані по посиланню.

Якщо я напишу від себе — будуть якраз пред’яви в дусі «ти просто не шариш» і «хто ти такий». Так от я навів посилання де інші люди конкретно розписали проблеми.

І взагалі не існує one size fits all підходів, а ActiveRecord не просто не панацея а взагалі досить проблемний паттерн як на мене — якраз через описані там проблеми.

В мене не пред’яви.

Ясно, знайшли тікет і вирішили посперечатися.

Крім ActiveRecord в Ruby є інші способи роботи з базою. Було б дивно якби у популярної мови не було б розробників які з тих чи інших причин незадоволені ActiveRecord.

досить проблемний паттерн

Не знаю що там у вас а у мене та купи інших людей проблем немає.

Та людині хібернейтом мабуть мозок виїло.
ActiveRecord і в пхп світі головний. Рішень з рельсів чимало втілено у пхп фреймворках. Бо в цілому — вдалі рішення

просто на іншому рівні знаходяться у порівнянні з тими інструментами які нам дають Java або інші екосистеми. Поки не почнеш писати—не зрозумієш.

Это парадокс Блаба: типичные программисты удовлетворены любым языком, которым им пришлось пользоваться, потому что тот диктует им, как они должны думать о программах

А як в Рубі з багатопоточністю — є взагалі, є якісь структури для багатопоточної роботи як в java.util.concurrent, типу черг, atomic примітивів, copy-on-write списків, thread local-ів, засобів синхронізації типу latch, read-write локів?

github.com/...​ncurrency/concurrent-ruby

В самой популярной реализации все это применимо достаточно ограничено (спасибки GIL), но есть альтернативные тащемто, так что при необходимости...

спасибки GIL

Что, GIL в Рубях как в Пистоне? Ужос н...

concurrent-ruby используется немного иначе.

В девелопменте можно использовать mri Ruby обычный(с GIL) а в проде тот же код запускается на JRuby и уже работает без GIL и с нативной многопоточностью(если правильно код написан).

Тут одразу стає питання на який біс воно треба в скриптовій мові?
Нащо використовувати тулзу через одне місце

В веб варіанті — краще прибити потік після виконання запиту (через фіксований проміхок часу), так не буде ніяких проблем з протіканням пам’яті
В варіанті демона — запустити декілька незалежних копій і шарити стан через БД
В варіанті скрипта — асинхронні виклики

не зовсім зрозумів до чого це і про що ви кажете

concurrent-ruby используется немного иначе.

Не очень понял о чем ты, пояснишь? Я имел в виду что примитивов и абстракций для написания thread-safe кода в руби вполне завезли, но их применение в дефолтной реализации ограничено тем фактом, что выгоды от многопоточности можно получить только в некоторых сценариях. Поэтому если скажем авторы либ часто могут юзать конкарент-руби чтобы запилить потокобезопасное решение (честь им и хвала), то у прикладных кодерков такая необходимость возникает достаточно редко — среднестатистическому CRUD многопоточность нужна как ежу футболка...

среднестатистическому CRUD многопоточность нужна как ежу футболка...

именно так!
поэтому пхп не страдает даже не имея и того что есть в руби и питоне.

а когда же она нужна — то вдруг Пайк выкатывает Го, потому что — а чего-то с ней так в Джаве.

Программисты на руби тащат в код сотни разных гемов, хотя можно обойтись парой строк кода, в большинстве случаев.
В итоге убежал в ноду

Я просто оставлю это здесь

I will pay you cash to delete your npm module

I will pay you cash to delete your npm module

санитары у него давно все деньги отобрали :)

"Руби еще не умер"

Выходит, писать на Ruby — патриотический долг каждого украинца.

Да и поляка тоже.

Подписаться на комментарии