Последнее время, когда я говорю с разработчиками или компаниями, часто слышу одну и ту же историю разными словами — «мы писали на 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. Так что ответ очевиден.
Комментарии (158)
rumkin
20.12.2018 19:40+2Странно, почему рубисты не говорят о Crystal, который по сути Go, только с фундаментом Ruby.
divanikus
20.12.2018 20:49Нишевой и пока еще сырой продукт. Хотя сам за ним слежу.
rumkin
20.12.2018 02:07Во-первых, RoR тоже нишевый, а Go до сих пор местами очень сырой. Во-вторых, Crystal – язык общего назначения. В-третьих, чтобы новый язык развивался нужно о нем хотя бы говорить.
snp
20.12.2018 08:11Если бы Crystal быстрее развивался, то легко бы потеснил Go. Но за Go стоят практически неограниченные ресурсы гугла и легионы разрабов на волне хайпа. У Crystal маленькая команда разработчиков и про него мало кто слышал :(
Я уже сам написал пару мелких проектов на Crystal, но инфраструктура слабая, shard'ов (внешних модулей) мало, комьюнити небольшое. Печально, конечно.
В моём личном сравнении Go vs Crystal последний по удобству выигрывает с отрывом. Именно за счёт рубевого синтаксиса.
IgnisNoir
20.12.2018 14:12Почему многие считают что Go используется на волне хайпа а не потому что это удобный и хороший язык?
0xd34df00d
20.12.2018 17:22Не могу сказать за многих, но зато могу сказать за себя. Так вот, я не считаю его удобным и хорошим.
VanquisherWinbringer
20.12.2018 20:24Он был хорош лет 5 назад. Сейчас когда во многих языках есть и каналы и «зеленые» потоки Golang уже не выглядит так радужно. Так для справки — за эти годы операционные системы усовершенствовались и стали более эффективно работать с потоками + ядер у процессоров стало больше и на фоне этого «зеленые» потоки выглядят еще менее радужно.
IgnisNoir
21.12.2018 09:32Суть в том что язык хорош и без этих потоков каналов. Да считается основной фишкой. Но он приятный и строгий сам по себе. Так что говорить о языке только по самой его известной фишке это странно
VanquisherWinbringer
21.12.2018 14:07Люди говорящие о технологии в рамках субъективных оценок (приятный, читаемый) вызывают у меня улыбку. Так, по моему у него омерзительный синтаксис и абсолютно нечитаемый код. По пробуйте мне доказать обратное. Это как с девушками — вот та вот мне не нравиться, и что бы вы не говорили она мне не будет нравиться, а вот внешность вот той нравиться. И чтобы бы вы не говорили это ничего не поменяет. Таково мое субъективное мнение поэтому Golang — уродливый, неприятный язык с ужасным синтаксисом, ни читаемым кодом и утиной типизацией через интерфейсы что уже делает его не строгим а значит не надежным.
sentyaev
20.12.2018 23:12Еще есть Elixir, но я думаю и его и Crystal будет ждать участь CoffeScript.
rumkin
20.12.2018 02:09Все там будут, но сомневаюсь, что рубисты в данный момент смотрят на WASM, скорее на альтернативу для замены в недалекой перспективе.
UPD. Но вот языку, который начнет вытеснять других на WASMе, самое время начинать набирать силу.
sentyaev
20.12.2018 02:41Не совсем понял причем здесь WASM.
Я имелл ввиду что-то вроде:
Сначала появился Ruby, довольно быстро стал популярным, но сейчас дела у него так-себе.
Пример Coffescript может быть поучительным, т.к. это был Javascript со вкусом Ruby, но сейчас на нем пишут полтора человека.
Тот же Elixir — Erlang с синтаксисом Ruby. Будущее у него туманное. Я за ним слежу, и даже есть один проект в продакшене. Но по динамике развития, складывается ощущение, что там один Жозе его развивает (это видно по статискике github).
Ну и с ваших слов «Crystal, который по сути Go».
Ну и если в Ruby новые разработчити не идут, то и в эти языки они тоже не пойдут, т.к. работы меньше, коммьюнити меньше, на и на stackoverflow ответов меньше. А из этого вытекает то, что и для бизнеса это становится большим риском.constXife
20.12.2018 02:58CoffeeScript вымер потому, что это костыль над JS, который выкинули, когда es6 стал популярнее. А Crystal — это самодостаточная, независимая технология. Странно сравнивать Crystal и CS просто по «схожести» синтаксиса с Ruby.
sentyaev
20.12.2018 11:09Не ради холивара, но например Typescript растет очень хорошо сейчас, хотя по сути тот-же костыль над Javascript.
VanquisherWinbringer
20.12.2018 20:39Да, совсем забыл про него. Вот тоже вариант для перехода для рубистов — TypeScipt. Можно и клиент и сервер писать на нем. Отличный язык. Почему про него никто в статье не говорит мне не понятно.
k4ir05
20.12.2018 04:20Пример Coffescript может быть поучительным, т.к. это был Javascript со вкусом Ruby, но сейчас на нем пишут полтора человека.
Возможно, привкус Python не понравился)
А вообще, скорее из-за того, что появился Babel, а потом и сам JS (ES) стали активней развивать.
И почему это у Ruby дела не очень? Сам язык то продолжает так же развиваться. 3-я версия в активной разработке с существенными изменениями.sentyaev
20.12.2018 11:17И почему это у Ruby дела не очень?
Это конечно просто мое личное наблюдение, но очень мало вакансий. В моем location всего один стартап запустился с Ruby за последние пару лет (из тех 20-30 о которых пишут и говорят).
Да и огромное количество статей «как мы мигрировали с Ruby на ЧЧЧ» тоже не добавляют популярности.
k4ir05
20.12.2018 14:15А на чём пишут остальные стартапы? Не на JS, случаем? Осмелюсь предположить, что некоторые отдают предпочтение Python. К тому же он уже наконец то переключился на 3.7. Ну и PHP вроде бодренько стал развиваться. И если речь о России, то это не удивительно, у нас довольно инертный рынок в этом плане. В остальном мире Ruby вполне успешно применяется.
А по поводу миграции — это вполне закономерное развитие проектов. Если они «выстреливают». Ruby не самый производительный, но он позволяет быстро писать.sentyaev
21.12.2018 10:54А на чём пишут остальные стартапы?
В моем городе половина или немного больше половины на Python, немного на JS и PHP, кстати есть пара на Elixir и один известный на Ruby (я тут имею ввиду стартапы про которые пишут).
У стартапов тренд на Python, т.к. BigData, AI и т.д.
rumkin
20.12.2018 04:33Если бы CoffeeScript выбирали исключительно из-за синтаксиса, то он и сейчас бы здравствовал. А его выбирали из-за возможностей: в JS тогда не было классов и даже стрелочных функций. Соответственно и умер он из-за того, что в JS появились сравнимые возможности.
А WASM здесь при том, что подавляющее большинство языков, которые не приспособятся к Web, ждет неизбежное забвение.
j_wayne
20.12.2018 11:37Говорим с коллегами о нем уже 8 лет, но дальше разговоров дело не идет. Экзотика-с…
Matisumi
20.12.2018 21:27+1Например, Максимом Индыковым из Staply, чья команда переезжает с Ruby на Go
Это чтобы через ~5 лет снова переехать на новый хайповый язык?creker
20.12.2018 22:05+3Если он будет еще лучше, то почему нет? Хайп здесь не при чем, у руби не осталось преимуществ, чтобы на нем оставаться.
k4ir05
20.12.2018 04:23Одно точно осталось — синтаксис (среди однотипных).
creker
20.12.2018 11:38Кому как. Никогда не считал руби читабельным и, судя по всему, я не один такой. У Go синтаксис тоже является одним и преимуществ. Кому-то важнее его читабельность, а не какая-то субъективная красота кода.
k4ir05
20.12.2018 14:30Чем синтаксис Go отличается от С-подобных? У Ruby, например, возможность писать вызовы функций без пустых скобок значительно облегчает читабельность (меньше лишних символов). Хотя, некоторые этим злоупотребляют и этим только ухудшают читабельность. В нём минимум служебных слов (типа var, const, return). Возможность написания своего DSL (отличный пример — RSpec, который в другие языки даже стали копировать, или Chef).
creker
20.12.2018 15:28Тем, что его спецификацию можно прочитать и осмыслить за час другой, а потом читать код, в котором не будет неоднозначных конструкций практически. Без подсветки, без IDE, без всего, можно читать код и понимать, что и куда. Когда пишешь код, у тебя нет вариантов злоупотребления чем-то, выбора из тучи разных вариантов написания одного и того же — ты пишешь один раз и всегда одинаково, потому что по-другому и невозможно. Свобода выбора и ломать голову какой же сегодня выбрать способ инициализации переменной из десятка возможных — это не про Go.
Символы без скобок — внизу пример есть, как это читается. Меньше не значит лучше. Go многословен, чтобы он читался всегда однозначно вне зависимости от контекста. Вы там конечно написали, что не имеет значения, но это величайшая глупость. Я должен знать, что это, потому что от этого зависит, кончится ли выполнение функции на этом или за этим одним идентификатором находится еще цепочка функций. Это объективный критерий читабельности и у Ruby с ним проблемы очевидно, раз он позволяет так писать.k4ir05
20.12.2018 16:08+1От части согласен. Но Ruby опасен для малоопытных разработчиков, он позволяет написать очень жуткий и сложный код. Если код нормально написан, то проблем с этим не возникает. Если это переменная, то к концу функции точно встретится её объявление.
creker
20.12.2018 19:02-1Go не полагается на опыт разработчиков, на их настроение, фантазию, честность, порядочность и т.д. Пишишешь или так, или никак. Из него намеренно вырезано как можно больше неортогональных дублирующих фич. Это конечно весело в плюсах каких-нить полдня потратить на раздумья, как и что написать, но, в конечном итоге, пользы от этого мало. Go позволяет просто писать и забыть о языке, синтаксисе, форматировании кода и многом другом. И это прекрасное ощущение, чем он видимо и заслужил строчку в топе самых любимых технологий из года в год, находясь заметно выше руби, который еще и в топе самых ненавистных находится.
Kroid
20.12.2018 19:49Это все конечно здорово, вот только этот самый Go не спрашивает меня, нужно ли это мне. И возникают потом вот такие перлы:
stackoverflow.com/questions/21743841/how-to-avoid-annoying-error-declared-and-not-used
Дебаг становится болью и страданием. Часть кода и импортируемых либ вечно закомменчена, потому что компилятор много на себя берет. Ходи вечно туда-сюда, то закомментируй, то раскомментируй кусок. Потом обязательно что-то забываешь раскомментить, из-за этого упадет в другом месте, и так далее.
А ведь решение простое — пусть компилятор компилирует, а линтер проверяет на все эти неиспользуемые переменные. По отдельности. Или флаг какой-нибудь ввести, чтобы управлять поведением компилятора. Но нет, разработчики языка же самые умные, давайте мол, заставим всех писать так, а не иначе.
На самом деле хороший язык в своей области, и писать на нем в целом приятно, но вот от этого момента у меня конкретно пригорает. Сколько лет прошло, а до сих пор не изменили это поведение.
Matisumi
20.12.2018 11:27Что значит не осталось преимуществ? Они исчезли, их украли? Просто это так странно по стороны смотрится — появляется очередная хайповая «прорывная» технология или язык, все на него пересаживаются и буквально носят на руках. А потом вдруг «ой, не осталось преимуществ». А в то же время другие товарищи как писали на java/.net/php так и пишут.
creker
20.12.2018 11:33А другие переписывают частично или полностью на другие языки, потому что они лучше для этого подходят. Go получил популярность не из-за гугла, который никаким вообще местом не стоит за эти языком, а за счет популярности среди крупных разработчиков, которые доверили свой бизнес новой технологии. Целые стеки технологий, на которых сейчас что только не крутится, на нем написаны. Таже контейнерная революция, это целиком и полностью Go нынче.
Да, преимущества исчезают внезапно, потому что все относительно. Пока нет лучшей альтеранативы, что-то будет преимуществом.
JekaMas
20.12.2018 11:03Шел 10й год хайпа golang. Хайповали Avito, Ozone, Alibaba, Mail.ru…
Хайп давно прошел. Давно идут дни спокойной и уверенной разработки.Matisumi
20.12.2018 11:2410 лет назад никакого хайпа вокруг Go не было. Кто-то на нем писал, безусловно, но именно хайп начался года 2-3 назад, когда все вдруг резко начали на него переходить.
creker
20.12.2018 11:30А хайп этот появился, потому что кто-то переписал, увидел профит, и пошло поехало лавинообразно. Хайп не хайп, а Go вытеснил других, потому что лучше.
Matisumi
20.12.2018 12:00А кого он вытеснил, собственно?
creker
20.12.2018 12:43Любого, кто плохо подходил в конкретной нише в конкретном проекте. php, python, ruby, java, node.js — что только не переносили на него. Так он и набрал свою популярность. У людей были существующие системы, которые их чем-то не устраивали или даже устраивали, но было любопытно поиграться с новой штукой. Они переписывали ее части на Go и получали те или иные преимущества. Обычно это простота и скорость. Если это хайп, то это правильный вид хайпа, который позволил другим узнать об отличной технологии.
k4ir05
20.12.2018 14:35в конкретном проекте
Я бы уточнил — в конкретном этапе проекта. Или нынче все стартапы начинают сразу писать на Go?acmnu
20.12.2018 14:59Зависит от ниши, но да, стартовать на Go уже просто, поскольку библиотек стало много. Несколько лет назад писать прототип сразу на Го было тяжко. Я бы сказал, что есть некоторые проблемы а той нише, где рельсы и джанго, но и это вопрос времени. Синтаксис конечно после руби будет убог, но зато появится многопоточность и упростится поставка. Тут уж надо определяться.
Любопытнее было бы противопоставить, elexir и go.
k4ir05
20.12.2018 16:36+1Ну главное отличие elixir — то, что он функциональный (а в вебе это редкое явление). И порог вхождения у него, пожалуй, значительно выше. Но мне он кажется очень интересным. И концепция Phoenix мне по душе.
creker
20.12.2018 15:34Я не могу говорить за все стартапы, но на Go очень просто и быстро пишется, не знаю откуда этот миф взялся. Может быть на версии 1.0 на нем и было сложно писать, но сейчас библиотек море. А сам язык только помогает сделать что-то быстро и просто с первого раза.
youlose
20.12.2018 16:26+1Чтобы эти библиотеки подключить надо разобраться с 100500 тулзов для их управления, папочки правильные в правильных местах создать и переменные окружения объявить =)
Вот тут про тулы для управления зависимостями
Так что про простоту работы с Go, всё хитрее чем кажется на самом деле. И сам язык не обладая достаточными абстракциями склоняет к написанию громадных простыней кода и жутких генераторов простыней кода.
У Go много преимуществ, но не перед Ruby — точно (кроме производительности, но чтобы это заметить надо с ооочень большими и сложными проектами работать). Это вообще из разных ниш и для разных задач языки.creker
20.12.2018 19:45Вы бы сначала разобрались в вопросе. Управление зависимостями и организация проектов в Go одна из самых простых и прозрачных, которые я когда-либо видел.
И сам язык не обладая достаточными абстракциями склоняет к написанию громадных простыней кода и жутких генераторов простыней кода.
Меня почему-то не склоняет. Склоняет обычно он тех, кто пришел из других языков и пытается писать на Go как на них.
У Go много преимуществ, но не перед Ruby — точно
Почему-то с него разработчики стабильно перебираются на Go. А ниши у них общие, это языки для бэкэнда в его самых разных проявлениях.k4ir05
21.12.2018 01:40Склоняет обычно он тех, кто пришел из других языков и пытается писать на Go как на них.
По-моему, природа неприязни к Ruby аналогична)
Почему-то с него разработчики стабильно перебираются на Go. А ниши у них общие, это языки для бэкэнда в его самых разных проявлениях.
На Go перебираются прежде всего из-за его производительности и неприхотливости к ресурсам. Сомневаюсь, что удобство разработки является причиной. И ниши я бы всё же немного разделил. Ruby прямой конкурент Python. Они не исключительно для бэкенда, это языки общего назначения. На Go можно написать однофайловый скриптик и просто запустить?
JekaMas
20.12.2018 11:31Тогда уж 3-4 года назад, как минимум. Когда Лазада развернулась и создала с сотню рабочих мест для гошников.
Трудно такой долгий срок растущей популярности оправдывать только хайпом.
Splo1ter
20.12.2018 14:31Согласен, особенно позабавила эта фраза — «Крупные компании во всю объявляют об использовании Go.»
Для Go до сих пор нет нормального инструментария для удобной разработки(не учитывая GoLang от JetBrains)JekaMas
20.12.2018 15:07А что не так с позабавившей фразой?
Splo1ter
20.12.2018 16:28Слишком голословное заявление
«Крупные компании» — слишком расплывчатое и индивидуальное понятие, для меня крупные компании это Microsoft, Oracle, Samsung и я что то не слышал что бы они продвигали Go. Только Google более менее в эту сторону смотрит.
Мне кажется как то так.JekaMas
20.12.2018 16:37Еще раз давайте попробуем, Alibaba, Avito, Ozine, Booking.com, Mail.ru — пойдет, как большие компании?
Splo1ter
20.12.2018 16:50Еще раз давайте попробуем — «слишком расплывчатое и индивидуальное понятие»,
эта часть фразы понята?
Из перечисленных компаний на мой взгляд крупные Alibaba, Mail.ru, Ozone.
Про остальные я не слышал и не в курсе, насколько они «крупные».JekaMas
20.12.2018 17:13Booking.com и avito — крупные. Посмотрите.
Но в любом случае, что-то новое открылось: крупные компании используют golang.
Кстати, Google.
Splo1ter
20.12.2018 17:33Google да, тут понятно почему, а вот крупнейшие игроки на рынке ИТ, такие как Apple, Microsoft, Samsung, Amazon, Oracle его не продвигают и не «бегут» за этим языком.
И я не совсем понимаю что вы подразумеваете под словом «крупные», вы про количество сотрудников или про суммарную площадь офисов?
И да, среди российских компаний довольно много ИТ компаний которые продвигают Go, пишут что то для себя.
creker
20.12.2018 15:35Во-первых, для Go не требуется обязательно IDE и это одно из его фич. Во-вторых, давно есть vscode. Ничего более не требуется.
AndreDeBonk
20.12.2018 21:52Как раз пытаюсь по знакомым знакомых найти фул стак веб разработчика с готовностью работать над проектом на ruby on rails. Сложно. Все в один голос говорят, что раньше это было хайпово — баловались, а сейчас сошло на нет.
Хоть бери и сам изучай его. Но как человек вне веб разработки, боюсь что буду лепить сложные велосипеды, и на это уйдет нерациальное количество времени.
Если есть желающие работать над долгосрочным проектом, просьба отписать в личку.
le1ic
19.12.2018 23:46Мне понравилось высвеченное противоречие между хорошо читаемым синтаксисом (хотя в каком из современных языков он не?), и семантикой «Насколько хорош ruby для написания, настолько же отвратителен для чтения. Понять, что происходит бывает достаточно сложно». А best practices (rubocop) еще и усугубляет дело вместо того, чтобы исправлять.
На самом деле я даже с читаемостью синтаксиса не согласен.
def f ... a end
Что здесь a? Вызов функции a(), или ранее объявленная переменная 'a'?Mayurifag
20.12.2018 02:06Cмотря что за многоточием скрывается.
Но на практике, во время реальной разработки, вы, скорее всего, пользуетесь каким угодно редактором с подсветкой синтаксиса. И вот эта самая подсветка обычно работает отлично, решая запрашиваемую проблему тем, что по умолчанию красит вызов функции и вывод содержимого переменной в разные цвета.СпойлерА ещё, скорее всего, функции с таким однобуквенным названием вам не встретится.le1ic
20.12.2018 08:30За многоточием скрывается дофига строчек кода. И этот ваш вопрос как раз про читаемость кода, если мне нужно знать весь контекст чтобы понять нет ли здесь вызова функции, то это плохо читаемый язык. Длина имени никак на читаемость не влияет, особенно опять-таки в силу того, что в ruby не принять называть функции например get_a / set_a.
Примеры? Их есть у меня
1. Если бы style check всегда настаивал на том, что вызов функции должен быть со скобочками ( a() )
2. style check не должен ругаться на return. Явный return показывает, что функция возвращает что-то осмысленное, и надо следить за результатом. Иначе можно сломать ее вставив новый код в конец (да даже просто добавив логгинг). Чтобы понять, что у функции есть значимое возвращаемое значение, нужно искать все места, где она используется.
3. Это у же больше просто к физической читаемости, чем к семантической: почему a.positive? считается согласно чекеру лучше, чем a > 0? Может у меня слишком много классов образования, но мне это кажется просто неадекватным.snp
20.12.2018 09:04- Если бы style check всегда настаивал на том, что вызов функции должен быть со скобочками ( a() )
Это вы привыкли к идее, что функция — это со скобочками. Почитайте про Smalltalk — от него Ruby очень многое почерпнул, станет понятнее, почему можно без скобок жить.
Чтобы понять, что у функции есть значимое возвращаемое значение
В большинстве случаев возращаемое значение в руби значимо, из этого и стоит исходить.
ZurgInq
20.12.2018 14:55С первыми двумя пунктами можно почти согласиться, но и тут легко найти объяснения:
- Если "а" — это локальная переменная, то это будет подсвечено редактором. И дополнительная фича — если вы перенесете вычисление этой переменной в функцию, то не нужно будет её переименовывать.
- Можно и должно выделяться пустой строкой перед возвращаемым результатом. И лучше придерживаться, что любая функция возвращает осмысленное значение (на то она и функция).
- А тут ruby-way, ООП и основная фишка ruby. В случае с a.positive — переменная "а" — может быть чем угодно, например специфичным value-object, а не только числовым значением.
Mayurifag
21.12.2018 00:59За многоточием скрывается дофига строчек кода
Жаль, хорошо было бы по возможность разбить на несколько методов. И тогда контекст из, например, 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 плохи.
k4ir05
20.12.2018 06:59Что здесь a? Вызов функции a(), или ранее объявленная переменная 'a'?
А не всё ли равно? Что от этого зависит?le1ic
20.12.2018 08:31От этого зависит читаемость кода, которую мы здесь обсуждаем
k4ir05
20.12.2018 10:25Не понимаю, как может влиять на читаемость переменная это или функция? Важно ведь возвращаемое значение. А читаемость больше зависит от именования сущностей и структуры кода.
Kroid
20.12.2018 16:12+1Ну вот, заминусовали человека не_рубисты.
Когда начинаешь этим пользоваться, понимаешь, насколько это удобно — когда «a» может быть хоть переменной, хоть функцией, и тебе на это плевать.
Например, определенный контроллер обрабатывает апи-запрос на создание пользователя. В теле этого контроллера будет строка, что-то вроде:
@user = User.create(create_params)
create_params на самом деле функция, описанная где-нибудь выше, но в этом случае используется как переменная. И это намного более читаемо, чем что-то вроде такого:
@user = User.create(create_params())
Зачем тут акцентировать скобками вызов функции? Какую пользу это принесет, кроме «в пхп/жс/питоне я привык, чтоб было так»?
А вот польза «без скобок» вполне очевидная — поведение не зависит от реализации. В других языках вызвать переменную как функцию — ошибка, вызвать функцию как переменную — ошибка. Изменил потом переменную на функцию или наоборот — и ходи потом во все места, где оно используется, исправляй.k4ir05
20.12.2018 16:47+1Изменил потом переменную на функцию или наоборот — и ходи потом во все места, где оно используется, исправляй.
Вот поэтому, видимо, скорость разработки на Ruby выше) Он позволяет сосредотачиваться на сути (предметной области), а не на реализации.boblenin
20.12.2018 20:21Возможно потому же gitlab требует 4Gb оперативки и 2 ядра для 1 пользователя а gogs уживается на 1 ядре и 256Mb для 10.
k4ir05
21.12.2018 01:19Так высокую прожорливость Ruby никто не отрицает. Но разве это следствие синтаксиса?
Groramar
21.12.2018 10:05Проблема в языках не только и не столько в синтаксисе, но и в окружении — платформа, реализация. Язык может выглядеть идеально, но потреблять для своей работы огромные ресурсы и кому он будет нужен?
k4ir05
21.12.2018 13:45Некоторые особенности, конечно, оказывают влияние, но они же позволяют сокращать время разработки и добавляют гибкости и универсальности.
И в этом направлении работы активно ведутся — повышается скорость, улучшается сборщик мусора и т.д. Да и в плане окружения, сейчас всё больше встречается хостингов с поддержкой Ruby. PHP и Python тоже не всегда были быстрыми неприхотливыми.Groramar
21.12.2018 15:24Мы вот как-то пробовали поуэршелл скрипты. Работало, в целом, хорошо, но он отъедал 99% ресурсов памяти и процессора. И, в конце концов, вывешивал сервер намертво. Я, понимаю, удобно когда компьютер делает работу за программиста, но не такой же ценой? Переписали то же самое на Delphi, 1% времени + 20-30% занимаемой памяти. Что тут еще сказать?
.Net со сборкой мусора виноват был, если что.
kivsiak
20.12.2018 18:35Я как не рубист, хочу сказать что вижу тут две принципиально разных вещи. Передачу функции в одном случае, и передачу результатов выполнения функции в другом.
И это вовсе не добавляет понимания кодуKroid
20.12.2018 19:33Именно. Если не знать руби, то так оно и выглядит.
В каком-нибудь 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())
по результатам выполнения означают одно и то же. В первом случае мы вызвали функцию б, результаты ее выполнения передали в функцию а (не смотря на отсутствие скобок, это все равно вызов функции, а не ее передача в другую функцию). Во втором случае — то же самое. В третьем — мы вручную присвоили переменной данные и передали их в функцию а. В итоге, во всех трех случаях, на вход в функцию а поступит число 42.b = 42 a(b)
Это удобно когда знаешь, и непривычно, когда не знаешь. Но оценка с точки зрения непривычности — не самая адекватная. Я, к примеру, совершенно не разбираюсь в c++. И, когда читаю исходник какого-либо интересного мне репозитория, чтобы разобраться в алгоритме, для меня код просто дико нечитаемый, приходится продираться сквозь него. Но это не значит, что синтаксис языка плох.kivsiak
20.12.2018 22:02Ну вот тут я не соглашусь. Хороший язык должен вызывать как можно меньше WTF. Почти все современные языки имеют функции первого класса. Не только js, но python, golnang, kotlin, c#, perl, php… Даже С. Не говорю уж о функциональных языках.
А тут ради сомнительно экономии двух скобок приходится извращаться с Proc. Я понимаю что выразительность языка была поставлена во главу его дизайна. Но тут они зашли слишком далеко, на мой взгляд.
С учетом современных тенденций использования функциональных подходов, то это еще одна причина потери популярности.youlose
21.12.2018 02:41«А тут ради сомнительно экономии двух скобок приходится извращаться с Proc. Я понимаю что выразительность языка была поставлена во главу его дизайна. Но тут они зашли слишком далеко, на мой взгляд.
С учетом современных тенденций использования функциональных подходов, то это еще одна причина потери популярности.»
Вы хотите сказать что Haskell менее функциональный язык чем другие тоже из-за того что в нём скобки необязательны? =)
youlose
21.12.2018 02:51Вот пример из очень трендового и популярного JS:
Math.max() > Math.min()
Не смотря в доку, попробуйте угадать какой результат и почему?
Вроде бы и скобочки на месте стоят, а логики никакой…
P.S. А по поводу того что Руби в чём-то на другие языки не похож, это нормально, как ещё новые языки будут появляться, если они должны быть похожи на Си, например?kivsiak
21.12.2018 03:21Еще из пхп можно примеры привести, у js много такого что его не красит ни разу.
Но, на всякий случай напомню что эта ветка про читаемость руби.youlose
21.12.2018 03:43Я хотел сказать что дело не в скобочках. Мало того, именно у меня, при разработке на Ruby ни разу в жизни не было дискомфорта из-за отсутствия/присутствия скобочек. Кода на нём получается очень мало (!), читается он всегда слева направо из-за умного, по японски аккуратного, уклона в ООП (мало какие языки могут этим похвастаться). И необязательность скобок позволяет легко заменять свойства объектов на методы без лишнего копипастинга, чем очень сильно упрощает рефакторинг.
И сценария где сложно разбираться в коде из-за того что вместо переменной выполняется какой-то метод объекта я даже представить не смог, буду благодарен за пример.
le1ic
21.12.2018 00:55Это от лукавого объяснение, вы идете от результата и даете ему объяснение. Но есть нюанс. create_params() — вызывает метод объекта, а create_params — обращением к локальной переменной. И где в этой вашей стройной логике место @create_params — атрибуту объекта? Казалось бы тогда унификация должна быть в первую очередь между например функциями объекта и методами объекта. А так какая-то петрушка получается.
Изменил потом переменную на функцию или наоборот — и ходи потом во все места, где оно используется, исправляй.
Ну а вы как хотите? В руби тоже самое. Если у вас были локальные переменные, в каждой функции своя, и вы решили поменять их на вызов функции, то тоже везде ходить и изменять. Скорее всего и имена переменных в каждом скопе свои были (если это не банальный user), ну и код, который этим переменным что-то присваивает ведь удалить нужно. Так что я что-то никакой магии не вижу.k4ir05
21.12.2018 02:03И где в этой вашей стройной логике место @create_params — атрибуту объекта?
Для этого принято использовать attr_accessor/attr_reader, напрямую к переменным экземпляра обычно не обращаются.
youlose
21.12.2018 03:57А в чём принципиальная разница?
Если это переменная — найти её элементарно, ибо она объявлена строго внутри этой функции (в руби строго с областью видимости переменных).
Если это метод он по неймспейсу ищется очень быстро, а если есть удобная возможность исполнять код (в тестах, например) там #source_location есть и другие замечательные плюшки.
egaxegax
20.12.2018 00:20Руби имеет большую популярность в Японии и Китае. И синтаксис у него японский — многие конструкции читать надо справа налево как иероглифы сверху вниз. Там в Азии пусть и развивается.
IgnisNoir
20.12.2018 14:17+1В Японии пишут или столбцово справого столбца к левому читая вниз. Или Слева на право как и у нас. Так что это вообще ни о чем аргумент. На счет Китайского не скажу
KvanTTT
20.12.2018 22:13Ну программисты в Японии конечно есть очень
задротистыеинтересные. Например, Yusuke Endoh, который написал знаменитую quine-relay — цепной квайн на 100 языках программирования. Он, кстати, рубист.
youlose
21.12.2018 04:09Можете привести пример где такой код?
Как раз в руби код читается сверху вниз и далее слева направо в большинстве случаев и надо очень сильно не в стиле руби писать чтобы было как вы говорите.
Вот в других языках легко примеры привести:
— например, «генераторы» в Python, Erlang, Elixir, Haskell, они вообще читаются от центра и во все стороны =)
— В JS, C++, Go и.т.п. есть постфиксный "++"
— В Clojure вообще можно пайпить во все стороныsentyaev
21.12.2018 11:03например, «генераторы» в Python… вообще читаются от центра и во все стороны =)
Не уверен, что понял о чем вы.
Вот этот код читается: «возвести Х в квадрат для всех Х из множества VALUES, где Х четное»
[x*x for x in values if x.is_even()]youlose
21.12.2018 11:26Ну смотрите, множество итерируемых элементов по центру.
Условие фильтрации справа.
То есть чтобы понять над чем мы вообще проводим операцию, то смотрим в центр, потом направо, в конце налево. А генераторы могут быть сложнее + использоваться как выражение. Теперь пример этого же на Руби:
с магией(типа для команды опытных товарищей)
values.select(&:even?).map { |i| i * i }
без магии
values.select { |i| i.even? }.map { |i| i * i }
Читается в правильном порядке слева направо. Ничего не надо промежуточного запоминать, всё логично.sentyaev
21.12.2018 13:34values.select { |i| i.even? }.map { |i| i * i }
Это интересно. Я читаю ваш пример так:
1. Действиеmap { |i| i * i }
2. Ищу коллекциюvalues
3. И только потом условиеselect { |i| i.even? }
Генераторы в Python мне кажутся более математической записью, что-ли.
В общем видимо дело в привычке, а не в конкретном синтаксисе.
411
20.12.2018 00:48Я бы сказал, что у руби сейчас некий период застоя. Плюсы языка никуда не делись, а хайп ушёл к Go и прочим. На нём всё ещё приятно писать и его также приятно читать.
А ещё мнения Павла очень сильно портят всю статью.IgnisNoir
20.12.2018 14:18Какой хайп, не подскажите? Уже сколько лет язык и сколько на нем написано а все хайп идет, все сидят и хайпуют наверное, страдают и хайпуют, верно?
Почему язык не может быть популярным из-за того что он удобный?411
20.12.2018 23:55Каждый популярный язык в своё время считался или считается удобным. Зачастую языки создают, чтобы решить какие-то очень часто возникающие проблемы, ну или чтобы заполнить нишу. Из этого вполне закономерно следует, что такой язык удобен для своего круга задач.
8-10 лет назад такой же вопрос бы задали о руби, через 10 зададут ещё о каком-то языке.
Paskin
20.12.2018 01:35Лет 7 назад пришлось некоторое время работать над расширением некоей довольно приличного размера системы, написанной на Руби. Сам я занимался в основном «клаудификацией» и другими архитектурно/инфраструктурными вопросами — а программисты этот язык тихо ненавидели.
Основной причиной был трудночитаемый код, что в сочетании с приличной разницей в часовых поясах между частями команды приводило к постоянным проблемам с интеграцией изменений, сделанных разными людьми.
Еще одной проблемой (ни до того, ни после мной не встреченной) была зацикленность немногочисленных «гуру» на «Ruby-way» и DRY — что сильно сказывалось на code review, особенно если учесть что у каждого из гуру этот самый «way» был какой-то свой, особенный.
Ну и последнее — низкая производительность. На машинах, где Руби еле шевелился — потом система, переписанная на Java просто летала.Mox
20.12.2018 14:33Я видел много любителей сложного кода, но имхо они такое наделают на другом языке. Особенно нельзя таких подпускать к C++.
Мне ruby то как раз нравится тем что на нем можно писать для людейPaskin
21.12.2018 16:14+1В сообществе Руби у этого есть целых две грани. С одной стороны — люди бьются за DRY доводя это до абсурда. С другой — какой-нибудь залетный миксин может сломать работающую и оттестированную систему (этим, кстати, начинает страдать и Python с развитием всяких хитрых фреймворков).
shybovycha
20.12.2018 01:40Очень много говорят о переезде существующих проектов с руби на whatever. Если разработчик говорит что меняет веру — то чаще всего слышу что на elixir. Интересно было бы услышать мнение команд, которые решили делать новый проект не на рельсах, а на том же Go.
По личному опыту знаю, что накидать небольшую приложуху или прототип на рельсах — крайне удобно. Да даже большой проект стартовать и позднее — поддерживать — очень приятно (в плане удобства ЯП и фреймворка). Некоторые части со временем требуют оптимизации, это да. А вот чтобы сходу на Go и достаточно большое приложение — это вообще возможно?
willyd
20.12.2018 05:46Это судя по всему проблема всех всё-в-одном фреймворковб вне зависимости от языка.
В какой-то момент твой прототип выростает в большое приложение и ты понимаешь, что ты завязан на этом фреймворке, а он тянет ресурсы.shybovycha
20.12.2018 05:52Это-то понятно. Меня интересует опыт разработчиков, решивших сразу делать все с расчетом на будущее с потребностью в производительности. Ну вот например, приносит ли такое решение в жертву тот же ActiveRecord (или еще что) со всеми его удобствами, если проект сходу пишется на том же Go?
willyd
20.12.2018 06:07Меня скорее всего поправят, но судя по отзывам, с Go заментно медленнее происходит внедрение, особенно если это касается новых фмч в большом проекте.
acmnu
20.12.2018 09:40+1Я как-то недавно присутствовал на совещании с потенциальными технологическими партнерами. И зашел у нас разговор по поводу тсогласования API наших сервисов.
— Нам в вашем API будет нехватать фичи X.
— Да, надо сделать, но это нужно выносить в отдельный сервис ибо под такое у нас сейчас нет ничего. Когда у нас там сроки?
— Три месяца.
— Блин, будем на Ruby тогда писать.
— А обычно на чем?
— Обычно на Go ибо производительнее, но за три месяца не успеем — разработка на Go дороже по человека часам. А потом перепишем, если выстрелит бизнес.
Вот примерно такая у ребят мотивация. Мы тоже пишем на Go, но с Python. Обычно на Go пишем нечто долгоживущее в памяти и быстрое.
Mox
20.12.2018 14:30+3Я разрабатывал на 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 и статичных сайтов», но хайп уже просто в другом месте.411
20.12.2018 23:38С этим соглашусь, сам начал потихоньку привыкать к Питону из-за наличия многих полезных либ.
sanchezzzhak
20.12.2018 18:06Я наверное один извращенец, который любит js и готов на нем писать все и вся...
Руби пробовал по работе, с каким-то аддовым шаблононизатором, шаг влево или вправо и проект не стартует, как у меня горело бордовым пламенем, на разработчиков, которые придумали использовать этот гем.
С тех пор я руби даже не воспринимаю в серьез, вот так поделка написанная, кем-то может убить желание использовать язык.
Vahman
20.12.2018 19:55Интересно, но ни в статье, ни в комментах никто не вспоминает .net
fillpackart
20.12.2018 20:58Да, интересно. У меня вот сложилось ощущение, что со стороны .net выглядит гораздо хуже, чем он есть. Как человек с довольно широким стеком, порой недоумеваю, почему его недолюбливают.
Crafter2012
21.12.2018 00:22Эффект ореола.
Микрософт плохой, следовательно, .net тоже.
Да и .net Windows-only. Вот .net core — уже привлекает внимание и потихоньку начинает воспринимается всерьез.
sentyaev
21.12.2018 00:51У dotnet тренд такой-же как и у Ruby. Мне за последний год не пришло не одного предложения из стартапа на dotnet, или вакансии где сказали бы, что разрабатывать будут что-то новое. В основном банки и галеры, ну и какие-то большие конторы где нужно будет их внутреннее говно мамонта поддерживать. Ну и процентов 10 — таже фигня, но обещают, что будут задачи по миграции на dotnet core.
Сам по себе рынок у dotnet очень большой, но я не вижу что-бы на нем что-то начинали.dunkan_macleod
21.12.2018 12:46У меня противоположные ощущения — крупные компании и стартапы принимают .NET Core очень хорошо. Видимо, все зависит от региона проживания.
dunkan_macleod
21.12.2018 12:37Кстати да. И это при том, что объемы разработки на .NET/Core на порядок превышают Ruby и тем более Go. Однако, у некоторых «все» переходят с Ruby на Go. Видимо, пребывание в пузыре — неизбежная болезнь любого разработчика.
Groramar
20.12.2018 20:33Delphi, видимо, еще один язык пережил :) Мы как писали 15+ лет на нем так и продолжаем. Это ли не успех языка?
mikhailian
20.12.2018 20:49Рельсы умерли.
Умерли потому, что менялись быстро. Большинство крупных проектов всё ещё работает на первой или второй версии. Хипстеры не осилили задачу портирования на распоследнюю версию и свалили пилить блокчейн на Elixir.
Splo1ter
21.12.2018 10:09В руби как и в php присутствует неконсистетность в названиях функций/методов стандатрной библиотеки, что порой расстраивает.
youlose
21.12.2018 10:23Вы бы пример привели хотя бы этой неконсистентности и языка, который более консистентен.
Splo1ter
21.12.2018 10:50ruby-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
С неймингом все окk4ir05
21.12.2018 15:02+1Полагаю, cp это для тех, кому привычно линуксовое название. Но у него есть псевдоним copy (для читабельности). Ну а под капотом действительно C.
Splo1ter
21.12.2018 15:04Ну вот, видимо пожертвовали консистентностью в угоду привычности.
Непонимаю за что минусyoulose
21.12.2018 22:11В мире дотнета конечно тоже есть прямые биндинги
github.com/mono/mono/blob/master/mcs/class/Mono.Posix/Mono.Unix.Native/Syscall.cs#L4577
Такие названия и интерфейсы связаны больше с миром Unix-подобных систем и там они отторжения не вызывают (то есть в других языках и технологиях на этих системах похожие интерфейсы)
Пример что вы привели действительно представляет из себя либу с некрасивыми интерфейсами, но это исключение, а не правило для мира Ruby.
FForth
21.12.2018 13:43The Top Programming Languages 2018. (из анализа выборки в 300 языков)
spectrum.ieee.org/static/interactive-the-top-programming-languages-2018
P.S. Ryby на 13-м месте в этом рейтинге.
magic2k
21.12.2018 22:33Кто такой это Павел Сережин? Зачем он тут? Только неадекватные заявления, снижающие ценность текста.
vba
Больше всего мне в Руби не хватает асинхронного программирования и огорчает полнейшее отсутствие неизменяемых структур данных. No future.
kt97679
github.com/eventmachine/eventmachine
apidock.com/ruby/Object/freeze
vba
Со всех трибун кричат что ни в коем случае не следует использовать эвент машин, ибо он устарел. Даже если им пользоваться, не припомню подобной лаконичности как например здесь:
Про заморозку объектов я промолчу, no comment
kt97679
Пожалуйста прокомментируйте что не так с заморозкой? Я о ней знаю только из документации, на практике не использовал, так что возможно я упускаю что-то важное.
То, что eventmachine устарел честно говоря тоже слышу первый раз. Можно вас попросить привести аргументы критиков или ссылку дать на соответствующий материал?
kana-desu
Неизменяемые структуры хороши не только тем, что они не изменяются (это тоже плюс, это гарантия для нас, что никто ничего не сделает с нашими данными, значит можно легко шарить их по ссылке), а что мы можем эффективно работать с ними, создавая новые данные на основе старых без полного копирования. Зачастую это древовидные структуры в основе своей. Возможно нужно еще и гц тюнить под это
Фриз ничего такого не предоставляет.
kt97679
Можно попросить вас уточнить какую версию руби вы сейчас имели в виду?
ZurgInq
Интересно чем же eventmachine устарел?
Асинхронное программирование само по себе имеет узкую нишу и если этой технологии не находится применение в большинстве случаев, не означает, что он устарел. В это же время асинхронные http библиотеки могут спокойно использовать под капотом eventmachine и никто не кричит, что они устарели.
gdt
Интересно, какую такую узкую нишу имеет асинхронное программирование. Любое взаимодействие с внешним миром — работа с сетью, чтение/запись на диск и т. д. гораздо проще выражается при использовании асинхронного кода, нежели мешаниной callback'ов. Зависит конечно от самого языка и от того, что конкретно разрабатывается.
ZurgInq
Типичное веб приложение не генерирует десятки запросов в сеть или на диск в контексте пользовательского запроса. Если это интерактивная веб страничка (пусть даже очень нагруженный интернет магазин, блог или форум), там скорей всего не будет сетевых запросов во внешние сервисы или обращений в диск мимо БД. А бизнес логика как правило имеет синхронную природу. Асинхронность в node.js или golang даёт преимущество или при очень высоких нагрузках (много входящих запросов) или в специфичных случаях, когда само приложение генерирует много запросов\трафика.
youlose
*удалил* (неправильно понял ответ)
gdt
Точно, речь же идёт про веб-приложения, а я тут со своими десктопными понятиями :)