Комментарии 32
Пересадить разработчиков на нишевый/непопулярный стек, чтобы никуда не убежали и своими офферами с требованием повышения зарплаты менеджмент не доставали - это, конечно, сберу ок. Но разработчикам-то это зачем?
По этой же, похоже, причине, в российской php-разработке нежно любят практически неизвестный за бугром Yii - гарантия того, что разработчик не наработает опыт, позволяющий ему переключиться на зарубежного работодателя.
Один мой знакомый подошёл к вопросу с противоположной точки зрения: специально подсаживает заказчиков на собственные Ruby-based решения, устраивая, таким образом, некоторый vendor lock-in.
Добрый день!
Мы обучаем ребят не только Ruby. Наши микросервисы пишутся на языке Go. Не вижу ничего плохого в желании людей расширять свой стек и стремиться стать сильнее. А по поводу “удержания” разработчиков, в этом уж точно нет никакой необходимости, так как компания предоставляет хорошие условия для комфортной работы сотрудников. Обстановка гармоничная, а обновление кадров происходит в рамках средней статистики, как и в других компаниях. Не стоит искать негативного смысла там, где его нет. Хорошего вам дня!
Сбер тут не причём, Сбер любит Java и ни на что ее не променяет.
>Сейчас нагрузка выросла, и мы постепенно переходим на микросервисы.
Перепишут на Go и "Всем Спасибо, дальше без Вас".
На hh.ru встречаются объявления поиска разработчиков на Perl со знанием Python или Go.
Наивно немного. В хороших командах ценятся сами люди, ибо хорошему инженеру не особо важно на каком языке решать задачу. Плюс старички знают как все устроено и какие исторические причины есть у тех или иных решений. А то может получиться как в анекдоте про швабры ...
превращают разработчиков других стеков в рубистов
Сразу вспомнилось прекрасное.it :)
Я тут делал одно тестовое задание на Руби, вот буквально — прототип накидать. Остался в полном недоумении, зачем в 2022 году это использовать.
Гемов мало, по сравнению с node.js — просто смехотворно. Даже самые популярные документированы исключительно плохо. А учитывая возможность расширять синтаксис, которой активно пользуются всякие фреймворки, программирование превращается в какую-то череду магических заклинаний — там подсмотрел один кусочек тайного знания, тут другой, всё в месте вроде б как-то пыхтит (правда, совершенно непонятно, как). Шаг влево-шаг право — и всё превращается в тыкву.
Расскажите что у вас там за стек такой на node js ? Если к фронтовым решениям я претензий не имею, то качество пакетов для бекенда очень хромает
Хм. А назовёте платформу, качество пакетов для бэкенда к которой не хромает? Установим бейзлайн, так сказать.
Ну вот чем вас тот же RoR не устроил?
Возможно прозвучит удивительно, но в той же PHP экосистеме вокруг популярных фреймвокров вполне нормальные пакеты. Вокруг того же РоР и спринга как мне кажется тоже. Вот к ноде вопросы. Почему то экспресс никак не прикратит свое существование
А, ясно. Пожалуй, на этом стоит закончить обсуждение.
А как же пачка других фреймворков и Nest как нынешний лидер? Возможно вы пропустили последние лет 8.
Какая пачка фреймворков ? Куча микрофрейморков которые заброшены, экспресс который прикратил развитие и давно не поддерживает новые возможности платформы. Ну и nest который к сожалению тащит за собой легаси наследие экспреса
Nest умеет работать и не только на базе Express, если он вам не нравится по каким-то причинам. Причём ядро можно выбрать в процессе или поменять на ходу. Про заброшенность всего и вся - хотелось бы каких-то графиков или сравнений, в моём мире оно очень даже живо.
У вас есть опыт смены адаптера в настоящем проекте ? Как минимум сломаются e2e тесты. Были проблемы со свагером ещё. И это если у вас auth не сделан с помощью passport'a, загрузка файлов через multer и нет никаких других мидлвар от express. Насчет заброшенности express можно посмотреть на то сколько времени 5 версия находится в alfa версии. Та же koa тоже непонятно в каком состоянии находиться. Многие пакеты для нее уже кучу лет не обновлялись.
Для baseline - .NET Core
Гм. И как же вы оценили качество, поделитесь методологией?
Я, скажу честно, под .NET не программировал с 2007 года. Но вот первый взгляд на статистику меня настораживает. Топ пакетов NuGet по их же официальной статистике:
Newtonsoft.Json — фреймворк для работы с JSON (что само по себе выглядит странно, что за платформа такая, что в 2022 году не поддерживает JSON нативно)
serilog — библиотека логирования
Castle.Core — набор из четырёх никак не связанных между собой пакетов [вот с таким вебсайтом](http://www.castleproject.org/) и документацией в виде .md-шек в репе
Swashbuckle.AspNetCore.Swagger — обёртка над сваггером
AWSSDK.Core — обёртка над AWS API
Итого, один пакет решает проблемы недоработанной платформы, одна либа логирования и две с половиной обёртки над чужими API. Что здесь примечательно? В топе нет ни одного пакета, который привносил бы в платформу какие-то новые возможности, которые выделили бы её среди других платформ.
Если честно, затрудняюсь понять, как оценить качество этого добра, и уж решительно не понимаю, бейзлайном чего это можно считать.
С пониманием как языка вся магия пропадает. А по поводу гемов - возможно, не все видят смысл в написании гемов для каждой незначительной задачки. И как по мне, так лучше минимизировать внешние зависимости (а то они потом ещё и переругаются).
Из текста так и не понял, зачем привязываться к руби. "Быстрый MVP для инвесторов" возможен сейчас, практически, на любом популярном стеке. К чему эта некрофилия? Зачем тратить лишние ресурсы на переобучение в то, что не имеет особых перспектив? Если у вас микросервисы, то вдвойне не понятно.
Отличная статья, спасибо большое!
Не понимаю хейта выше насчёт руби, чем он вам не угодил? Я вот руби разработчик и у нас в компании их очень много + постоянно нанимают рубистов и обучают с нуля на курсах. Очень много добротный проектов и куча стартапов на нем. А насчёт малого количества гемов - ощущение, что просто не смотрели их как следует)) к тому же язык постоянно обновляется, очень много классных вещей интегрируют. И если руби без перспектив, то почему все так любят Netflix и используют Github, которые написаны на Ruby?)
Статья отличная, было очень интересно читать и приятно осознавать, что крупная компания тоже готова развивать руби-сообщество!
Не понимаю хейта выше насчёт руби, чем он вам не угодил
Ну не то что бы не угодил но вот хотя бы объективный аргумент против:
benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/ruby-node.html
И если руби без перспектив, то почему все так любят Netflix и используют Github, которые написаны на Ruby
Допустим вам нравятся автомобили марки Мерседес. Вы любите на них кататься. Следуя такой логике можно ли утверждать что вам так же нравиться производитель манипуляторов для сварки самого дальнего угла, где-то под бензобаком, использовавшиеся при сборке?
Ну не то что бы не угодил но вот хотя бы объективный аргумент против:
benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/ruby-node.html
Существует достаточно задач, для которых скорость работы системы является наименьшей из проблем. И принимать решение о выборе инструмента по этому критерию - худшее что можно сделать.
Даже если нужна производительность, синтетические тесты едва ли отражают влияние на производительность системы в целом. База и любой ввод/вывод чаще займут время чуть менее чем полностью.
Существует достаточно задач, для которых скорость работы системы является наименьшей из проблем. И принимать решение о выборе инструмента по этому критерию — худшее что можно сделать.
1) Если бы руби позиционировали в комментарии как инструмент ТОЛЬКО для «неспешных» систем то и разговора бы не было.
2) даже если это наименьшая из проблем она важна при прочих приблизительно равных.
Даже если нужна производительность, синтетические тесты едва ли отражают влияние на производительность системы в целом. База и любой ввод/вывод чаще займут время чуть менее чем полностью.
Нет это не совсем так. В свое время переписав на одном проекте микросервис активно работающий с сетью и цпу с node на go(скачивание и парсинг xml-файлов и да на node были уже выжаты все возможные соки), мы сократили количество контейнеров в AWS в 10 раз. Не так давно был пост про node->rust и там тоже была разбежка по потреблению цпу в 10 раз.
Если бы там был руби то можно было бы еще умножать на 10.
Опыт twitter по переходу на Scala тоже чего-то да стоит.
А вот теперь учитывая вышесказанное — как CTO или бизнес овнер или программист который с нуля выбирает свой будущий стек, какие вы видите плюсы завязываться на инструмент про который с самого начала известно что:
а) имеет проблемы с хайрингом нужных спецов, о чем явно говорит эта статья
б) требует минимум в 10 раз больше серверов на любой чих в бизнес-логике
в) все хорошие идеи из флагманского фреймворка RoR перекочевали по конкурентам, в тот же Laravel/Spring Boot.
Если вы уже вложились в руби временем для получения экспертизы или деньгами то понятно что коней поменять на переправе будет стоить денег которые не факт что окупятся.
Но в чем же так хорош руби в 2022 году, по сравнению с тем же php, python, node(языки приблизительно одного порядка зрелости экосистемы и скорости разработки) для новых проектов, если он требует 10$ на инфраструктуру там, где конкуренты требуют 1$ а соискателей в 7 раз меньше(по данным статьи)? Примеры?
Думаю, если бы над руби работала та же команда с теми же ресурсами, что и над Node, то его скорость была бы точно выше. Но он развивается общественными силами.
а) имеет проблемы с хайрингом нужных спецов, о чем явно говорит эта статья
В статье говорится про найм, а с хайрингом (за рубежом) таких проблем нет.
б) требует минимум в 10 раз больше серверов на любой чих в бизнес-логике
Можно узнать откуда такие выводы и с чем сравнивалось?
Но в чем же так хорош руби в 2022 году, по сравнению с тем же php, python, node(языки приблизительно одного порядка зрелости экосистемы и скорости разработки)
Я бы назвал удобство синтаксиса. C Node я бы его не сравнивал - это всё же не язык. И к тому же специфический.
А как вы работаете с возражениями разработчиков ДО этапа онбординга?
«Руби мистически жив»: как в СберМаркете превращают разработчиков других стеков в рубистов