Пацаны, так Ruby умер или нет?



    Последнее время, когда я говорю с разработчиками или компаниями, часто слышу одну и ту же историю разными словами — «мы писали на Ruby, но сейчас переезжаем». С одной стороны, ничего удивительного. Разработка — дело изменчивое, всегда появляется что-то новое, каждый день надо тратить кучу мозгов, чтобы оставаться актуальным.

    Но при этом существуют же некие преданность технологии и даже культ инструмента. Скажи пхп-шнику, что пора переезжать на .NET, услышишь «PHP отличный, полмира на нем пишет», или просто получишь в лоб.

    Что же не так с Ruby, и куда делась его взрывная популярность? Я поговорил с несколькими рубистами. Например, Максимом Индыковым из Staply, чья команда переезжает с Ruby на Go, и с Алексеем Кузнецовым из GeekBrains, компании, которая начиналась с курсов по Ruby, а сейчас отказалась от них полностью.

    Чем хорош Ruby?


    Максим Индыков (maks_ohs): Продуманный синтаксис, на котором код выглядит максимально читаемым. Можно писать действительно понятно и лаконично. Огромное количество реализованных библиотек, подключение которых не вызывает проблем.

    Павел Сережин: Самый главный плюс ruby — это rails, лучший фреймворк. Четко реализованные паттерны, не то, что на node.js, крути как хочешь. Само написание кода напоминает английскую речь.

    Алексей Кузнецов: У языка легковесный и очень лаконичный синтаксис, хорошо подходящий для описания DSL и бизнес логики. Низкий порог входа, доброжелательное комьюнити. Хороший кандидат, чтобы учить как первый язык.

    Чем плох Ruby?


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

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

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

    Алексей Кузнецов: Язык практически не развивается на фоне его ближайших конкурентов (JavaScript и Python). Взрывной рост интереса к Ruby основывался в первую очередь на Ruby on Rails. Но сейчас, когда Rails-like фреймворки есть в каждом популярном ЯП, Ruby мало что может предложить. Отсутствие даже опциональной статической типизации также не добавляет Ruby очков.

    Расскажи, почему ты выбирал его?


    Алексей Кузнецов: Я перешел на Ruby c C++ около 5 лет назад и на тот момент это было разумным выбором. Хотелось делать продукты, которые ближе к конечным пользователям. У PHP была не самая лучшая репутация. В JS балом правил ES5+JQuery, а синтаксис Python не вдохновлял.

    Павел Сережин: Прежде всего из-за rails, он идеально подходит под область web разработки, которой я и хотел заниматься. И приятно писать на языке ориентированном на разработчика.

    Максим Индыков: Очень повлияло коммьюнити. Огромное количество качественно написанных туториалов и best practices. Rails фреймворк, делающий разработку максимально понятной от самого старта проекта, до деплоя. Богатство подходов и реализаций для написания тестов: RSpec, MiniTest и так далее.

    На тот момент, казалось ли тебе, что за ним будущее?


    Максим Индыков: Да, язык постоянно развивался (и сейчас продолжает это делать). Было огромное количество вакансий. На фоне php все казалось максимально логичным и правильным.

    Павел Сережин: Никогда не считал, что ruby будет в топе, а наоборот. Всегда казалось, что разрабов будет достаточно мало, и это создаст конкуренцию на ровном месте. Правда — это один из минусов, с уровня джуна зайти кроме как в столицах практически невозможно.

    Почему сейчас Ruby все реже требуется?


    Павел Сережин: Сейчас все чаще для создания новых проектов просто выбирают более популярные языки и фреймворки. И ruby, и rails немного отстают в производительности и не успевают за трендами. В rails завезли поддержку webpack, что не сильно помогает — легче разделить на два отдельных проекта.

    Алексей Кузнецов: Node.js активно канибализирует нишу веб-приложений, а со стороны всевозможных утилит поджимает Go.

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

    Ruby создавался как такой ЯП, который нравится разрабам, а не бизнесу. Как думаешь, его нынешняя непопулярность — показатель того, что такая стратегия не работает?


    Алексей Кузнецов: Мне кажется, что ситуация противоположная. Остальные языки подтянулись до уровня, на котором с ними стало приятно работать разработчикам (destructuring в ES6, стримы в Java8, нуллабилити в Kotlin и Swift, модель конкуренции в Go).

    Максим Индыков: Бизнес хочет экономить деньги — ресурсы серверов. Когда появляется технология способная держать нагрузку на порядки выше, мало кто откажется сэкономить.
    Когда эта технология имеет строгую типизацию, что является плюсом к надежности — это еще один камень в огород Ruby.

    По ощущениям, в РФ такая ситуация: была и есть php разработка. Потом пришла локальная популярность ruby, который преподносился как убийца php, но часто не хватало других аргументов для бизнеса, кроме «Ну на Ruby реально удобно писать». Всех пугал недостаток специалистов. С появлением elixir и go аргументы уже гораздо более понятны.

    С Ruby надо уходить?


    Алексей Кузнецов: Не думаю, что надо бежать с Ruby, но стоит посмотреть на альтернативы.

    Максим Индыков: Весь рынок мигрирует. Крупные компании во всю объявляют об использовании Go. Но речь идет о миграции в определенных областях задач. Знаниями новых популярных технологий точно нужно обладать.

    Павел Сережин: Сейчас js куда более популярен и достаточно неудобно распыляться на два разных по синтаксису языка. Исторически сложилось, что у меня к Реакту душа лежит больше, так что думаю уйти с фулстека на фронт.

    Встанет ли он в число совершенно невостребованных языков?


    Максим Индыков: Нет, для быстро написания прототипов и MVP, где требуется простота реализации, ему нет равных. Есть непаханое поле проектов, которые нужно реализовать быстро и качественно. Момент, когда потребуется оптимизация может и не наступить, а как известно, преждевременная оптимизация — это зло.

    Павел Сережин: Не думаю. За Ruby так и останется некая репутация слегка непопулярного языка, ниша со своим комьюнити.

    Алексей Кузнецов: До этого еще далеко. Есть много ситуаций, когда не так важно, на чем написан проект. И много разработчиков, готовых за выходные собрать MVP.
    А имея прокачанную команду рубистов можно успешно развивать продукт годами (GitHub и GitLab — оба написаны на RoR).

    На Ruby написаны миллионы строк кода, который кому-то нужно поддерживать.
    Но количество новых проектов со временем будет только уменьшаться. Думаю, лет пять у языка еще есть.

    Что бы могло помочь Ruby оставаться популярным?


    Максим Индыков: Большая гибкость разработчиков языка. Реализация улучшений по работе с многопоточностью.

    Павел Сережин: Повышение производительности самого языка и rails. И поставить корпорацию с кучей денег на поддержку.

    Алексей Кузнецов: Ruby не превратился в тыкву. Просто появились другие кареты. В комплекте с некоторыми идут реактивные двигатели, другие сильнее сияют.
    Думаю, опциональная статическая типизация (и тулинг, который можно сделать поверх нее) могли бы помочь.

    Какой из популярных сейчас ЯПов больше всего подходит рубисту?


    Максим Индыков: Скорее зависит от задач, но чаще всего на этот вопрос ответ: elixir. Язык созданный людьми из ruby/rails сообщества.

    Алексей Кузнецов: В целом мне не близко деление на разработчиков по языкам программирования. Для software developer не должно быть проблемой освоить новый стек на достаточном уровне за 2-4 недели.

    А так я бы смотрел в сторону Go/JS/Swift в зависимости от задач, на которых разработчик планирует сфокусироваться. Есть еще Elixir и Clojure, но они не мейнстримовые.

    Павел Сережин: Почти каждый уважающий себя рубист уходит на Golang. Так что ответ очевиден.
    Support the author
    Share post

    Similar posts

    Comments 183

      +2

      Больше всего мне в Руби не хватает асинхронного программирования и огорчает полнейшее отсутствие неизменяемых структур данных. No future.

          0

          Со всех трибун кричат что ни в коем случае не следует использовать эвент машин, ибо он устарел. Даже если им пользоваться, не припомню подобной лаконичности как например здесь:



          Про заморозку объектов я промолчу, no comment

            0
            Пожалуйста прокомментируйте что не так с заморозкой? Я о ней знаю только из документации, на практике не использовал, так что возможно я упускаю что-то важное.

            То, что eventmachine устарел честно говоря тоже слышу первый раз. Можно вас попросить привести аргументы критиков или ссылку дать на соответствующий материал?
              0

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


              Фриз ничего такого не предоставляет.

                +1
                Можно попросить вас уточнить какую версию руби вы сейчас имели в виду?
              0
              Интересно чем же eventmachine устарел?
              Асинхронное программирование само по себе имеет узкую нишу и если этой технологии не находится применение в большинстве случаев, не означает, что он устарел. В это же время асинхронные http библиотеки могут спокойно использовать под капотом eventmachine и никто не кричит, что они устарели.
                0
                Интересно, какую такую узкую нишу имеет асинхронное программирование. Любое взаимодействие с внешним миром — работа с сетью, чтение/запись на диск и т. д. гораздо проще выражается при использовании асинхронного кода, нежели мешаниной callback'ов. Зависит конечно от самого языка и от того, что конкретно разрабатывается.
                  0
                  Типичное веб приложение не генерирует десятки запросов в сеть или на диск в контексте пользовательского запроса. Если это интерактивная веб страничка (пусть даже очень нагруженный интернет магазин, блог или форум), там скорей всего не будет сетевых запросов во внешние сервисы или обращений в диск мимо БД. А бизнес логика как правило имеет синхронную природу. Асинхронность в node.js или golang даёт преимущество или при очень высоких нагрузках (много входящих запросов) или в специфичных случаях, когда само приложение генерирует много запросов\трафика.
                    0
                    *удалил* (неправильно понял ответ)
                      0
                      Точно, речь же идёт про веб-приложения, а я тут со своими десктопными понятиями :)
                        0
                        Далеко не всегда можно получить всю нужную инфу одним sql запросом, даже если не стесняться использовать джоины направо и налево. К примеру, это интернет магазин. Нужно и профиль юзера получить, и корзину его товаров, и категории товаров, и подробная информация об одном товаре, и список схожих товаров, и путь от главной страницы до определенного товара — категория, подкатегории, и тд.

                        Асинхронно это реализовывать на nodejs довольно бесяче (особенно раньше, на колбеках), но очень производительно — когда один запрос ожидает ответа от внешнего сервиса — бд, кеша или еще чего — другой исполняется.
              +3

              Странно, почему рубисты не говорят о Crystal, который по сути Go, только с фундаментом Ruby.

                +2
                Нишевой и пока еще сырой продукт. Хотя сам за ним слежу.
                  +1

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

                    0

                    Если бы Crystal быстрее развивался, то легко бы потеснил Go. Но за Go стоят практически неограниченные ресурсы гугла и легионы разрабов на волне хайпа. У Crystal маленькая команда разработчиков и про него мало кто слышал :(


                    Я уже сам написал пару мелких проектов на Crystal, но инфраструктура слабая, shard'ов (внешних модулей) мало, комьюнити небольшое. Печально, конечно.


                    В моём личном сравнении Go vs Crystal последний по удобству выигрывает с отрывом. Именно за счёт рубевого синтаксиса.

                      –2
                      Почему многие считают что Go используется на волне хайпа а не потому что это удобный и хороший язык?
                        +7
                        Не могу сказать за многих, но зато могу сказать за себя. Так вот, я не считаю его удобным и хорошим.
                          +1
                          Он был хорош лет 5 назад. Сейчас когда во многих языках есть и каналы и «зеленые» потоки Golang уже не выглядит так радужно. Так для справки — за эти годы операционные системы усовершенствовались и стали более эффективно работать с потоками + ядер у процессоров стало больше и на фоне этого «зеленые» потоки выглядят еще менее радужно.
                            –2
                            Суть в том что язык хорош и без этих потоков каналов. Да считается основной фишкой. Но он приятный и строгий сам по себе. Так что говорить о языке только по самой его известной фишке это странно
                              +1
                              Люди говорящие о технологии в рамках субъективных оценок (приятный, читаемый) вызывают у меня улыбку. Так, по моему у него омерзительный синтаксис и абсолютно нечитаемый код. По пробуйте мне доказать обратное. Это как с девушками — вот та вот мне не нравиться, и что бы вы не говорили она мне не будет нравиться, а вот внешность вот той нравиться. И чтобы бы вы не говорили это ничего не поменяет. Таково мое субъективное мнение поэтому Golang — уродливый, неприятный язык с ужасным синтаксисом, ни читаемым кодом и утиной типизацией через интерфейсы что уже делает его не строгим а значит не надежным.
                      0

                      Вообще никак не нишевой. Он одного класса с Go. Но что сырой, это да, нужно согласиться :(

                        0
                        Нишевой он в том плане, что расчитан на рубистов как основную аудиторию. Ну и комьюнити у него (пока) маленькое.
                      –9
                      Странно, почему ни кто не вспомнил про elixir :)
                        +8
                        В статье он три раза встречается. Вы о чем?
                        0
                        Еще есть Elixir, но я думаю и его и Crystal будет ждать участь CoffeScript.
                          0

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


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

                            0
                            Не совсем понял причем здесь WASM.
                            Я имелл ввиду что-то вроде:
                            Сначала появился Ruby, довольно быстро стал популярным, но сейчас дела у него так-себе.
                            Пример Coffescript может быть поучительным, т.к. это был Javascript со вкусом Ruby, но сейчас на нем пишут полтора человека.
                            Тот же Elixir — Erlang с синтаксисом Ruby. Будущее у него туманное. Я за ним слежу, и даже есть один проект в продакшене. Но по динамике развития, складывается ощущение, что там один Жозе его развивает (это видно по статискике github).
                            Ну и с ваших слов «Crystal, который по сути Go».

                            Ну и если в Ruby новые разработчити не идут, то и в эти языки они тоже не пойдут, т.к. работы меньше, коммьюнити меньше, на и на stackoverflow ответов меньше. А из этого вытекает то, что и для бизнеса это становится большим риском.
                              +1
                              CoffeeScript вымер потому, что это костыль над JS, который выкинули, когда es6 стал популярнее. А Crystal — это самодостаточная, независимая технология. Странно сравнивать Crystal и CS просто по «схожести» синтаксиса с Ruby.
                                0
                                Не ради холивара, но например Typescript растет очень хорошо сейчас, хотя по сути тот-же костыль над Javascript.
                                  0
                                  Да, совсем забыл про него. Вот тоже вариант для перехода для рубистов — TypeScipt. Можно и клиент и сервер писать на нем. Отличный язык. Почему про него никто в статье не говорит мне не понятно.
                                +1
                                Пример Coffescript может быть поучительным, т.к. это был Javascript со вкусом Ruby, но сейчас на нем пишут полтора человека.

                                Возможно, привкус Python не понравился)
                                А вообще, скорее из-за того, что появился Babel, а потом и сам JS (ES) стали активней развивать.
                                И почему это у Ruby дела не очень? Сам язык то продолжает так же развиваться. 3-я версия в активной разработке с существенными изменениями.
                                  0
                                  И почему это у Ruby дела не очень?

                                  Это конечно просто мое личное наблюдение, но очень мало вакансий. В моем location всего один стартап запустился с Ruby за последние пару лет (из тех 20-30 о которых пишут и говорят).
                                  Да и огромное количество статей «как мы мигрировали с Ruby на ЧЧЧ» тоже не добавляют популярности.

                                    0
                                    А на чём пишут остальные стартапы? Не на JS, случаем? Осмелюсь предположить, что некоторые отдают предпочтение Python. К тому же он уже наконец то переключился на 3.7. Ну и PHP вроде бодренько стал развиваться. И если речь о России, то это не удивительно, у нас довольно инертный рынок в этом плане. В остальном мире Ruby вполне успешно применяется.
                                    А по поводу миграции — это вполне закономерное развитие проектов. Если они «выстреливают». Ruby не самый производительный, но он позволяет быстро писать.
                                      0
                                      А на чём пишут остальные стартапы?

                                      В моем городе половина или немного больше половины на Python, немного на JS и PHP, кстати есть пара на Elixir и один известный на Ruby (я тут имею ввиду стартапы про которые пишут).
                                      У стартапов тренд на Python, т.к. BigData, AI и т.д.
                                    –1
                                    Поэтому — githut 2
                                    +1

                                    Если бы CoffeeScript выбирали исключительно из-за синтаксиса, то он и сейчас бы здравствовал. А его выбирали из-за возможностей: в JS тогда не было классов и даже стрелочных функций. Соответственно и умер он из-за того, что в JS появились сравнимые возможности.


                                    А WASM здесь при том, что подавляющее большинство языков, которые не приспособятся к Web, ждет неизбежное забвение.

                                      0
                                      Я за ним слежу, и даже есть один проект в продакшене. Но по динамике развития, складывается ощущение, что там один Жозе его развивает (это видно по статискике github).

                                      Хм, так вы посмотрите статистику за 2018-й год. На долю Жозе приходится примерно половина коммитов, но как минимум ещё 9 человек активно участвовали.
                                      Но в целом, смотреть динамику развития Elixir по компилятору не очень правильно. Основное развитие идёт в тулинге и в сопутствующих библиотеках. Например, из свеженького Phoenix LiveView

                                  0
                                  Говорим с коллегами о нем уже 8 лет, но дальше разговоров дело не идет. Экзотика-с…
                                    –1
                                    Мне вот больше интересно почему рубисты не говорят о Python.
                                    +26
                                    Например, Максимом Индыковым из Staply, чья команда переезжает с Ruby на Go


                                    Это чтобы через ~5 лет снова переехать на новый хайповый язык?
                                      +3
                                      Если он будет еще лучше, то почему нет? Хайп здесь не при чем, у руби не осталось преимуществ, чтобы на нем оставаться.
                                        +2
                                        Одно точно осталось — синтаксис (среди однотипных).
                                          0
                                          Кому как. Никогда не считал руби читабельным и, судя по всему, я не один такой. У Go синтаксис тоже является одним и преимуществ. Кому-то важнее его читабельность, а не какая-то субъективная красота кода.
                                            +1
                                            Чем синтаксис Go отличается от С-подобных? У Ruby, например, возможность писать вызовы функций без пустых скобок значительно облегчает читабельность (меньше лишних символов). Хотя, некоторые этим злоупотребляют и этим только ухудшают читабельность. В нём минимум служебных слов (типа var, const, return). Возможность написания своего DSL (отличный пример — RSpec, который в другие языки даже стали копировать, или Chef).
                                              –1
                                              Тем, что его спецификацию можно прочитать и осмыслить за час другой, а потом читать код, в котором не будет неоднозначных конструкций практически. Без подсветки, без IDE, без всего, можно читать код и понимать, что и куда. Когда пишешь код, у тебя нет вариантов злоупотребления чем-то, выбора из тучи разных вариантов написания одного и того же — ты пишешь один раз и всегда одинаково, потому что по-другому и невозможно. Свобода выбора и ломать голову какой же сегодня выбрать способ инициализации переменной из десятка возможных — это не про Go.

                                              Символы без скобок — внизу пример есть, как это читается. Меньше не значит лучше. Go многословен, чтобы он читался всегда однозначно вне зависимости от контекста. Вы там конечно написали, что не имеет значения, но это величайшая глупость. Я должен знать, что это, потому что от этого зависит, кончится ли выполнение функции на этом или за этим одним идентификатором находится еще цепочка функций. Это объективный критерий читабельности и у Ruby с ним проблемы очевидно, раз он позволяет так писать.
                                                +1
                                                От части согласен. Но Ruby опасен для малоопытных разработчиков, он позволяет написать очень жуткий и сложный код. Если код нормально написан, то проблем с этим не возникает. Если это переменная, то к концу функции точно встретится её объявление.
                                                  –1
                                                  Go не полагается на опыт разработчиков, на их настроение, фантазию, честность, порядочность и т.д. Пишишешь или так, или никак. Из него намеренно вырезано как можно больше неортогональных дублирующих фич. Это конечно весело в плюсах каких-нить полдня потратить на раздумья, как и что написать, но, в конечном итоге, пользы от этого мало. Go позволяет просто писать и забыть о языке, синтаксисе, форматировании кода и многом другом. И это прекрасное ощущение, чем он видимо и заслужил строчку в топе самых любимых технологий из года в год, находясь заметно выше руби, который еще и в топе самых ненавистных находится.
                                                    +1
                                                    Это все конечно здорово, вот только этот самый Go не спрашивает меня, нужно ли это мне. И возникают потом вот такие перлы:
                                                    stackoverflow.com/questions/21743841/how-to-avoid-annoying-error-declared-and-not-used

                                                    Дебаг становится болью и страданием. Часть кода и импортируемых либ вечно закомменчена, потому что компилятор много на себя берет. Ходи вечно туда-сюда, то закомментируй, то раскомментируй кусок. Потом обязательно что-то забываешь раскомментить, из-за этого упадет в другом месте, и так далее.

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

                                                    На самом деле хороший язык в своей области, и писать на нем в целом приятно, но вот от этого момента у меня конкретно пригорает. Сколько лет прошло, а до сих пор не изменили это поведение.
                                          0
                                          Что значит не осталось преимуществ? Они исчезли, их украли? Просто это так странно по стороны смотрится — появляется очередная хайповая «прорывная» технология или язык, все на него пересаживаются и буквально носят на руках. А потом вдруг «ой, не осталось преимуществ». А в то же время другие товарищи как писали на java/.net/php так и пишут.
                                            0
                                            А другие переписывают частично или полностью на другие языки, потому что они лучше для этого подходят. Go получил популярность не из-за гугла, который никаким вообще местом не стоит за эти языком, а за счет популярности среди крупных разработчиков, которые доверили свой бизнес новой технологии. Целые стеки технологий, на которых сейчас что только не крутится, на нем написаны. Таже контейнерная революция, это целиком и полностью Go нынче.

                                            Да, преимущества исчезают внезапно, потому что все относительно. Пока нет лучшей альтеранативы, что-то будет преимуществом.
                                          +3

                                          Шел 10й год хайпа golang. Хайповали Avito, Ozone, Alibaba, Mail.ru…
                                          Хайп давно прошел. Давно идут дни спокойной и уверенной разработки.

                                            +1
                                            10 лет назад никакого хайпа вокруг Go не было. Кто-то на нем писал, безусловно, но именно хайп начался года 2-3 назад, когда все вдруг резко начали на него переходить.
                                              0
                                              А хайп этот появился, потому что кто-то переписал, увидел профит, и пошло поехало лавинообразно. Хайп не хайп, а Go вытеснил других, потому что лучше.
                                                0

                                                В своей ниже для своих задач. Полностью согласен.

                                                  0
                                                  А кого он вытеснил, собственно?
                                                    0
                                                    Любого, кто плохо подходил в конкретной нише в конкретном проекте. php, python, ruby, java, node.js — что только не переносили на него. Так он и набрал свою популярность. У людей были существующие системы, которые их чем-то не устраивали или даже устраивали, но было любопытно поиграться с новой штукой. Они переписывали ее части на Go и получали те или иные преимущества. Обычно это простота и скорость. Если это хайп, то это правильный вид хайпа, который позволил другим узнать об отличной технологии.
                                                      0
                                                      в конкретном проекте

                                                      Я бы уточнил — в конкретном этапе проекта. Или нынче все стартапы начинают сразу писать на Go?
                                                        0

                                                        Зависит от ниши, но да, стартовать на Go уже просто, поскольку библиотек стало много. Несколько лет назад писать прототип сразу на Го было тяжко. Я бы сказал, что есть некоторые проблемы а той нише, где рельсы и джанго, но и это вопрос времени. Синтаксис конечно после руби будет убог, но зато появится многопоточность и упростится поставка. Тут уж надо определяться.


                                                        Любопытнее было бы противопоставить, elexir и go.

                                                          +1
                                                          Ну главное отличие elixir — то, что он функциональный (а в вебе это редкое явление). И порог вхождения у него, пожалуй, значительно выше. Но мне он кажется очень интересным. И концепция Phoenix мне по душе.
                                                          0
                                                          Я не могу говорить за все стартапы, но на Go очень просто и быстро пишется, не знаю откуда этот миф взялся. Может быть на версии 1.0 на нем и было сложно писать, но сейчас библиотек море. А сам язык только помогает сделать что-то быстро и просто с первого раза.
                                                            +2
                                                            Чтобы эти библиотеки подключить надо разобраться с 100500 тулзов для их управления, папочки правильные в правильных местах создать и переменные окружения объявить =)

                                                            Вот тут про тулы для управления зависимостями

                                                            Так что про простоту работы с Go, всё хитрее чем кажется на самом деле. И сам язык не обладая достаточными абстракциями склоняет к написанию громадных простыней кода и жутких генераторов простыней кода.

                                                            У Go много преимуществ, но не перед Ruby — точно (кроме производительности, но чтобы это заметить надо с ооочень большими и сложными проектами работать). Это вообще из разных ниш и для разных задач языки.
                                                              –1
                                                              Вы бы сначала разобрались в вопросе. Управление зависимостями и организация проектов в Go одна из самых простых и прозрачных, которые я когда-либо видел.

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

                                                              Меня почему-то не склоняет. Склоняет обычно он тех, кто пришел из других языков и пытается писать на Go как на них.

                                                              У Go много преимуществ, но не перед Ruby — точно

                                                              Почему-то с него разработчики стабильно перебираются на Go. А ниши у них общие, это языки для бэкэнда в его самых разных проявлениях.
                                                                0
                                                                Склоняет обычно он тех, кто пришел из других языков и пытается писать на Go как на них.

                                                                По-моему, природа неприязни к Ruby аналогична)
                                                                Почему-то с него разработчики стабильно перебираются на Go. А ниши у них общие, это языки для бэкэнда в его самых разных проявлениях.

                                                                На Go перебираются прежде всего из-за его производительности и неприхотливости к ресурсам. Сомневаюсь, что удобство разработки является причиной. И ниши я бы всё же немного разделил. Ruby прямой конкурент Python. Они не исключительно для бэкенда, это языки общего назначения. На Go можно написать однофайловый скриптик и просто запустить?
                                                                  0
                                                                  Ruby прямой конкурент Python.
                                                                  Совершенно не конкуренты. Питон — это МЛ и анализ данных. Руби — это бекенд веб сервисов.

                                                                  На Go можно написать однофайловый скриптик и просто запустить?
                                                                  Да.
                                                                    0
                                                                    Совершенно не конкуренты. Питон — это МЛ и анализ данных. Руби — это бекенд веб сервисов.

                                                                    Ну это смотря с какой колокольни смотреть. Что если так?
                                                                    github.com/arbox/machine-learning-with-ruby
                                                                    github.com/vinta/awesome-python#web-frameworks
                                                                    Chef, Capistrano, Phusion Passenger, Mina, Puppet, Vagrant это разве бекенд веб сервисов?

                                                                    Хммм, а разве Go интерпретируемый?
                                                                      0

                                                                      github.com/arbox/machine-learning-with-ruby — ну это, конечно, по сравнению с тем, что есть в Python, баловство.

                                                                        0
                                                                        Ну это понятно, но всё же может что-то. А не только бекенд. Хоть какую-то конкуренцию оказывает (пытается).
                                                                        0
                                                                        Ну это смотря с какой колокольни смотреть. Что если так?
                                                                        Да как бы можно и на си писать веб-приложение, что не делает его конкурентом php :)

                                                                        Факт в том, что среди языков общего назначения никто не может переплюнуть python в области анализа данных. Да, в руби есть несколько либ для этого, но это совершенно не то. Питон — это готовая инфраструктура, тогда как руби — несколько кубиков.

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

                                                                        Хммм, а разве Go интерпретируемый?
                                                                        Нет, но вопрос ведь был не об этом. «На Go можно написать однофайловый скриптик и просто запустить?» На go можно написать код, сохранить его в файле main.go, а потом просто запустить его через go run main.go
                                                      0

                                                      Тогда уж 3-4 года назад, как минимум. Когда Лазада развернулась и создала с сотню рабочих мест для гошников.


                                                      Трудно такой долгий срок растущей популярности оправдывать только хайпом.

                                                      0
                                                      Согласен, особенно позабавила эта фраза — «Крупные компании во всю объявляют об использовании Go.»
                                                      Для Go до сих пор нет нормального инструментария для удобной разработки(не учитывая GoLang от JetBrains)
                                                        0
                                                        А что не так с позабавившей фразой?
                                                          0
                                                          Слишком голословное заявление
                                                          «Крупные компании» — слишком расплывчатое и индивидуальное понятие, для меня крупные компании это Microsoft, Oracle, Samsung и я что то не слышал что бы они продвигали Go. Только Google более менее в эту сторону смотрит.
                                                          Мне кажется как то так.
                                                            0

                                                            Еще раз давайте попробуем, Alibaba, Avito, Ozine, Booking.com, Mail.ru — пойдет, как большие компании?

                                                              –1
                                                              Еще раз давайте попробуем — «слишком расплывчатое и индивидуальное понятие»,
                                                              эта часть фразы понята?
                                                              Из перечисленных компаний на мой взгляд крупные Alibaba, Mail.ru, Ozone.
                                                              Про остальные я не слышал и не в курсе, насколько они «крупные».
                                                                0

                                                                Booking.com и avito — крупные. Посмотрите.


                                                                Но в любом случае, что-то новое открылось: крупные компании используют golang.


                                                                Кстати, Google.

                                                                  0
                                                                  Google да, тут понятно почему, а вот крупнейшие игроки на рынке ИТ, такие как Apple, Microsoft, Samsung, Amazon, Oracle его не продвигают и не «бегут» за этим языком.
                                                                  И я не совсем понимаю что вы подразумеваете под словом «крупные», вы про количество сотрудников или про суммарную площадь офисов?

                                                                  И да, среди российских компаний довольно много ИТ компаний которые продвигают Go, пишут что то для себя.
                                                                    0
                                                                    Подскажу тогда уж еще Tesla, SpaceX
                                                          –1
                                                          Во-первых, для Go не требуется обязательно IDE и это одно из его фич. Во-вторых, давно есть vscode. Ничего более не требуется.
                                                            0
                                                            А почему собственно не учитывать продукцию JetBrains?
                                                        –3
                                                        Как раз пытаюсь по знакомым знакомых найти фул стак веб разработчика с готовностью работать над проектом на ruby on rails. Сложно. Все в один голос говорят, что раньше это было хайпово — баловались, а сейчас сошло на нет.

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

                                                        Если есть желающие работать над долгосрочным проектом, просьба отписать в личку.
                                                          +3

                                                          А не по знакомым пытались искать?

                                                          –4
                                                          Perl хоронят уже 18 лет, так что у Ruby все еще впереди.
                                                            +4
                                                            Ruby никогда не был настолько популярен, как Perl в конце 90-х, когда на нем была написана наверное большая часть веба, до тех пор пока его не потеснил, а потом и практически вытеснил там PHP.
                                                              +7
                                                              В Букинге работаете?
                                                                +6
                                                                Perl уже давно похоронен и закопан
                                                                0
                                                                Мне понравилось высвеченное противоречие между хорошо читаемым синтаксисом (хотя в каком из современных языков он не?), и семантикой «Насколько хорош ruby для написания, настолько же отвратителен для чтения. Понять, что происходит бывает достаточно сложно». А best practices (rubocop) еще и усугубляет дело вместо того, чтобы исправлять.

                                                                На самом деле я даже с читаемостью синтаксиса не согласен.
                                                                def f
                                                                  ...
                                                                  a
                                                                end
                                                                

                                                                Что здесь a? Вызов функции a(), или ранее объявленная переменная 'a'?
                                                                  +2
                                                                  Cмотря что за многоточием скрывается.

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


                                                                  А best practices (rubocop) еще и усугубляет дело вместо того, чтобы исправлять.

                                                                  Могли бы вы привести пару-тройку примеров?
                                                                    +5
                                                                    За многоточием скрывается дофига строчек кода. И этот ваш вопрос как раз про читаемость кода, если мне нужно знать весь контекст чтобы понять нет ли здесь вызова функции, то это плохо читаемый язык. Длина имени никак на читаемость не влияет, особенно опять-таки в силу того, что в ruby не принять называть функции например get_a / set_a.

                                                                    Примеры? Их есть у меня
                                                                    1. Если бы style check всегда настаивал на том, что вызов функции должен быть со скобочками ( a() )
                                                                    2. style check не должен ругаться на return. Явный return показывает, что функция возвращает что-то осмысленное, и надо следить за результатом. Иначе можно сломать ее вставив новый код в конец (да даже просто добавив логгинг). Чтобы понять, что у функции есть значимое возвращаемое значение, нужно искать все места, где она используется.
                                                                    3. Это у же больше просто к физической читаемости, чем к семантической: почему a.positive? считается согласно чекеру лучше, чем a > 0? Может у меня слишком много классов образования, но мне это кажется просто неадекватным.
                                                                      0
                                                                      1. Если бы style check всегда настаивал на том, что вызов функции должен быть со скобочками ( a() )

                                                                      Это вы привыкли к идее, что функция — это со скобочками. Почитайте про Smalltalk — от него Ruby очень многое почерпнул, станет понятнее, почему можно без скобок жить.


                                                                      Чтобы понять, что у функции есть значимое возвращаемое значение

                                                                      В большинстве случаев возращаемое значение в руби значимо, из этого и стоит исходить.

                                                                        0

                                                                        А что вам мешает настроить rubocop под ваши правила?

                                                                          +3

                                                                          С первыми двумя пунктами можно почти согласиться, но и тут легко найти объяснения:


                                                                          1. Если "а" — это локальная переменная, то это будет подсвечено редактором. И дополнительная фича — если вы перенесете вычисление этой переменной в функцию, то не нужно будет её переименовывать.
                                                                          2. Можно и должно выделяться пустой строкой перед возвращаемым результатом. И лучше придерживаться, что любая функция возвращает осмысленное значение (на то она и функция).
                                                                          3. А тут ruby-way, ООП и основная фишка ruby. В случае с a.positive — переменная "а" — может быть чем угодно, например специфичным value-object, а не только числовым значением.
                                                                            0
                                                                            За многоточием скрывается дофига строчек кода

                                                                            Жаль, хорошо было бы по возможность разбить на несколько методов. И тогда контекст из, например, 5-ти строчек воспринимался бы лучше.
                                                                            в ruby не принять называть функции например get_a / set_a.

                                                                            Наверняка есть исключения, но, надеюсь, нигде не приняты такие названия функций. Имеется в виду, get/set_%одна-буква%.
                                                                            1. Если бы style check всегда настаивал на том, что вызов функции должен быть со скобочками ( a() )

                                                                            И я продолжу настаивать на том, что это вопрос подсветки редактора кода + некоей привычки.
                                                                            2. style check не должен ругаться на return. Явный return показывает, что функция возвращает что-то осмысленное, и надо следить за результатом. Иначе можно сломать ее вставив новый код в конец (да даже просто добавив логгинг). Чтобы понять, что у функции есть значимое возвращаемое значение, нужно искать все места, где она используется.

                                                                            Поправьте если не прав, это вы про случай, когда явный return можно опустить, так как больше функция не может отдавать ничего в принципе? Или линтер ругается на что-то другое?
                                                                            3. Это у же больше просто к физической читаемости, чем к семантической: почему a.positive? считается согласно чекеру лучше, чем a > 0? Может у меня слишком много классов образования, но мне это кажется просто неадекватным.

                                                                            safe navigation можно использовать с таким подходом, как вариант, но если вам прямо-таки не нравится этот линтер, — ничего же не мешает отрубить его в rubocop.yml.

                                                                            Простите, ваш изначальный тезис был про то, что rubocop/best practices делает ситуацию хуже. Я, возможно, вас неправильно понял. Наоборот, мне воспринялось, что вы говорите про то, что отсылки из style guide плохи.
                                                                          +1
                                                                          Что здесь a? Вызов функции a(), или ранее объявленная переменная 'a'?

                                                                          А не всё ли равно? Что от этого зависит?
                                                                            +3
                                                                            От этого зависит читаемость кода, которую мы здесь обсуждаем
                                                                              +1
                                                                              вряд ли человек, который пишет читаемый код, назовет функцию, или переменную «a».
                                                                                +5
                                                                                назовем ее user_context, вам легче стало?
                                                                                  0
                                                                                  Методы — глаголы.
                                                                                  Переменные — существительные.

                                                                                  Для того, чтобы их отличать, достаточно правильного именования.
                                                                                    0
                                                                                    Все бы хорошо, да вот английский язык очень любит одно и то же слово делать и глаголом, и существительным. Ну вот step например :) Разумеется, в каждом конкретном контексте можно обыгрывать сущность/действие по-разному, просто хотел отметить, что правильное именование — довольно-таки непростая задача.
                                                                                –3
                                                                                Не понимаю, как может влиять на читаемость переменная это или функция? Важно ведь возвращаемое значение. А читаемость больше зависит от именования сущностей и структуры кода.
                                                                                  0
                                                                                  Ну вот, заминусовали человека не_рубисты.

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

                                                                                  Например, определенный контроллер обрабатывает апи-запрос на создание пользователя. В теле этого контроллера будет строка, что-то вроде:
                                                                                  @user = User.create(create_params)

                                                                                  create_params на самом деле функция, описанная где-нибудь выше, но в этом случае используется как переменная. И это намного более читаемо, чем что-то вроде такого:
                                                                                  @user = User.create(create_params())

                                                                                  Зачем тут акцентировать скобками вызов функции? Какую пользу это принесет, кроме «в пхп/жс/питоне я привык, чтоб было так»?

                                                                                  А вот польза «без скобок» вполне очевидная — поведение не зависит от реализации. В других языках вызвать переменную как функцию — ошибка, вызвать функцию как переменную — ошибка. Изменил потом переменную на функцию или наоборот — и ходи потом во все места, где оно используется, исправляй.
                                                                                    +1
                                                                                    Изменил потом переменную на функцию или наоборот — и ходи потом во все места, где оно используется, исправляй.

                                                                                    Вот поэтому, видимо, скорость разработки на Ruby выше) Он позволяет сосредотачиваться на сути (предметной области), а не на реализации.
                                                                                      +2
                                                                                      Возможно потому же gitlab требует 4Gb оперативки и 2 ядра для 1 пользователя а gogs уживается на 1 ядре и 256Mb для 10.
                                                                                        +1

                                                                                        Так высокую прожорливость Ruby никто не отрицает. Но разве это следствие синтаксиса?

                                                                                          0
                                                                                          Проблема в языках не только и не столько в синтаксисе, но и в окружении — платформа, реализация. Язык может выглядеть идеально, но потреблять для своей работы огромные ресурсы и кому он будет нужен?
                                                                                            0
                                                                                            Некоторые особенности, конечно, оказывают влияние, но они же позволяют сокращать время разработки и добавляют гибкости и универсальности.
                                                                                            И в этом направлении работы активно ведутся — повышается скорость, улучшается сборщик мусора и т.д. Да и в плане окружения, сейчас всё больше встречается хостингов с поддержкой Ruby. PHP и Python тоже не всегда были быстрыми неприхотливыми.
                                                                                              0
                                                                                              Мы вот как-то пробовали поуэршелл скрипты. Работало, в целом, хорошо, но он отъедал 99% ресурсов памяти и процессора. И, в конце концов, вывешивал сервер намертво. Я, понимаю, удобно когда компьютер делает работу за программиста, но не такой же ценой? Переписали то же самое на Delphi, 1% времени + 20-30% занимаемой памяти. Что тут еще сказать?
                                                                                              .Net со сборкой мусора виноват был, если что.
                                                                                      0
                                                                                      Я как не рубист, хочу сказать что вижу тут две принципиально разных вещи. Передачу функции в одном случае, и передачу результатов выполнения функции в другом.

                                                                                      И это вовсе не добавляет понимания коду
                                                                                        +1
                                                                                        Именно. Если не знать руби, то так оно и выглядит.

                                                                                        В каком-нибудь javascript'e
                                                                                        function b() { return 42; }
                                                                                        a(b)
                                                                                        
                                                                                        и
                                                                                        function b() { return 42; }
                                                                                        a(b())
                                                                                        
                                                                                        означают совершенно разную логику. В первом случае мы в функцию а передали функцию б, которую можно будет вызвать внутри этой функции а. Во втором случае мы вызвали функцию б и результаты ее выполнения передали в функцию а.

                                                                                        Но в руби
                                                                                        def b
                                                                                          42
                                                                                        end
                                                                                        a(b)
                                                                                        
                                                                                        и
                                                                                        def b
                                                                                          42
                                                                                        end
                                                                                        a(b())
                                                                                        
                                                                                        и
                                                                                        b = 42
                                                                                        a(b)
                                                                                        
                                                                                        по результатам выполнения означают одно и то же. В первом случае мы вызвали функцию б, результаты ее выполнения передали в функцию а (не смотря на отсутствие скобок, это все равно вызов функции, а не ее передача в другую функцию). Во втором случае — то же самое. В третьем — мы вручную присвоили переменной данные и передали их в функцию а. В итоге, во всех трех случаях, на вход в функцию а поступит число 42.

                                                                                        Это удобно когда знаешь, и непривычно, когда не знаешь. Но оценка с точки зрения непривычности — не самая адекватная. Я, к примеру, совершенно не разбираюсь в c++. И, когда читаю исходник какого-либо интересного мне репозитория, чтобы разобраться в алгоритме, для меня код просто дико нечитаемый, приходится продираться сквозь него. Но это не значит, что синтаксис языка плох.
                                                                                          0
                                                                                          Ну вот тут я не соглашусь. Хороший язык должен вызывать как можно меньше WTF. Почти все современные языки имеют функции первого класса. Не только js, но python, golnang, kotlin, c#, perl, php… Даже С. Не говорю уж о функциональных языках.

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

                                                                                          С учетом современных тенденций использования функциональных подходов, то это еще одна причина потери популярности.
                                                                                            +2
                                                                                            «А тут ради сомнительно экономии двух скобок приходится извращаться с Proc. Я понимаю что выразительность языка была поставлена во главу его дизайна. Но тут они зашли слишком далеко, на мой взгляд.

                                                                                            С учетом современных тенденций использования функциональных подходов, то это еще одна причина потери популярности.»

                                                                                            Вы хотите сказать что Haskell менее функциональный язык чем другие тоже из-за того что в нём скобки необязательны? =)
                                                                                              –2
                                                                                              толсто.
                                                                                          +1
                                                                                          Вот пример из очень трендового и популярного JS:
                                                                                          Math.max() > Math.min()

                                                                                          Не смотря в доку, попробуйте угадать какой результат и почему?
                                                                                          Вроде бы и скобочки на месте стоят, а логики никакой…

                                                                                          P.S. А по поводу того что Руби в чём-то на другие языки не похож, это нормально, как ещё новые языки будут появляться, если они должны быть похожи на Си, например?
                                                                                            0
                                                                                            Еще из пхп можно примеры привести, у js много такого что его не красит ни разу.

                                                                                            Но, на всякий случай напомню что эта ветка про читаемость руби.
                                                                                              +2
                                                                                              Я хотел сказать что дело не в скобочках. Мало того, именно у меня, при разработке на Ruby ни разу в жизни не было дискомфорта из-за отсутствия/присутствия скобочек. Кода на нём получается очень мало (!), читается он всегда слева направо из-за умного, по японски аккуратного, уклона в ООП (мало какие языки могут этим похвастаться). И необязательность скобок позволяет легко заменять свойства объектов на методы без лишнего копипастинга, чем очень сильно упрощает рефакторинг.
                                                                                              И сценария где сложно разбираться в коде из-за того что вместо переменной выполняется какой-то метод объекта я даже представить не смог, буду благодарен за пример.
                                                                                          0
                                                                                          Это от лукавого объяснение, вы идете от результата и даете ему объяснение. Но есть нюанс. create_params() — вызывает метод объекта, а create_params — обращением к локальной переменной. И где в этой вашей стройной логике место @create_params — атрибуту объекта? Казалось бы тогда унификация должна быть в первую очередь между например функциями объекта и методами объекта. А так какая-то петрушка получается.

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

                                                                                          Ну а вы как хотите? В руби тоже самое. Если у вас были локальные переменные, в каждой функции своя, и вы решили поменять их на вызов функции, то тоже везде ходить и изменять. Скорее всего и имена переменных в каждом скопе свои были (если это не банальный user), ну и код, который этим переменным что-то присваивает ведь удалить нужно. Так что я что-то никакой магии не вижу.
                                                                                            0
                                                                                            И где в этой вашей стройной логике место @create_params — атрибуту объекта?

                                                                                            Для этого принято использовать attr_accessor/attr_reader, напрямую к переменным экземпляра обычно не обращаются.
                                                                                    +1
                                                                                    А в чём принципиальная разница?
                                                                                    Если это переменная — найти её элементарно, ибо она объявлена строго внутри этой функции (в руби строго с областью видимости переменных).
                                                                                    Если это метод он по неймспейсу ищется очень быстро, а если есть удобная возможность исполнять код (в тестах, например) там #source_location есть и другие замечательные плюшки.
                                                                                    –7
                                                                                    Руби имеет большую популярность в Японии и Китае. И синтаксис у него японский — многие конструкции читать надо справа налево как иероглифы сверху вниз. Там в Азии пусть и развивается.
                                                                                      +1
                                                                                      В Японии пишут или столбцово справого столбца к левому читая вниз. Или Слева на право как и у нас. Так что это вообще ни о чем аргумент. На счет Китайского не скажу
                                                                                        0

                                                                                        Ну программисты в Японии конечно есть очень задротистые интересные. Например, Yusuke Endoh, который написал знаменитую quine-relay — цепной квайн на 100 языках программирования. Он, кстати, рубист.

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

                                                                                          Вот в других языках легко примеры привести:
                                                                                          — например, «генераторы» в Python, Erlang, Elixir, Haskell, они вообще читаются от центра и во все стороны =)
                                                                                          — В JS, C++, Go и.т.п. есть постфиксный "++"
                                                                                          — В Clojure вообще можно пайпить во все стороны
                                                                                            0
                                                                                            например, «генераторы» в Python… вообще читаются от центра и во все стороны =)

                                                                                            Не уверен, что понял о чем вы.
                                                                                            Вот этот код читается: «возвести Х в квадрат для всех Х из множества VALUES, где Х четное»
                                                                                            [x*x for x in values if x.is_even()]
                                                                                              +1
                                                                                              Ну смотрите, множество итерируемых элементов по центру.
                                                                                              Условие фильтрации справа.
                                                                                              То есть чтобы понять над чем мы вообще проводим операцию, то смотрим в центр, потом направо, в конце налево. А генераторы могут быть сложнее + использоваться как выражение. Теперь пример этого же на Руби:
                                                                                              с магией(типа для команды опытных товарищей)
                                                                                               values.select(&:even?).map { |i| i * i }

                                                                                              без магии
                                                                                               values.select { |i| i.even? }.map { |i| i * i }


                                                                                              Читается в правильном порядке слева направо. Ничего не надо промежуточного запоминать, всё логично.
                                                                                                –1
                                                                                                values.select { |i| i.even? }.map { |i| i * i }

                                                                                                Это интересно. Я читаю ваш пример так:
                                                                                                1. Действие map { |i| i * i }
                                                                                                2. Ищу коллекцию values
                                                                                                3. И только потом условие select { |i| i.even? }

                                                                                                Генераторы в Python мне кажутся более математической записью, что-ли.
                                                                                                В общем видимо дело в привычке, а не в конкретном синтаксисе.
                                                                                          +1
                                                                                          Я бы сказал, что у руби сейчас некий период застоя. Плюсы языка никуда не делись, а хайп ушёл к Go и прочим. На нём всё ещё приятно писать и его также приятно читать.

                                                                                          А ещё мнения Павла очень сильно портят всю статью.
                                                                                            +1
                                                                                            Какой хайп, не подскажите? Уже сколько лет язык и сколько на нем написано а все хайп идет, все сидят и хайпуют наверное, страдают и хайпуют, верно?

                                                                                            Почему язык не может быть популярным из-за того что он удобный?
                                                                                              0
                                                                                              Каждый популярный язык в своё время считался или считается удобным. Зачастую языки создают, чтобы решить какие-то очень часто возникающие проблемы, ну или чтобы заполнить нишу. Из этого вполне закономерно следует, что такой язык удобен для своего круга задач.

                                                                                              8-10 лет назад такой же вопрос бы задали о руби, через 10 зададут ещё о каком-то языке.
                                                                                            +4
                                                                                            Лет 7 назад пришлось некоторое время работать над расширением некоей довольно приличного размера системы, написанной на Руби. Сам я занимался в основном «клаудификацией» и другими архитектурно/инфраструктурными вопросами — а программисты этот язык тихо ненавидели.
                                                                                            Основной причиной был трудночитаемый код, что в сочетании с приличной разницей в часовых поясах между частями команды приводило к постоянным проблемам с интеграцией изменений, сделанных разными людьми.
                                                                                            Еще одной проблемой (ни до того, ни после мной не встреченной) была зацикленность немногочисленных «гуру» на «Ruby-way» и DRY — что сильно сказывалось на code review, особенно если учесть что у каждого из гуру этот самый «way» был какой-то свой, особенный.
                                                                                            Ну и последнее — низкая производительность. На машинах, где Руби еле шевелился — потом система, переписанная на Java просто летала.
                                                                                              +1
                                                                                              Это прям мой опыт последние несколько лет ) Полюбить ruby так и не смог.
                                                                                                +2
                                                                                                Я видел много любителей сложного кода, но имхо они такое наделают на другом языке. Особенно нельзя таких подпускать к C++.

                                                                                                Мне ruby то как раз нравится тем что на нем можно писать для людей
                                                                                                  +1
                                                                                                  В сообществе Руби у этого есть целых две грани. С одной стороны — люди бьются за DRY доводя это до абсурда. С другой — какой-нибудь залетный миксин может сломать работающую и оттестированную систему (этим, кстати, начинает страдать и Python с развитием всяких хитрых фреймворков).
                                                                                                    0
                                                                                                    Питон страдает зоопарковостью, среди прочего. Куча веток всего, часто несовместимых. Нужно что-то сделать? Будь готов тянуть и ставить множество зависимостей. Другой код открыл? Он уже не работает с теми зависимостями, что первый. И не так просто это разрулить.
                                                                                                    Старая уже статья:
                                                                                                    habr.com/post/206024
                                                                                                      0
                                                                                                      Нужно что-то сделать? Будь готов тянуть и ставить множество зависимостей.

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

                                                                                                      Вы о чем? О pip и venv? За вечер можно разобраться как оно работает.
                                                                                                      Другой код открыл? Он уже не работает с теми зависимостями, что первый.

                                                                                                      Опять, причем тут Python, на любом языке тоже самое происходит.
                                                                                                        0
                                                                                                        Питон много чем страдает, а может и нет — но ветка была про Руби.
                                                                                                  0

                                                                                                  Очень много говорят о переезде существующих проектов с руби на whatever. Если разработчик говорит что меняет веру — то чаще всего слышу что на elixir. Интересно было бы услышать мнение команд, которые решили делать новый проект не на рельсах, а на том же Go.


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

                                                                                                    0
                                                                                                    Это судя по всему проблема всех всё-в-одном фреймворков, вне зависимости от языка.
                                                                                                    В какой-то момент твой прототип выростает в большое приложение и ты понимаешь, что ты завязан на этом фреймворке, а он тянет ресурсы.
                                                                                                      –1

                                                                                                      Это-то понятно. Меня интересует опыт разработчиков, решивших сразу делать все с расчетом на будущее с потребностью в производительности. Ну вот например, приносит ли такое решение в жертву тот же ActiveRecord (или еще что) со всеми его удобствами, если проект сходу пишется на том же Go?

                                                                                                        +1
                                                                                                        Меня скорее всего поправят, но судя по отзывам, с Go заментно медленнее происходит внедрение, особенно если это касается новых фич в большом проекте.
                                                                                                      +4

                                                                                                      Я как-то недавно присутствовал на совещании с потенциальными технологическими партнерами. И зашел у нас разговор по поводу тсогласования API наших сервисов.


                                                                                                      — Нам в вашем API будет нехватать фичи X.
                                                                                                      — Да, надо сделать, но это нужно выносить в отдельный сервис ибо под такое у нас сейчас нет ничего. Когда у нас там сроки?
                                                                                                      — Три месяца.
                                                                                                      — Блин, будем на Ruby тогда писать.
                                                                                                      — А обычно на чем?
                                                                                                      — Обычно на Go ибо производительнее, но за три месяца не успеем — разработка на Go дороже по человека часам. А потом перепишем, если выстрелит бизнес.


                                                                                                      Вот примерно такая у ребят мотивация. Мы тоже пишем на Go, но с Python. Обычно на Go пишем нечто долгоживущее в памяти и быстрое.

                                                                                                      +3
                                                                                                      > destruction в ES6

                                                                                                      Вот только оно не destruction, а destructuring.
                                                                                                        +9
                                                                                                        Я разрабатывал на Rails где-то с 2007 года, и вижу совершенно другие причины ухода популярности Ruby.

                                                                                                        Ruby On Rails был практически идеальным фреймворком для своей технологической эпохи — HTML + jQuery. Фронт и бэк отлично существовали в одном проекте, странички верстались на Haml/slim/erb, большая часть логики была в backend, и все это благодаря синтаксису ruby было очень приятно.

                                                                                                        Что поменялось?

                                                                                                        Произошла революция во фронте. React, Vue, Angular потребовали отдельных навыков и создали большее разделение между фронтом и бэком. Много кода стало уходить из шаблонов на фронт, интеграция Rails со всеми этими вещами не сказать что вызывает у меня восторг, а скорее желание держать фронт и бэк вообще раздельно как разные проекты.

                                                                                                        Количество логики в backend заметно уменьшилось и возникает желание держать его также на JS, чтобы не иметь разделения по компетенциям в команде.

                                                                                                        Также произошла революция ML, и возник огромный спрос на Python разработчиков, а дальше сработала логика — если в команде есть Python, давайте не будем плодить сущностей и давайте делать бэк на Python.

                                                                                                        Эти 2 тренда — миграция на Python и перенос логики во фронт и сделали Rails не столь уникальным и нужным.

                                                                                                        А вот как это побороть? Развивать ruby сообщество не только в сторону Rails, но и в сторону прикладного программирования — нормальные биндинги к GUI, библиотекам ML, чтобы можно было например писать комфортно GTK приложения на Ruby, но, боюсь, у сообщества нет на это ресурсов.

                                                                                                        Вообщем итог — просто сменилась технология веб разработки и ничего с этим не сделать, у Ruby и Rails останется ниша «приятного фреймворка для разработки API и статичных сайтов», но хайп уже просто в другом месте.
                                                                                                          0
                                                                                                          С этим соглашусь, сам начал потихоньку привыкать к Питону из-за наличия многих полезных либ.
                                                                                                          –1
                                                                                                          Эх, вот бы gitlab на go переписали, а то почти все ресурсы моего мини сервера скушал…
                                                                                                            +1
                                                                                                            Есть Gogs
                                                                                                              0
                                                                                                              Это да, пробовал. Gitlab подкупает своим «всё в одном». Есть сразу и канбан доска и CI встроенная. Было бы всё это в gogs
                                                                                                            –2

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


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


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

                                                                                                              +1
                                                                                                              Я тоже любил js, но потом появился nodejs и любовь прошла.
                                                                                                              +1

                                                                                                              Интересно, но ни в статье, ни в комментах никто не вспоминает .net

                                                                                                                0
                                                                                                                Да, интересно. У меня вот сложилось ощущение, что со стороны .net выглядит гораздо хуже, чем он есть. Как человек с довольно широким стеком, порой недоумеваю, почему его недолюбливают.
                                                                                                                  0
                                                                                                                  Эффект ореола.
                                                                                                                  Микрософт плохой, следовательно, .net тоже.
                                                                                                                  Да и .net Windows-only. Вот .net core — уже привлекает внимание и потихоньку начинает воспринимается всерьез.
                                                                                                                  0
                                                                                                                  У dotnet тренд такой-же как и у Ruby. Мне за последний год не пришло не одного предложения из стартапа на dotnet, или вакансии где сказали бы, что разрабатывать будут что-то новое. В основном банки и галеры, ну и какие-то большие конторы где нужно будет их внутреннее говно мамонта поддерживать. Ну и процентов 10 — таже фигня, но обещают, что будут задачи по миграции на dotnet core.
                                                                                                                  Сам по себе рынок у dotnet очень большой, но я не вижу что-бы на нем что-то начинали.
                                                                                                                    +1
                                                                                                                    У меня противоположные ощущения — крупные компании и стартапы принимают .NET Core очень хорошо. Видимо, все зависит от региона проживания.
                                                                                                                      0
                                                                                                                      Думаю вы правы. Каждый из своего болота на мир смотрит.
                                                                                                                    0
                                                                                                                    Кстати да. И это при том, что объемы разработки на .NET/Core на порядок превышают Ruby и тем более Go. Однако, у некоторых «все» переходят с Ruby на Go. Видимо, пребывание в пузыре — неизбежная болезнь любого разработчика.
                                                                                                                    0
                                                                                                                    Все равно все окажитесь в js, так что нода, и нечего тут думать.
                                                                                                                      0
                                                                                                                      Delphi, видимо, еще один язык пережил :) Мы как писали 15+ лет на нем так и продолжаем. Он до сих пор востребован и актуален. Это ли не успех языка?
                                                                                                                        0

                                                                                                                        У нас последний продукт на дельфях остался, старый монстр, но, думаю, тоже будет переписан

                                                                                                                          0
                                                                                                                          Куда переписываете и в чем причина?
                                                                                                                            0
                                                                                                                            Был монструозный десктоп, будем перетаскивать бэк на сервисы (.net core), и сделаем клиента под web. Причина — на дельфи осталось пара старых разрабов, но никто из потенциальных новичков не желает с ними работать, то есть команду практически нельзя расширить, плюс знания о проекте в данный момент полностью сосредоточены и замкнуты на паре человек. Поддерживать такой продукт опасно и неудобно.
                                                                                                                              0
                                                                                                                              Понятно. Мы на UniGUI переписали несколько проектов, более ста форм, толстые проекты довольно. Переписал сам за примерно месяц. Получилось всё — и бэк и фронт на delphi, очень удобно и совершенно неопасно :) Недавно еще несколько человек на проект взяли.
                                                                                                                        0
                                                                                                                        del
                                                                                                                          –1

                                                                                                                          Рельсы умерли.


                                                                                                                          Умерли потому, что менялись быстро. Большинство крупных проектов всё ещё работает на первой или второй версии. Хипстеры не осилили задачу портирования на распоследнюю версию и свалили пилить блокчейн на Elixir.

                                                                                                                            +1
                                                                                                                            В руби как и в php присутствует неконсистетность в названиях функций/методов стандатрной библиотеки, что порой расстраивает.
                                                                                                                              0
                                                                                                                              Вы бы пример привели хотя бы этой неконсистентности и языка, который более консистентен.
                                                                                                                                –1
                                                                                                                                ruby-doc.org/stdlib-2.5.3/libdoc/fileutils/rdoc/FileUtils.html#method-c-chown_R
                                                                                                                                ruby-doc.org/stdlib-2.5.3/libdoc/fileutils/rdoc/FileUtils.html#method-c-rm_f
                                                                                                                                copy_stream и cp, почему тогда не назвать copy_stream как cs?
                                                                                                                                Как и в php видимо у ruby идут вызовы в C библиотеки, а там как угнодно можно назвать
                                                                                                                                Это касательно ruby
                                                                                                                                Консистентность — C# — referencesource.microsoft.com/#mscorlib/system/io/stream.cs,f956b0c07e86df64
                                                                                                                                Java — docs.oracle.com/javase/7/docs/api
                                                                                                                                С неймингом все ок
                                                                                                                                  +1
                                                                                                                                  Полагаю, cp это для тех, кому привычно линуксовое название. Но у него есть псевдоним copy (для читабельности). Ну а под капотом действительно C.
                                                                                                                                    0
                                                                                                                                    Ну вот, видимо пожертвовали консистентностью в угоду привычности.
                                                                                                                                    Непонимаю за что минус
                                                                                                                                      0
                                                                                                                                      В мире дотнета конечно тоже есть прямые биндинги
                                                                                                                                      github.com/mono/mono/blob/master/mcs/class/Mono.Posix/Mono.Unix.Native/Syscall.cs#L4577
                                                                                                                                      Такие названия и интерфейсы связаны больше с миром Unix-подобных систем и там они отторжения не вызывают (то есть в других языках и технологиях на этих системах похожие интерфейсы)

                                                                                                                                      Пример что вы привели действительно представляет из себя либу с некрасивыми интерфейсами, но это исключение, а не правило для мира Ruby.
                                                                                                                              0
                                                                                                                              The Top Programming Languages 2018. (из анализа выборки в 300 языков)
                                                                                                                              spectrum.ieee.org/static/interactive-the-top-programming-languages-2018

                                                                                                                              P.S. Ryby на 13-м месте в этом рейтинге.
                                                                                                                                0
                                                                                                                                Кто такой это Павел Сережин? Зачем он тут? Только неадекватные заявления, снижающие ценность текста.
                                                                                                                                  0
                                                                                                                                  Знаком неплохо с Ruby, как ни странно — это не Ruby on Rails, а был RubyQt — биндинг Qt для руби. Использовался для разработки ERP системы. Очень неплохо зашел, так как писалось все в стиле unix-way — делались простые GUI скрины для каждой задачи, потом из одного меню вызывались.

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

                                                                                                                                  Сейчас работаю с web — бекэнд на Go. Думаю, что в плане производительности работы веб сервисов Go — вне конкуренции. Но написать быстро прототип Web приложения на Go кажется довольно трудным. Очень не хватает как раз готового фреймворка, чтобы не делать стандартные вещи руками. Но думаю, его и не будет из-за того, что Go не выразительный язык, много лапши с if err != nil

                                                                                                                                  Интересует такой момент. Можно ли использовать как раз оба продукта: Ruby on Rails для быстрого написания прототипа, а затем отдельные куски переписывать на Го (если проседает производительность)?
                                                                                                                                  По идее можно поставить перед ними Nginx и отдельные роуты, которые надо заоптимайзить, пробрасывать на Go сервисы.

                                                                                                                                  Кто-то делать так, может поделиться, насколько это жизнеспособно?

                                                                                                                                  Спасибо.

                                                                                                                                    0
                                                                                                                                    Интересует такой момент. Можно ли использовать как раз оба продукта: Ruby on Rails для быстрого написания прототипа, а затем отдельные куски переписывать на Го (если проседает производительность)?
                                                                                                                                    По идее можно поставить перед ними Nginx и отдельные роуты, которые надо заоптимайзить, пробрасывать на Go сервисы.
                                                                                                                                    Да, примерно так это будет выглядеть.

                                                                                                                                    Проблема, с которой будете сталкиваться — неподходящая архитектура. По факту, вы пишете монолит на рельсах, а потом решаете сделать микросервисы — часть на рельсах, часть на go. Но в монолите обычно разные куски сильно связаны друг с другом, а значит, вы будете писать повторяющиеся куски бизнес-логики и на рельсах и на go, дописывать отдельное приватное апи в рельсах — потому что go будет время от времени у них что-то спрашивать — и наоборот, рельсы будут что-то спрашивать у go.

                                                                                                                                    В общем — весело будет всем. Я бы сказал, что если есть такая возможность — лучше заморозить рельсы (или замедлить выход новых фич), параллельно писать приложение на go, а потом, когда оно будет готово, разом переключиться. Иначе — бардак обеспечен.
                                                                                                                                      0
                                                                                                                                      Сейчас разрабатываю мелкого и среднего размера api на Go. Хочу сказать (мое мнение), что на нем трудно описывать бизнес логику — маловато абстракций. И очень много ручной работы. Есть желание поделать именно web проект, а не только api, но на Го устанешь все писать). Поэтому посматриваю в сторону какого-нибудь фреймворка. Руби знаю, поэтому и написал про него. Смотрю — сейчас активно развивается PHP — но сам язык после руби, довольно уродливым показался. Хотя это всего лишь язык — инструмент. Возможно придется и его поизучать.
                                                                                                                                        0
                                                                                                                                        Писал на пыхе более десяти лет. Вообще писал много на чем, но основным ЯП все же была пыха. Это боль, муки страдания на проекте, сложнее какого-либо лендинга или блога. Каждый прогер пишет как хочет. Код не читаемый вообще. Язык полное днище. Ушел в Руби, так как уже кровь из глаз пошла, постоянно разгребать это жуткое легаси.
                                                                                                                                          –1
                                                                                                                                          Писать на Пыхе уметь надо) Я тоже работаю с ним немало лет и лучшего ЯП для разработке под веб так и не нашел. Под любую задачу можно найти массу готовых решений, гибкость максимальная, никаких проблем даже в крупных проектах. Нужно просто договариваться по соглашениям об организации кода и следовать им.

                                                                                                                                          Самое главное — избегать проектов-самописов, все делать на фреймворках. В идеале на одном (я выбрал Yii2).

                                                                                                                                          Изучал в разное время Python, Ruby — не зашли. Да, все красиво и изящно, но на рынке PHP нет равных. Синтаксис не кажется уродливым, он просто другой.

                                                                                                                                          Но тем не менее, эволюционировать надо и поэтому в свободное время начал изучать Go.
                                                                                                                                            0
                                                                                                                                            Самое главное — избегать проектов-самописов, все делать на фреймворках. В идеале на одном (я выбрал Yii2).

                                                                                                                                            Это очень дельное замечание. Только мне юи не зашел, пользовался ларкой, в основном. Но и на симфони было пару проектов.

                                                                                                                                            Но большинство крупных проектов-монстров на которых я работал — это были именно самописы. Спустя пол года такой работы в любой конторе, мне хотелось брать в руки автомат и всех стрелять! :))

                                                                                                                                            И главное начальство не хотело ничего трогать, менять, переходить на современные технологии. Мол 20 лет работало, еще столько же нам будет денег приносить. До разума не достучаться, тебя скорее уволят (хоть и ведущий разработчик), чем дадут что-то довести до ума.

                                                                                                                                            После последнего такого проекта, я окончательно решил сбежать с пыхи. У меня даже статейка есть сравнения ларки и рельсов (чисто мои личные ощущения): cleverman.org/post/laravel-ili-ruby-on-rails
                                                                                                                                          0
                                                                                                                                          А Buffalo не пробовали? Вроде похож на Rails. Да и ещё куча фреймворков есть на Go.
                                                                                                                                          У меня, кстати, аналогичное восприятие пыхи после руби)
                                                                                                                                          0
                                                                                                                                          Мне тоже php кажется уродливым — но я на нем лет 5 назад последний раз писал и не собираюсь возвращаться :) Хотя слышал, что он сейчас круто развивается.

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

                                                                                                                                          Если вы хотите делать веб приложения «старого типа», когда браузер по запросу получает готовую веб страницу — лучше рельсов до сих пор нет ничего. Если же «нового типа» — когда фронт отделен (вроде реакта, ангуляра или вуе) и рендерится самостоятельно в браузере, а от сервера требуется только апи — тут голые рельсы не идеально конечно подходят. Можно в этом случае либо использовать рельсы + grape (гем для описания апи) — я таким путем обычно иду, либо из отдельных гемов (грейп/синатра + актив рекорд + ...) собрать себе приложение — но тут ручной работы больше и часть «фишек» рельсов исчезают, либо вообще использовать nodejs — за счет асинхронности оно для апи-приложений хорошо подходит, но плохо, если нужно рендерить html.
                                                                                                                                            0
                                                                                                                                            Так ведь есть чудесный Rails API. В нем нет ничего лишнего. Я от рельсов вообще беру только роуты, контроллеры и модельки. При чем все модельки пустые с привязкой к таблицам постгреса. А все запросы нативные, которые я храню в репозиториях (подготовленные методы с запросами и биндингами). Скорость работы отличная. Гемы использую по минимуму, накидать свое решение можно очень быстро и самостоятельно на голом руби. Мое личное мнение, что если программист и не программист (у этого слова есть четкое определение), а всего лишь знает синтаксис ЯП, то он и скачет по фреймворкам и ЯП, в надежде облегчить себе жизнь. Только это ему не поможет.
                                                                                                                                              0
                                                                                                                                              Мне Rails API обычно бывает недостаточно. Причины 3:
                                                                                                                                              1. Самая незначительная. Все запросы, кроме crud, нужно добавлять в роутер по-отдельности.
                                                                                                                                              2. Валидация входных параметров. У грейпа она настолько крутая, что уже невозможно отказаться.
                                                                                                                                              3. Генерация документации по апи для фронтендеров. Я написал себе небольшой класс, который парсит апи и отдает json с его структурой. Плюс html страничку, которая берет этот json и превращает его в множество интерактивных форм для отправки тестовых апи запросов. Такой самописный swagger получился, т.к. оригинальный меня не устраивает в некоторых местах.
                                                                                                                                                0
                                                                                                                                                1. Это да. И часто у меня функционал, который описать ресурсом не получится. Очень много ручных роутов. Но я с этим живу, путем разбивания роутов на отдельные файлы, в которых роуты для конкретных сущностей.
                                                                                                                                                2. Я когда перешел на рельсы, то радовался, что валидатор находится в модели. Типа там, где ему и место. Как только пошли сложные данные, которые должны валидироваться, но не должны сохраняться в базу или на основе проверки менять данные для сохранения, то я понял, что так дело не пойдет. Пришлось писать свою обертку над стандартным валидатором, а для сущностей делать свои файлы валидаторов (где нужно со сложной логикой). Плюс подгонять их для работы с юнит тестами. Теперь хоть могу валидировать данные где угодно. Но это кастомное решение, над которым пришлось повозиться.
                                                                                                                                                3. Вот этим я не занимался. Мне проще глянуть в роуты, если я чего забыл. А для тестирования АПИ я использую Postman

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

                                                                                                                                                Поэтому я остановился на очень гибком ЯП (руби), с очень приятным синтаксисом. В конце концов, все эти разговоры о производительности очень часто звучат от людей, которые не знают, что это вообще такое. Многие сидят на небольших проектах, с дневной посещаемостью в пару тыс. человек, в лучшем случае. А большинство тормозов возникает из-за БД и больших пингов.
                                                                                                                                        0
                                                                                                                                        Боже мой! Как мне развидеть прочитанное?! Вся статья — это просто какой-то словесный понос! Примеров нет, каких-то описанных задач нет. Бизнес хочет экономить на ресурсах, это просто жесть! На каких ресурсах? Сэкономить на 32 гигах оперативы? С одной стороны говорят, что простой и понятный синтаксис, как вроде пишешь на английском, а потом говорят, что читать код невозможно. Вначале говорят, что ни хрена не развивается, мол все старое, а потом говорят, что развитие даже сейчас происходит. Все ноют про статическую типизацию (и это в интерпретируемом языке). На хрена она вам? Здесь строгая динамическая типизация. Ее более чем достаточно. Вся статья ни о чем! Одно какое-то бла-бла-бла. Пишут на руби и новые проекты и старые поддерживают! Вот уже альфа рельсов шестых вышла, релиз на подходе. Сам руби 2.5.3 в rvm доступна. Как вообще можно сравнивать Ruby с JS? Это же, млять, днище полное! Мол, пишет один, он такой из себя запупенный фулстек, но хочет уйти во фронт на реакте писать. Знать JS и React, как дополнительную технологию, я это еще понимаю, но уйти с бэкенда на фронт — это очень многое говорит о специалисте.

                                                                                                                                        Руби и рельсы живы и будут и дальше жить. Это всего навсего инструмент. Отличный инструмент. А всякие хипстеры будут до конца дней своих скакать от технологии к технологии, разводя бизнес на бабки, внушая своим боссам, что важен именно ЯП, а не профессиональные специалисты, которые умеют строить архитектуру. На какой проект не попадешь, как откроешь запросы к БД, так, сука, плакать хочется. Ни индексов правильно расставить не умеют, ни запрос грамотно составить (вместо одного запроса тянут данные пятью и больше). Зато ЯП им виноват, давайте все на Go перепишем, он же быстрее.

                                                                                                                                        А из свежих проектов, которые появились на рельсах и реакте — это проект по расчету стройматериалов e-tamarin.com Так что используют руби и рельсы, и ГитХаб тоже все устраивает. Растет и развивается. А тот, кто вайтишник, ему всегда будет что-то мешать, то плохие ЯП, то сложные БД, то слабые сервера, то отсутствие четвертого вэбпака в серверном языке (это вообще был перл).

                                                                                                                                        Only users with full accounts can post comments. Log in, please.