Comments 184
Больше всего мне в Руби не хватает асинхронного программирования и огорчает полнейшее отсутствие неизменяемых структур данных. No future.
Со всех трибун кричат что ни в коем случае не следует использовать эвент машин, ибо он устарел. Даже если им пользоваться, не припомню подобной лаконичности как например здесь:
Про заморозку объектов я промолчу, no comment
Пожалуйста прокомментируйте что не так с заморозкой? Я о ней знаю только из документации, на практике не использовал, так что возможно я упускаю что-то важное.
То, что eventmachine устарел честно говоря тоже слышу первый раз. Можно вас попросить привести аргументы критиков или ссылку дать на соответствующий материал?
То, что eventmachine устарел честно говоря тоже слышу первый раз. Можно вас попросить привести аргументы критиков или ссылку дать на соответствующий материал?
Неизменяемые структуры хороши не только тем, что они не изменяются (это тоже плюс, это гарантия для нас, что никто ничего не сделает с нашими данными, значит можно легко шарить их по ссылке), а что мы можем эффективно работать с ними, создавая новые данные на основе старых без полного копирования. Зачастую это древовидные структуры в основе своей. Возможно нужно еще и гц тюнить под это
Фриз ничего такого не предоставляет.
Интересно чем же eventmachine устарел?
Асинхронное программирование само по себе имеет узкую нишу и если этой технологии не находится применение в большинстве случаев, не означает, что он устарел. В это же время асинхронные http библиотеки могут спокойно использовать под капотом eventmachine и никто не кричит, что они устарели.
Асинхронное программирование само по себе имеет узкую нишу и если этой технологии не находится применение в большинстве случаев, не означает, что он устарел. В это же время асинхронные http библиотеки могут спокойно использовать под капотом eventmachine и никто не кричит, что они устарели.
Интересно, какую такую узкую нишу имеет асинхронное программирование. Любое взаимодействие с внешним миром — работа с сетью, чтение/запись на диск и т. д. гораздо проще выражается при использовании асинхронного кода, нежели мешаниной callback'ов. Зависит конечно от самого языка и от того, что конкретно разрабатывается.
Типичное веб приложение не генерирует десятки запросов в сеть или на диск в контексте пользовательского запроса. Если это интерактивная веб страничка (пусть даже очень нагруженный интернет магазин, блог или форум), там скорей всего не будет сетевых запросов во внешние сервисы или обращений в диск мимо БД. А бизнес логика как правило имеет синхронную природу. Асинхронность в node.js или golang даёт преимущество или при очень высоких нагрузках (много входящих запросов) или в специфичных случаях, когда само приложение генерирует много запросов\трафика.
*удалил* (неправильно понял ответ)
Точно, речь же идёт про веб-приложения, а я тут со своими десктопными понятиями :)
Далеко не всегда можно получить всю нужную инфу одним sql запросом, даже если не стесняться использовать джоины направо и налево. К примеру, это интернет магазин. Нужно и профиль юзера получить, и корзину его товаров, и категории товаров, и подробная информация об одном товаре, и список схожих товаров, и путь от главной страницы до определенного товара — категория, подкатегории, и тд.
Асинхронно это реализовывать на nodejs довольно бесяче (особенно раньше, на колбеках), но очень производительно — когда один запрос ожидает ответа от внешнего сервиса — бд, кеша или еще чего — другой исполняется.
Асинхронно это реализовывать на nodejs довольно бесяче (особенно раньше, на колбеках), но очень производительно — когда один запрос ожидает ответа от внешнего сервиса — бд, кеша или еще чего — другой исполняется.
Странно, почему рубисты не говорят о Crystal, который по сути Go, только с фундаментом Ruby.
Нишевой и пока еще сырой продукт. Хотя сам за ним слежу.
Во-первых, RoR тоже нишевый, а Go до сих пор местами очень сырой. Во-вторых, Crystal – язык общего назначения. В-третьих, чтобы новый язык развивался нужно о нем хотя бы говорить.
Если бы Crystal быстрее развивался, то легко бы потеснил Go. Но за Go стоят практически неограниченные ресурсы гугла и легионы разрабов на волне хайпа. У Crystal маленькая команда разработчиков и про него мало кто слышал :(
Я уже сам написал пару мелких проектов на Crystal, но инфраструктура слабая, shard'ов (внешних модулей) мало, комьюнити небольшое. Печально, конечно.
В моём личном сравнении Go vs Crystal последний по удобству выигрывает с отрывом. Именно за счёт рубевого синтаксиса.
Почему многие считают что Go используется на волне хайпа а не потому что это удобный и хороший язык?
UFO just landed and posted this here
Он был хорош лет 5 назад. Сейчас когда во многих языках есть и каналы и «зеленые» потоки Golang уже не выглядит так радужно. Так для справки — за эти годы операционные системы усовершенствовались и стали более эффективно работать с потоками + ядер у процессоров стало больше и на фоне этого «зеленые» потоки выглядят еще менее радужно.
Суть в том что язык хорош и без этих потоков каналов. Да считается основной фишкой. Но он приятный и строгий сам по себе. Так что говорить о языке только по самой его известной фишке это странно
Люди говорящие о технологии в рамках субъективных оценок (приятный, читаемый) вызывают у меня улыбку. Так, по моему у него омерзительный синтаксис и абсолютно нечитаемый код. По пробуйте мне доказать обратное. Это как с девушками — вот та вот мне не нравиться, и что бы вы не говорили она мне не будет нравиться, а вот внешность вот той нравиться. И чтобы бы вы не говорили это ничего не поменяет. Таково мое субъективное мнение поэтому Golang — уродливый, неприятный язык с ужасным синтаксисом, ни читаемым кодом и утиной типизацией через интерфейсы что уже делает его не строгим а значит не надежным.
Вообще никак не нишевой. Он одного класса с Go. Но что сырой, это да, нужно согласиться :(
Странно, почему ни кто не вспомнил про elixir :)
UFO just landed and posted this here
Все там будут, но сомневаюсь, что рубисты в данный момент смотрят на WASM, скорее на альтернативу для замены в недалекой перспективе.
UPD. Но вот языку, который начнет вытеснять других на WASMе, самое время начинать набирать силу.
UFO just landed and posted this here
CoffeeScript вымер потому, что это костыль над JS, который выкинули, когда es6 стал популярнее. А Crystal — это самодостаточная, независимая технология. Странно сравнивать Crystal и CS просто по «схожести» синтаксиса с Ruby.
Пример Coffescript может быть поучительным, т.к. это был Javascript со вкусом Ruby, но сейчас на нем пишут полтора человека.
Возможно, привкус Python не понравился)
А вообще, скорее из-за того, что появился Babel, а потом и сам JS (ES) стали активней развивать.
И почему это у Ruby дела не очень? Сам язык то продолжает так же развиваться. 3-я версия в активной разработке с существенными изменениями.
UFO just landed and posted this here
А на чём пишут остальные стартапы? Не на JS, случаем? Осмелюсь предположить, что некоторые отдают предпочтение Python. К тому же он уже наконец то переключился на 3.7. Ну и PHP вроде бодренько стал развиваться. И если речь о России, то это не удивительно, у нас довольно инертный рынок в этом плане. В остальном мире Ruby вполне успешно применяется.
А по поводу миграции — это вполне закономерное развитие проектов. Если они «выстреливают». Ruby не самый производительный, но он позволяет быстро писать.
А по поводу миграции — это вполне закономерное развитие проектов. Если они «выстреливают». Ruby не самый производительный, но он позволяет быстро писать.
Поэтому — githut 2
Если бы CoffeeScript выбирали исключительно из-за синтаксиса, то он и сейчас бы здравствовал. А его выбирали из-за возможностей: в JS тогда не было классов и даже стрелочных функций. Соответственно и умер он из-за того, что в JS появились сравнимые возможности.
А WASM здесь при том, что подавляющее большинство языков, которые не приспособятся к Web, ждет неизбежное забвение.
Я за ним слежу, и даже есть один проект в продакшене. Но по динамике развития, складывается ощущение, что там один Жозе его развивает (это видно по статискике github).
Хм, так вы посмотрите статистику за 2018-й год. На долю Жозе приходится примерно половина коммитов, но как минимум ещё 9 человек активно участвовали.
Но в целом, смотреть динамику развития Elixir по компилятору не очень правильно. Основное развитие идёт в тулинге и в сопутствующих библиотеках. Например, из свеженького Phoenix LiveView
Говорим с коллегами о нем уже 8 лет, но дальше разговоров дело не идет. Экзотика-с…
Мне вот больше интересно почему рубисты не говорят о Python.
Например, Максимом Индыковым из Staply, чья команда переезжает с Ruby на Go
Это чтобы через ~5 лет снова переехать на новый хайповый язык?
Если он будет еще лучше, то почему нет? Хайп здесь не при чем, у руби не осталось преимуществ, чтобы на нем оставаться.
Одно точно осталось — синтаксис (среди однотипных).
Кому как. Никогда не считал руби читабельным и, судя по всему, я не один такой. У Go синтаксис тоже является одним и преимуществ. Кому-то важнее его читабельность, а не какая-то субъективная красота кода.
Чем синтаксис Go отличается от С-подобных? У Ruby, например, возможность писать вызовы функций без пустых скобок значительно облегчает читабельность (меньше лишних символов). Хотя, некоторые этим злоупотребляют и этим только ухудшают читабельность. В нём минимум служебных слов (типа var, const, return). Возможность написания своего DSL (отличный пример — RSpec, который в другие языки даже стали копировать, или Chef).
Тем, что его спецификацию можно прочитать и осмыслить за час другой, а потом читать код, в котором не будет неоднозначных конструкций практически. Без подсветки, без IDE, без всего, можно читать код и понимать, что и куда. Когда пишешь код, у тебя нет вариантов злоупотребления чем-то, выбора из тучи разных вариантов написания одного и того же — ты пишешь один раз и всегда одинаково, потому что по-другому и невозможно. Свобода выбора и ломать голову какой же сегодня выбрать способ инициализации переменной из десятка возможных — это не про Go.
Символы без скобок — внизу пример есть, как это читается. Меньше не значит лучше. Go многословен, чтобы он читался всегда однозначно вне зависимости от контекста. Вы там конечно написали, что не имеет значения, но это величайшая глупость. Я должен знать, что это, потому что от этого зависит, кончится ли выполнение функции на этом или за этим одним идентификатором находится еще цепочка функций. Это объективный критерий читабельности и у Ruby с ним проблемы очевидно, раз он позволяет так писать.
Символы без скобок — внизу пример есть, как это читается. Меньше не значит лучше. Go многословен, чтобы он читался всегда однозначно вне зависимости от контекста. Вы там конечно написали, что не имеет значения, но это величайшая глупость. Я должен знать, что это, потому что от этого зависит, кончится ли выполнение функции на этом или за этим одним идентификатором находится еще цепочка функций. Это объективный критерий читабельности и у Ruby с ним проблемы очевидно, раз он позволяет так писать.
От части согласен. Но Ruby опасен для малоопытных разработчиков, он позволяет написать очень жуткий и сложный код. Если код нормально написан, то проблем с этим не возникает. Если это переменная, то к концу функции точно встретится её объявление.
Go не полагается на опыт разработчиков, на их настроение, фантазию, честность, порядочность и т.д. Пишишешь или так, или никак. Из него намеренно вырезано как можно больше неортогональных дублирующих фич. Это конечно весело в плюсах каких-нить полдня потратить на раздумья, как и что написать, но, в конечном итоге, пользы от этого мало. Go позволяет просто писать и забыть о языке, синтаксисе, форматировании кода и многом другом. И это прекрасное ощущение, чем он видимо и заслужил строчку в топе самых любимых технологий из года в год, находясь заметно выше руби, который еще и в топе самых ненавистных находится.
Это все конечно здорово, вот только этот самый Go не спрашивает меня, нужно ли это мне. И возникают потом вот такие перлы:
stackoverflow.com/questions/21743841/how-to-avoid-annoying-error-declared-and-not-used
Дебаг становится болью и страданием. Часть кода и импортируемых либ вечно закомменчена, потому что компилятор много на себя берет. Ходи вечно туда-сюда, то закомментируй, то раскомментируй кусок. Потом обязательно что-то забываешь раскомментить, из-за этого упадет в другом месте, и так далее.
А ведь решение простое — пусть компилятор компилирует, а линтер проверяет на все эти неиспользуемые переменные. По отдельности. Или флаг какой-нибудь ввести, чтобы управлять поведением компилятора. Но нет, разработчики языка же самые умные, давайте мол, заставим всех писать так, а не иначе.
На самом деле хороший язык в своей области, и писать на нем в целом приятно, но вот от этого момента у меня конкретно пригорает. Сколько лет прошло, а до сих пор не изменили это поведение.
stackoverflow.com/questions/21743841/how-to-avoid-annoying-error-declared-and-not-used
Дебаг становится болью и страданием. Часть кода и импортируемых либ вечно закомменчена, потому что компилятор много на себя берет. Ходи вечно туда-сюда, то закомментируй, то раскомментируй кусок. Потом обязательно что-то забываешь раскомментить, из-за этого упадет в другом месте, и так далее.
А ведь решение простое — пусть компилятор компилирует, а линтер проверяет на все эти неиспользуемые переменные. По отдельности. Или флаг какой-нибудь ввести, чтобы управлять поведением компилятора. Но нет, разработчики языка же самые умные, давайте мол, заставим всех писать так, а не иначе.
На самом деле хороший язык в своей области, и писать на нем в целом приятно, но вот от этого момента у меня конкретно пригорает. Сколько лет прошло, а до сих пор не изменили это поведение.
Что значит не осталось преимуществ? Они исчезли, их украли? Просто это так странно по стороны смотрится — появляется очередная хайповая «прорывная» технология или язык, все на него пересаживаются и буквально носят на руках. А потом вдруг «ой, не осталось преимуществ». А в то же время другие товарищи как писали на java/.net/php так и пишут.
А другие переписывают частично или полностью на другие языки, потому что они лучше для этого подходят. Go получил популярность не из-за гугла, который никаким вообще местом не стоит за эти языком, а за счет популярности среди крупных разработчиков, которые доверили свой бизнес новой технологии. Целые стеки технологий, на которых сейчас что только не крутится, на нем написаны. Таже контейнерная революция, это целиком и полностью Go нынче.
Да, преимущества исчезают внезапно, потому что все относительно. Пока нет лучшей альтеранативы, что-то будет преимуществом.
Да, преимущества исчезают внезапно, потому что все относительно. Пока нет лучшей альтеранативы, что-то будет преимуществом.
Шел 10й год хайпа golang. Хайповали Avito, Ozone, Alibaba, Mail.ru…
Хайп давно прошел. Давно идут дни спокойной и уверенной разработки.
10 лет назад никакого хайпа вокруг Go не было. Кто-то на нем писал, безусловно, но именно хайп начался года 2-3 назад, когда все вдруг резко начали на него переходить.
А хайп этот появился, потому что кто-то переписал, увидел профит, и пошло поехало лавинообразно. Хайп не хайп, а Go вытеснил других, потому что лучше.
В своей ниже для своих задач. Полностью согласен.
А кого он вытеснил, собственно?
Любого, кто плохо подходил в конкретной нише в конкретном проекте. php, python, ruby, java, node.js — что только не переносили на него. Так он и набрал свою популярность. У людей были существующие системы, которые их чем-то не устраивали или даже устраивали, но было любопытно поиграться с новой штукой. Они переписывали ее части на Go и получали те или иные преимущества. Обычно это простота и скорость. Если это хайп, то это правильный вид хайпа, который позволил другим узнать об отличной технологии.
в конкретном проекте
Я бы уточнил — в конкретном этапе проекта. Или нынче все стартапы начинают сразу писать на Go?
Зависит от ниши, но да, стартовать на Go уже просто, поскольку библиотек стало много. Несколько лет назад писать прототип сразу на Го было тяжко. Я бы сказал, что есть некоторые проблемы а той нише, где рельсы и джанго, но и это вопрос времени. Синтаксис конечно после руби будет убог, но зато появится многопоточность и упростится поставка. Тут уж надо определяться.
Любопытнее было бы противопоставить, elexir и go.
Я не могу говорить за все стартапы, но на Go очень просто и быстро пишется, не знаю откуда этот миф взялся. Может быть на версии 1.0 на нем и было сложно писать, но сейчас библиотек море. А сам язык только помогает сделать что-то быстро и просто с первого раза.
Чтобы эти библиотеки подключить надо разобраться с 100500 тулзов для их управления, папочки правильные в правильных местах создать и переменные окружения объявить =)
Вот тут про тулы для управления зависимостями
Так что про простоту работы с Go, всё хитрее чем кажется на самом деле. И сам язык не обладая достаточными абстракциями склоняет к написанию громадных простыней кода и жутких генераторов простыней кода.
У Go много преимуществ, но не перед Ruby — точно (кроме производительности, но чтобы это заметить надо с ооочень большими и сложными проектами работать). Это вообще из разных ниш и для разных задач языки.
Вот тут про тулы для управления зависимостями
Так что про простоту работы с Go, всё хитрее чем кажется на самом деле. И сам язык не обладая достаточными абстракциями склоняет к написанию громадных простыней кода и жутких генераторов простыней кода.
У Go много преимуществ, но не перед Ruby — точно (кроме производительности, но чтобы это заметить надо с ооочень большими и сложными проектами работать). Это вообще из разных ниш и для разных задач языки.
Вы бы сначала разобрались в вопросе. Управление зависимостями и организация проектов в Go одна из самых простых и прозрачных, которые я когда-либо видел.
Меня почему-то не склоняет. Склоняет обычно он тех, кто пришел из других языков и пытается писать на Go как на них.
Почему-то с него разработчики стабильно перебираются на Go. А ниши у них общие, это языки для бэкэнда в его самых разных проявлениях.
И сам язык не обладая достаточными абстракциями склоняет к написанию громадных простыней кода и жутких генераторов простыней кода.
Меня почему-то не склоняет. Склоняет обычно он тех, кто пришел из других языков и пытается писать на Go как на них.
У Go много преимуществ, но не перед Ruby — точно
Почему-то с него разработчики стабильно перебираются на Go. А ниши у них общие, это языки для бэкэнда в его самых разных проявлениях.
Склоняет обычно он тех, кто пришел из других языков и пытается писать на Go как на них.
По-моему, природа неприязни к Ruby аналогична)
Почему-то с него разработчики стабильно перебираются на Go. А ниши у них общие, это языки для бэкэнда в его самых разных проявлениях.
На Go перебираются прежде всего из-за его производительности и неприхотливости к ресурсам. Сомневаюсь, что удобство разработки является причиной. И ниши я бы всё же немного разделил. Ruby прямой конкурент Python. Они не исключительно для бэкенда, это языки общего назначения. На Go можно написать однофайловый скриптик и просто запустить?
Ruby прямой конкурент Python.Совершенно не конкуренты. Питон — это МЛ и анализ данных. Руби — это бекенд веб сервисов.
На Go можно написать однофайловый скриптик и просто запустить?Да.
Совершенно не конкуренты. Питон — это МЛ и анализ данных. Руби — это бекенд веб сервисов.
Ну это смотря с какой колокольни смотреть. Что если так?
github.com/arbox/machine-learning-with-ruby
github.com/vinta/awesome-python#web-frameworks
Chef, Capistrano, Phusion Passenger, Mina, Puppet, Vagrant это разве бекенд веб сервисов?
Хммм, а разве Go интерпретируемый?
github.com/arbox/machine-learning-with-ruby — ну это, конечно, по сравнению с тем, что есть в Python, баловство.
Ну это смотря с какой колокольни смотреть. Что если так?Да как бы можно и на си писать веб-приложение, что не делает его конкурентом php :)
Факт в том, что среди языков общего назначения никто не может переплюнуть python в области анализа данных. Да, в руби есть несколько либ для этого, но это совершенно не то. Питон — это готовая инфраструктура, тогда как руби — несколько кубиков.
Но если говорить о написании веб-приложения безо всяких вычислений и нейронных сетей, руби не переплюнет пока никто по скорости разработки. Да, в питоне есть и фласк, и джанго, и sqlalchemy, и другие хорошие либы, но с руби не сравнится.
Хммм, а разве Go интерпретируемый?Нет, но вопрос ведь был не об этом. «На Go можно написать однофайловый скриптик и просто запустить?» На go можно написать код, сохранить его в файле main.go, а потом просто запустить его через go run main.go
Тогда уж 3-4 года назад, как минимум. Когда Лазада развернулась и создала с сотню рабочих мест для гошников.
Трудно такой долгий срок растущей популярности оправдывать только хайпом.
Согласен, особенно позабавила эта фраза — «Крупные компании во всю объявляют об использовании Go.»
Для Go до сих пор нет нормального инструментария для удобной разработки(не учитывая GoLang от JetBrains)
Для Go до сих пор нет нормального инструментария для удобной разработки(не учитывая GoLang от JetBrains)
А что не так с позабавившей фразой?
Слишком голословное заявление
«Крупные компании» — слишком расплывчатое и индивидуальное понятие, для меня крупные компании это Microsoft, Oracle, Samsung и я что то не слышал что бы они продвигали Go. Только Google более менее в эту сторону смотрит.
Мне кажется как то так.
«Крупные компании» — слишком расплывчатое и индивидуальное понятие, для меня крупные компании это Microsoft, Oracle, Samsung и я что то не слышал что бы они продвигали Go. Только Google более менее в эту сторону смотрит.
Мне кажется как то так.
Еще раз давайте попробуем, Alibaba, Avito, Ozine, Booking.com, Mail.ru — пойдет, как большие компании?
Еще раз давайте попробуем — «слишком расплывчатое и индивидуальное понятие»,
эта часть фразы понята?
Из перечисленных компаний на мой взгляд крупные Alibaba, Mail.ru, Ozone.
Про остальные я не слышал и не в курсе, насколько они «крупные».
эта часть фразы понята?
Из перечисленных компаний на мой взгляд крупные Alibaba, Mail.ru, Ozone.
Про остальные я не слышал и не в курсе, насколько они «крупные».
Booking.com и avito — крупные. Посмотрите.
Но в любом случае, что-то новое открылось: крупные компании используют golang.
Кстати, Google.
Google да, тут понятно почему, а вот крупнейшие игроки на рынке ИТ, такие как Apple, Microsoft, Samsung, Amazon, Oracle его не продвигают и не «бегут» за этим языком.
И я не совсем понимаю что вы подразумеваете под словом «крупные», вы про количество сотрудников или про суммарную площадь офисов?
И да, среди российских компаний довольно много ИТ компаний которые продвигают Go, пишут что то для себя.
И я не совсем понимаю что вы подразумеваете под словом «крупные», вы про количество сотрудников или про суммарную площадь офисов?
И да, среди российских компаний довольно много ИТ компаний которые продвигают Go, пишут что то для себя.
Во-первых, для Go не требуется обязательно IDE и это одно из его фич. Во-вторых, давно есть vscode. Ничего более не требуется.
А почему собственно не учитывать продукцию JetBrains?
Как раз пытаюсь по знакомым знакомых найти фул стак веб разработчика с готовностью работать над проектом на ruby on rails. Сложно. Все в один голос говорят, что раньше это было хайпово — баловались, а сейчас сошло на нет.
Хоть бери и сам изучай его. Но как человек вне веб разработки, боюсь что буду лепить сложные велосипеды, и на это уйдет нерациальное количество времени.
Если есть желающие работать над долгосрочным проектом, просьба отписать в личку.
Хоть бери и сам изучай его. Но как человек вне веб разработки, боюсь что буду лепить сложные велосипеды, и на это уйдет нерациальное количество времени.
Если есть желающие работать над долгосрочным проектом, просьба отписать в личку.
UFO just landed and posted this here
UFO just landed and posted this here
Cмотря что за многоточием скрывается.
Но на практике, во время реальной разработки, вы, скорее всего, пользуетесь каким угодно редактором с подсветкой синтаксиса. И вот эта самая подсветка обычно работает отлично, решая запрашиваемую проблему тем, что по умолчанию красит вызов функции и вывод содержимого переменной в разные цвета.
Могли бы вы привести пару-тройку примеров?
Но на практике, во время реальной разработки, вы, скорее всего, пользуетесь каким угодно редактором с подсветкой синтаксиса. И вот эта самая подсветка обычно работает отлично, решая запрашиваемую проблему тем, что по умолчанию красит вызов функции и вывод содержимого переменной в разные цвета.
Спойлер
А ещё, скорее всего, функции с таким однобуквенным названием вам не встретится.
А best practices (rubocop) еще и усугубляет дело вместо того, чтобы исправлять.
Могли бы вы привести пару-тройку примеров?
UFO just landed and posted this here
- Если бы style check всегда настаивал на том, что вызов функции должен быть со скобочками ( a() )
Это вы привыкли к идее, что функция — это со скобочками. Почитайте про Smalltalk — от него Ruby очень многое почерпнул, станет понятнее, почему можно без скобок жить.
Чтобы понять, что у функции есть значимое возвращаемое значение
В большинстве случаев возращаемое значение в руби значимо, из этого и стоит исходить.
А что вам мешает настроить rubocop под ваши правила?
С первыми двумя пунктами можно почти согласиться, но и тут легко найти объяснения:
- Если "а" — это локальная переменная, то это будет подсвечено редактором. И дополнительная фича — если вы перенесете вычисление этой переменной в функцию, то не нужно будет её переименовывать.
- Можно и должно выделяться пустой строкой перед возвращаемым результатом. И лучше придерживаться, что любая функция возвращает осмысленное значение (на то она и функция).
- А тут ruby-way, ООП и основная фишка ruby. В случае с a.positive — переменная "а" — может быть чем угодно, например специфичным value-object, а не только числовым значением.
За многоточием скрывается дофига строчек кода
Жаль, хорошо было бы по возможность разбить на несколько методов. И тогда контекст из, например, 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 плохи.
Что здесь a? Вызов функции a(), или ранее объявленная переменная 'a'?
А не всё ли равно? Что от этого зависит?
UFO just landed and posted this here
вряд ли человек, который пишет читаемый код, назовет функцию, или переменную «a».
UFO just landed and posted this here
Методы — глаголы.
Переменные — существительные.
Для того, чтобы их отличать, достаточно правильного именования.
Переменные — существительные.
Для того, чтобы их отличать, достаточно правильного именования.
Все бы хорошо, да вот английский язык очень любит одно и то же слово делать и глаголом, и существительным. Ну вот step например :) Разумеется, в каждом конкретном контексте можно обыгрывать сущность/действие по-разному, просто хотел отметить, что правильное именование — довольно-таки непростая задача.
Не понимаю, как может влиять на читаемость переменная это или функция? Важно ведь возвращаемое значение. А читаемость больше зависит от именования сущностей и структуры кода.
Ну вот, заминусовали человека не_рубисты.
Когда начинаешь этим пользоваться, понимаешь, насколько это удобно — когда «a» может быть хоть переменной, хоть функцией, и тебе на это плевать.
Например, определенный контроллер обрабатывает апи-запрос на создание пользователя. В теле этого контроллера будет строка, что-то вроде:
create_params на самом деле функция, описанная где-нибудь выше, но в этом случае используется как переменная. И это намного более читаемо, чем что-то вроде такого:
Зачем тут акцентировать скобками вызов функции? Какую пользу это принесет, кроме «в пхп/жс/питоне я привык, чтоб было так»?
А вот польза «без скобок» вполне очевидная — поведение не зависит от реализации. В других языках вызвать переменную как функцию — ошибка, вызвать функцию как переменную — ошибка. Изменил потом переменную на функцию или наоборот — и ходи потом во все места, где оно используется, исправляй.
Когда начинаешь этим пользоваться, понимаешь, насколько это удобно — когда «a» может быть хоть переменной, хоть функцией, и тебе на это плевать.
Например, определенный контроллер обрабатывает апи-запрос на создание пользователя. В теле этого контроллера будет строка, что-то вроде:
@user = User.create(create_params)create_params на самом деле функция, описанная где-нибудь выше, но в этом случае используется как переменная. И это намного более читаемо, чем что-то вроде такого:
@user = User.create(create_params())Зачем тут акцентировать скобками вызов функции? Какую пользу это принесет, кроме «в пхп/жс/питоне я привык, чтоб было так»?
А вот польза «без скобок» вполне очевидная — поведение не зависит от реализации. В других языках вызвать переменную как функцию — ошибка, вызвать функцию как переменную — ошибка. Изменил потом переменную на функцию или наоборот — и ходи потом во все места, где оно используется, исправляй.
Изменил потом переменную на функцию или наоборот — и ходи потом во все места, где оно используется, исправляй.
Вот поэтому, видимо, скорость разработки на Ruby выше) Он позволяет сосредотачиваться на сути (предметной области), а не на реализации.
Возможно потому же gitlab требует 4Gb оперативки и 2 ядра для 1 пользователя а gogs уживается на 1 ядре и 256Mb для 10.
Так высокую прожорливость Ruby никто не отрицает. Но разве это следствие синтаксиса?
Проблема в языках не только и не столько в синтаксисе, но и в окружении — платформа, реализация. Язык может выглядеть идеально, но потреблять для своей работы огромные ресурсы и кому он будет нужен?
Некоторые особенности, конечно, оказывают влияние, но они же позволяют сокращать время разработки и добавляют гибкости и универсальности.
И в этом направлении работы активно ведутся — повышается скорость, улучшается сборщик мусора и т.д. Да и в плане окружения, сейчас всё больше встречается хостингов с поддержкой Ruby. PHP и Python тоже не всегда были быстрыми неприхотливыми.
И в этом направлении работы активно ведутся — повышается скорость, улучшается сборщик мусора и т.д. Да и в плане окружения, сейчас всё больше встречается хостингов с поддержкой Ruby. PHP и Python тоже не всегда были быстрыми неприхотливыми.
Мы вот как-то пробовали поуэршелл скрипты. Работало, в целом, хорошо, но он отъедал 99% ресурсов памяти и процессора. И, в конце концов, вывешивал сервер намертво. Я, понимаю, удобно когда компьютер делает работу за программиста, но не такой же ценой? Переписали то же самое на Delphi, 1% времени + 20-30% занимаемой памяти. Что тут еще сказать?
.Net со сборкой мусора виноват был, если что.
.Net со сборкой мусора виноват был, если что.
Я как не рубист, хочу сказать что вижу тут две принципиально разных вещи. Передачу функции в одном случае, и передачу результатов выполнения функции в другом.
И это вовсе не добавляет понимания коду
И это вовсе не добавляет понимания коду
Именно. Если не знать руби, то так оно и выглядит.
В каком-нибудь javascript'e
Но в руби
Это удобно когда знаешь, и непривычно, когда не знаешь. Но оценка с точки зрения непривычности — не самая адекватная. Я, к примеру, совершенно не разбираюсь в c++. И, когда читаю исходник какого-либо интересного мне репозитория, чтобы разобраться в алгоритме, для меня код просто дико нечитаемый, приходится продираться сквозь него. Но это не значит, что синтаксис языка плох.
В каком-нибудь 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)
Это удобно когда знаешь, и непривычно, когда не знаешь. Но оценка с точки зрения непривычности — не самая адекватная. Я, к примеру, совершенно не разбираюсь в c++. И, когда читаю исходник какого-либо интересного мне репозитория, чтобы разобраться в алгоритме, для меня код просто дико нечитаемый, приходится продираться сквозь него. Но это не значит, что синтаксис языка плох.
Ну вот тут я не соглашусь. Хороший язык должен вызывать как можно меньше WTF. Почти все современные языки имеют функции первого класса. Не только js, но python, golnang, kotlin, c#, perl, php… Даже С. Не говорю уж о функциональных языках.
А тут ради сомнительно экономии двух скобок приходится извращаться с Proc. Я понимаю что выразительность языка была поставлена во главу его дизайна. Но тут они зашли слишком далеко, на мой взгляд.
С учетом современных тенденций использования функциональных подходов, то это еще одна причина потери популярности.
А тут ради сомнительно экономии двух скобок приходится извращаться с Proc. Я понимаю что выразительность языка была поставлена во главу его дизайна. Но тут они зашли слишком далеко, на мой взгляд.
С учетом современных тенденций использования функциональных подходов, то это еще одна причина потери популярности.
«А тут ради сомнительно экономии двух скобок приходится извращаться с Proc. Я понимаю что выразительность языка была поставлена во главу его дизайна. Но тут они зашли слишком далеко, на мой взгляд.
С учетом современных тенденций использования функциональных подходов, то это еще одна причина потери популярности.»
Вы хотите сказать что Haskell менее функциональный язык чем другие тоже из-за того что в нём скобки необязательны? =)
С учетом современных тенденций использования функциональных подходов, то это еще одна причина потери популярности.»
Вы хотите сказать что Haskell менее функциональный язык чем другие тоже из-за того что в нём скобки необязательны? =)
Вот пример из очень трендового и популярного JS:
Не смотря в доку, попробуйте угадать какой результат и почему?
Вроде бы и скобочки на месте стоят, а логики никакой…
P.S. А по поводу того что Руби в чём-то на другие языки не похож, это нормально, как ещё новые языки будут появляться, если они должны быть похожи на Си, например?
Math.max() > Math.min()Не смотря в доку, попробуйте угадать какой результат и почему?
Вроде бы и скобочки на месте стоят, а логики никакой…
P.S. А по поводу того что Руби в чём-то на другие языки не похож, это нормально, как ещё новые языки будут появляться, если они должны быть похожи на Си, например?
Еще из пхп можно примеры привести, у js много такого что его не красит ни разу.
Но, на всякий случай напомню что эта ветка про читаемость руби.
Но, на всякий случай напомню что эта ветка про читаемость руби.
Я хотел сказать что дело не в скобочках. Мало того, именно у меня, при разработке на Ruby ни разу в жизни не было дискомфорта из-за отсутствия/присутствия скобочек. Кода на нём получается очень мало (!), читается он всегда слева направо из-за умного, по японски аккуратного, уклона в ООП (мало какие языки могут этим похвастаться). И необязательность скобок позволяет легко заменять свойства объектов на методы без лишнего копипастинга, чем очень сильно упрощает рефакторинг.
И сценария где сложно разбираться в коде из-за того что вместо переменной выполняется какой-то метод объекта я даже представить не смог, буду благодарен за пример.
И сценария где сложно разбираться в коде из-за того что вместо переменной выполняется какой-то метод объекта я даже представить не смог, буду благодарен за пример.
UFO just landed and posted this here
А в чём принципиальная разница?
Если это переменная — найти её элементарно, ибо она объявлена строго внутри этой функции (в руби строго с областью видимости переменных).
Если это метод он по неймспейсу ищется очень быстро, а если есть удобная возможность исполнять код (в тестах, например) там #source_location есть и другие замечательные плюшки.
Если это переменная — найти её элементарно, ибо она объявлена строго внутри этой функции (в руби строго с областью видимости переменных).
Если это метод он по неймспейсу ищется очень быстро, а если есть удобная возможность исполнять код (в тестах, например) там #source_location есть и другие замечательные плюшки.
Руби имеет большую популярность в Японии и Китае. И синтаксис у него японский — многие конструкции читать надо справа налево как иероглифы сверху вниз. Там в Азии пусть и развивается.
В Японии пишут или столбцово справого столбца к левому читая вниз. Или Слева на право как и у нас. Так что это вообще ни о чем аргумент. На счет Китайского не скажу
Ну программисты в Японии конечно есть очень задротистые интересные. Например, Yusuke Endoh, который написал знаменитую quine-relay — цепной квайн на 100 языках программирования. Он, кстати, рубист.
Можете привести пример где такой код?
Как раз в руби код читается сверху вниз и далее слева направо в большинстве случаев и надо очень сильно не в стиле руби писать чтобы было как вы говорите.
Вот в других языках легко примеры привести:
— например, «генераторы» в Python, Erlang, Elixir, Haskell, они вообще читаются от центра и во все стороны =)
— В JS, C++, Go и.т.п. есть постфиксный "++"
— В Clojure вообще можно пайпить во все стороны
Как раз в руби код читается сверху вниз и далее слева направо в большинстве случаев и надо очень сильно не в стиле руби писать чтобы было как вы говорите.
Вот в других языках легко примеры привести:
— например, «генераторы» в Python, Erlang, Elixir, Haskell, они вообще читаются от центра и во все стороны =)
— В JS, C++, Go и.т.п. есть постфиксный "++"
— В Clojure вообще можно пайпить во все стороны
UFO just landed and posted this here
Ну смотрите, множество итерируемых элементов по центру.
Условие фильтрации справа.
То есть чтобы понять над чем мы вообще проводим операцию, то смотрим в центр, потом направо, в конце налево. А генераторы могут быть сложнее + использоваться как выражение. Теперь пример этого же на Руби:
с магией(типа для команды опытных товарищей)
без магии
Читается в правильном порядке слева направо. Ничего не надо промежуточного запоминать, всё логично.
Условие фильтрации справа.
То есть чтобы понять над чем мы вообще проводим операцию, то смотрим в центр, потом направо, в конце налево. А генераторы могут быть сложнее + использоваться как выражение. Теперь пример этого же на Руби:
с магией(типа для команды опытных товарищей)
values.select(&:even?).map { |i| i * i }без магии
values.select { |i| i.even? }.map { |i| i * i }Читается в правильном порядке слева направо. Ничего не надо промежуточного запоминать, всё логично.
Я бы сказал, что у руби сейчас некий период застоя. Плюсы языка никуда не делись, а хайп ушёл к Go и прочим. На нём всё ещё приятно писать и его также приятно читать.
А ещё мнения Павла очень сильно портят всю статью.
А ещё мнения Павла очень сильно портят всю статью.
Какой хайп, не подскажите? Уже сколько лет язык и сколько на нем написано а все хайп идет, все сидят и хайпуют наверное, страдают и хайпуют, верно?
Почему язык не может быть популярным из-за того что он удобный?
Почему язык не может быть популярным из-за того что он удобный?
Каждый популярный язык в своё время считался или считается удобным. Зачастую языки создают, чтобы решить какие-то очень часто возникающие проблемы, ну или чтобы заполнить нишу. Из этого вполне закономерно следует, что такой язык удобен для своего круга задач.
8-10 лет назад такой же вопрос бы задали о руби, через 10 зададут ещё о каком-то языке.
8-10 лет назад такой же вопрос бы задали о руби, через 10 зададут ещё о каком-то языке.
Лет 7 назад пришлось некоторое время работать над расширением некоей довольно приличного размера системы, написанной на Руби. Сам я занимался в основном «клаудификацией» и другими архитектурно/инфраструктурными вопросами — а программисты этот язык тихо ненавидели.
Основной причиной был трудночитаемый код, что в сочетании с приличной разницей в часовых поясах между частями команды приводило к постоянным проблемам с интеграцией изменений, сделанных разными людьми.
Еще одной проблемой (ни до того, ни после мной не встреченной) была зацикленность немногочисленных «гуру» на «Ruby-way» и DRY — что сильно сказывалось на code review, особенно если учесть что у каждого из гуру этот самый «way» был какой-то свой, особенный.
Ну и последнее — низкая производительность. На машинах, где Руби еле шевелился — потом система, переписанная на Java просто летала.
Основной причиной был трудночитаемый код, что в сочетании с приличной разницей в часовых поясах между частями команды приводило к постоянным проблемам с интеграцией изменений, сделанных разными людьми.
Еще одной проблемой (ни до того, ни после мной не встреченной) была зацикленность немногочисленных «гуру» на «Ruby-way» и DRY — что сильно сказывалось на code review, особенно если учесть что у каждого из гуру этот самый «way» был какой-то свой, особенный.
Ну и последнее — низкая производительность. На машинах, где Руби еле шевелился — потом система, переписанная на Java просто летала.
UFO just landed and posted this here
Я видел много любителей сложного кода, но имхо они такое наделают на другом языке. Особенно нельзя таких подпускать к C++.
Мне ruby то как раз нравится тем что на нем можно писать для людей
Мне ruby то как раз нравится тем что на нем можно писать для людей
В сообществе Руби у этого есть целых две грани. С одной стороны — люди бьются за DRY доводя это до абсурда. С другой — какой-нибудь залетный миксин может сломать работающую и оттестированную систему (этим, кстати, начинает страдать и Python с развитием всяких хитрых фреймворков).
Питон страдает зоопарковостью, среди прочего. Куча веток всего, часто несовместимых. Нужно что-то сделать? Будь готов тянуть и ставить множество зависимостей. Другой код открыл? Он уже не работает с теми зависимостями, что первый. И не так просто это разрулить.
Старая уже статья:
habr.com/post/206024
Старая уже статья:
habr.com/post/206024
Очень много говорят о переезде существующих проектов с руби на whatever. Если разработчик говорит что меняет веру — то чаще всего слышу что на elixir. Интересно было бы услышать мнение команд, которые решили делать новый проект не на рельсах, а на том же Go.
По личному опыту знаю, что накидать небольшую приложуху или прототип на рельсах — крайне удобно. Да даже большой проект стартовать и позднее — поддерживать — очень приятно (в плане удобства ЯП и фреймворка). Некоторые части со временем требуют оптимизации, это да. А вот чтобы сходу на Go и достаточно большое приложение — это вообще возможно?
Это судя по всему проблема всех всё-в-одном фреймворков, вне зависимости от языка.
В какой-то момент твой прототип выростает в большое приложение и ты понимаешь, что ты завязан на этом фреймворке, а он тянет ресурсы.
В какой-то момент твой прототип выростает в большое приложение и ты понимаешь, что ты завязан на этом фреймворке, а он тянет ресурсы.
Я как-то недавно присутствовал на совещании с потенциальными технологическими партнерами. И зашел у нас разговор по поводу тсогласования API наших сервисов.
— Нам в вашем API будет нехватать фичи X.
— Да, надо сделать, но это нужно выносить в отдельный сервис ибо под такое у нас сейчас нет ничего. Когда у нас там сроки?
— Три месяца.
— Блин, будем на Ruby тогда писать.
— А обычно на чем?
— Обычно на Go ибо производительнее, но за три месяца не успеем — разработка на Go дороже по человека часам. А потом перепишем, если выстрелит бизнес.
Вот примерно такая у ребят мотивация. Мы тоже пишем на Go, но с Python. Обычно на Go пишем нечто долгоживущее в памяти и быстрое.
Я разрабатывал на 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 и статичных сайтов», но хайп уже просто в другом месте.
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 и статичных сайтов», но хайп уже просто в другом месте.
Эх, вот бы gitlab на go переписали, а то почти все ресурсы моего мини сервера скушал…
Я наверное один извращенец, который любит js и готов на нем писать все и вся...
Руби пробовал по работе, с каким-то аддовым шаблононизатором, шаг влево или вправо и проект не стартует, как у меня горело бордовым пламенем, на разработчиков, которые придумали использовать этот гем.
С тех пор я руби даже не воспринимаю в серьез, вот так поделка написанная, кем-то может убить желание использовать язык.
Интересно, но ни в статье, ни в комментах никто не вспоминает .net
Да, интересно. У меня вот сложилось ощущение, что со стороны .net выглядит гораздо хуже, чем он есть. Как человек с довольно широким стеком, порой недоумеваю, почему его недолюбливают.
Эффект ореола.
Микрософт плохой, следовательно, .net тоже.
Да и .net Windows-only. Вот .net core — уже привлекает внимание и потихоньку начинает воспринимается всерьез.
Микрософт плохой, следовательно, .net тоже.
Да и .net Windows-only. Вот .net core — уже привлекает внимание и потихоньку начинает воспринимается всерьез.
UFO just landed and posted this here
Кстати да. И это при том, что объемы разработки на .NET/Core на порядок превышают Ruby и тем более Go. Однако, у некоторых «все» переходят с Ruby на Go. Видимо, пребывание в пузыре — неизбежная болезнь любого разработчика.
Все равно все окажитесь в js, так что нода, и нечего тут думать.
Delphi, видимо, еще один язык пережил :) Мы как писали 15+ лет на нем так и продолжаем. Он до сих пор востребован и актуален. Это ли не успех языка?
У нас последний продукт на дельфях остался, старый монстр, но, думаю, тоже будет переписан
Куда переписываете и в чем причина?
Был монструозный десктоп, будем перетаскивать бэк на сервисы (.net core), и сделаем клиента под web. Причина — на дельфи осталось пара старых разрабов, но никто из потенциальных новичков не желает с ними работать, то есть команду практически нельзя расширить, плюс знания о проекте в данный момент полностью сосредоточены и замкнуты на паре человек. Поддерживать такой продукт опасно и неудобно.
del
UFO just landed and posted this here
В руби как и в php присутствует неконсистетность в названиях функций/методов стандатрной библиотеки, что порой расстраивает.
Вы бы пример привели хотя бы этой неконсистентности и языка, который более консистентен.
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
С неймингом все ок
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
С неймингом все ок
Полагаю, cp это для тех, кому привычно линуксовое название. Но у него есть псевдоним copy (для читабельности). Ну а под капотом действительно C.
Ну вот, видимо пожертвовали консистентностью в угоду привычности.
Непонимаю за что минус
Непонимаю за что минус
В мире дотнета конечно тоже есть прямые биндинги
github.com/mono/mono/blob/master/mcs/class/Mono.Posix/Mono.Unix.Native/Syscall.cs#L4577
Такие названия и интерфейсы связаны больше с миром Unix-подобных систем и там они отторжения не вызывают (то есть в других языках и технологиях на этих системах похожие интерфейсы)
Пример что вы привели действительно представляет из себя либу с некрасивыми интерфейсами, но это исключение, а не правило для мира Ruby.
github.com/mono/mono/blob/master/mcs/class/Mono.Posix/Mono.Unix.Native/Syscall.cs#L4577
Такие названия и интерфейсы связаны больше с миром Unix-подобных систем и там они отторжения не вызывают (то есть в других языках и технологиях на этих системах похожие интерфейсы)
Пример что вы привели действительно представляет из себя либу с некрасивыми интерфейсами, но это исключение, а не правило для мира Ruby.
The Top Programming Languages 2018. (из анализа выборки в 300 языков)
spectrum.ieee.org/static/interactive-the-top-programming-languages-2018
P.S. Ryby на 13-м месте в этом рейтинге.
spectrum.ieee.org/static/interactive-the-top-programming-languages-2018
P.S. Ryby на 13-м месте в этом рейтинге.
Кто такой это Павел Сережин? Зачем он тут? Только неадекватные заявления, снижающие ценность текста.
Знаком неплохо с Ruby, как ни странно — это не Ruby on Rails, а был RubyQt — биндинг Qt для руби. Использовался для разработки ERP системы. Очень неплохо зашел, так как писалось все в стиле unix-way — делались простые GUI скрины для каждой задачи, потом из одного меню вызывались.
Руби конечно крут в плане синтаксиса и чистоты написания кода и выражения мыслей, если сильно не впадать в идиоматический код с очень короткими методами.
Сейчас работаю с web — бекэнд на Go. Думаю, что в плане производительности работы веб сервисов Go — вне конкуренции. Но написать быстро прототип Web приложения на Go кажется довольно трудным. Очень не хватает как раз готового фреймворка, чтобы не делать стандартные вещи руками. Но думаю, его и не будет из-за того, что Go не выразительный язык, много лапши с if err != nil
Интересует такой момент. Можно ли использовать как раз оба продукта: Ruby on Rails для быстрого написания прототипа, а затем отдельные куски переписывать на Го (если проседает производительность)?
По идее можно поставить перед ними Nginx и отдельные роуты, которые надо заоптимайзить, пробрасывать на Go сервисы.
Кто-то делать так, может поделиться, насколько это жизнеспособно?
Спасибо.
Руби конечно крут в плане синтаксиса и чистоты написания кода и выражения мыслей, если сильно не впадать в идиоматический код с очень короткими методами.
Сейчас работаю с web — бекэнд на Go. Думаю, что в плане производительности работы веб сервисов Go — вне конкуренции. Но написать быстро прототип Web приложения на Go кажется довольно трудным. Очень не хватает как раз готового фреймворка, чтобы не делать стандартные вещи руками. Но думаю, его и не будет из-за того, что Go не выразительный язык, много лапши с if err != nil
Интересует такой момент. Можно ли использовать как раз оба продукта: Ruby on Rails для быстрого написания прототипа, а затем отдельные куски переписывать на Го (если проседает производительность)?
По идее можно поставить перед ними Nginx и отдельные роуты, которые надо заоптимайзить, пробрасывать на Go сервисы.
Кто-то делать так, может поделиться, насколько это жизнеспособно?
Спасибо.
Интересует такой момент. Можно ли использовать как раз оба продукта: Ruby on Rails для быстрого написания прототипа, а затем отдельные куски переписывать на Го (если проседает производительность)?Да, примерно так это будет выглядеть.
По идее можно поставить перед ними Nginx и отдельные роуты, которые надо заоптимайзить, пробрасывать на Go сервисы.
Проблема, с которой будете сталкиваться — неподходящая архитектура. По факту, вы пишете монолит на рельсах, а потом решаете сделать микросервисы — часть на рельсах, часть на go. Но в монолите обычно разные куски сильно связаны друг с другом, а значит, вы будете писать повторяющиеся куски бизнес-логики и на рельсах и на go, дописывать отдельное приватное апи в рельсах — потому что go будет время от времени у них что-то спрашивать — и наоборот, рельсы будут что-то спрашивать у go.
В общем — весело будет всем. Я бы сказал, что если есть такая возможность — лучше заморозить рельсы (или замедлить выход новых фич), параллельно писать приложение на go, а потом, когда оно будет готово, разом переключиться. Иначе — бардак обеспечен.
Сейчас разрабатываю мелкого и среднего размера api на Go. Хочу сказать (мое мнение), что на нем трудно описывать бизнес логику — маловато абстракций. И очень много ручной работы. Есть желание поделать именно web проект, а не только api, но на Го устанешь все писать). Поэтому посматриваю в сторону какого-нибудь фреймворка. Руби знаю, поэтому и написал про него. Смотрю — сейчас активно развивается PHP — но сам язык после руби, довольно уродливым показался. Хотя это всего лишь язык — инструмент. Возможно придется и его поизучать.
Писал на пыхе более десяти лет. Вообще писал много на чем, но основным ЯП все же была пыха. Это боль, муки страдания на проекте, сложнее какого-либо лендинга или блога. Каждый прогер пишет как хочет. Код не читаемый вообще. Язык полное днище. Ушел в Руби, так как уже кровь из глаз пошла, постоянно разгребать это жуткое легаси.
Писать на Пыхе уметь надо) Я тоже работаю с ним немало лет и лучшего ЯП для разработке под веб так и не нашел. Под любую задачу можно найти массу готовых решений, гибкость максимальная, никаких проблем даже в крупных проектах. Нужно просто договариваться по соглашениям об организации кода и следовать им.
Самое главное — избегать проектов-самописов, все делать на фреймворках. В идеале на одном (я выбрал Yii2).
Изучал в разное время Python, Ruby — не зашли. Да, все красиво и изящно, но на рынке PHP нет равных. Синтаксис не кажется уродливым, он просто другой.
Но тем не менее, эволюционировать надо и поэтому в свободное время начал изучать Go.
Самое главное — избегать проектов-самописов, все делать на фреймворках. В идеале на одном (я выбрал Yii2).
Изучал в разное время Python, Ruby — не зашли. Да, все красиво и изящно, но на рынке PHP нет равных. Синтаксис не кажется уродливым, он просто другой.
Но тем не менее, эволюционировать надо и поэтому в свободное время начал изучать Go.
Самое главное — избегать проектов-самописов, все делать на фреймворках. В идеале на одном (я выбрал Yii2).
Это очень дельное замечание. Только мне юи не зашел, пользовался ларкой, в основном. Но и на симфони было пару проектов.
Но большинство крупных проектов-монстров на которых я работал — это были именно самописы. Спустя пол года такой работы в любой конторе, мне хотелось брать в руки автомат и всех стрелять! :))
И главное начальство не хотело ничего трогать, менять, переходить на современные технологии. Мол 20 лет работало, еще столько же нам будет денег приносить. До разума не достучаться, тебя скорее уволят (хоть и ведущий разработчик), чем дадут что-то довести до ума.
После последнего такого проекта, я окончательно решил сбежать с пыхи. У меня даже статейка есть сравнения ларки и рельсов (чисто мои личные ощущения): cleverman.org/post/laravel-ili-ruby-on-rails
А Buffalo не пробовали? Вроде похож на Rails. Да и ещё куча фреймворков есть на Go.
У меня, кстати, аналогичное восприятие пыхи после руби)
У меня, кстати, аналогичное восприятие пыхи после руби)
Мне тоже php кажется уродливым — но я на нем лет 5 назад последний раз писал и не собираюсь возвращаться :) Хотя слышал, что он сейчас круто развивается.
На go люди обычно пишут, когда реализовывают микросервисную архитектуру. Большой сложный нагруженный веб проект, с десятком микросервисов, балансировщиком, месседж брокером и прочими радостями. Монолитное приложение на нем не так часто пишут.
Если вы хотите делать веб приложения «старого типа», когда браузер по запросу получает готовую веб страницу — лучше рельсов до сих пор нет ничего. Если же «нового типа» — когда фронт отделен (вроде реакта, ангуляра или вуе) и рендерится самостоятельно в браузере, а от сервера требуется только апи — тут голые рельсы не идеально конечно подходят. Можно в этом случае либо использовать рельсы + grape (гем для описания апи) — я таким путем обычно иду, либо из отдельных гемов (грейп/синатра + актив рекорд + ...) собрать себе приложение — но тут ручной работы больше и часть «фишек» рельсов исчезают, либо вообще использовать nodejs — за счет асинхронности оно для апи-приложений хорошо подходит, но плохо, если нужно рендерить html.
На go люди обычно пишут, когда реализовывают микросервисную архитектуру. Большой сложный нагруженный веб проект, с десятком микросервисов, балансировщиком, месседж брокером и прочими радостями. Монолитное приложение на нем не так часто пишут.
Если вы хотите делать веб приложения «старого типа», когда браузер по запросу получает готовую веб страницу — лучше рельсов до сих пор нет ничего. Если же «нового типа» — когда фронт отделен (вроде реакта, ангуляра или вуе) и рендерится самостоятельно в браузере, а от сервера требуется только апи — тут голые рельсы не идеально конечно подходят. Можно в этом случае либо использовать рельсы + grape (гем для описания апи) — я таким путем обычно иду, либо из отдельных гемов (грейп/синатра + актив рекорд + ...) собрать себе приложение — но тут ручной работы больше и часть «фишек» рельсов исчезают, либо вообще использовать nodejs — за счет асинхронности оно для апи-приложений хорошо подходит, но плохо, если нужно рендерить html.
Так ведь есть чудесный Rails API. В нем нет ничего лишнего. Я от рельсов вообще беру только роуты, контроллеры и модельки. При чем все модельки пустые с привязкой к таблицам постгреса. А все запросы нативные, которые я храню в репозиториях (подготовленные методы с запросами и биндингами). Скорость работы отличная. Гемы использую по минимуму, накидать свое решение можно очень быстро и самостоятельно на голом руби. Мое личное мнение, что если программист и не программист (у этого слова есть четкое определение), а всего лишь знает синтаксис ЯП, то он и скачет по фреймворкам и ЯП, в надежде облегчить себе жизнь. Только это ему не поможет.
Мне Rails API обычно бывает недостаточно. Причины 3:
1. Самая незначительная. Все запросы, кроме crud, нужно добавлять в роутер по-отдельности.
2. Валидация входных параметров. У грейпа она настолько крутая, что уже невозможно отказаться.
3. Генерация документации по апи для фронтендеров. Я написал себе небольшой класс, который парсит апи и отдает json с его структурой. Плюс html страничку, которая берет этот json и превращает его в множество интерактивных форм для отправки тестовых апи запросов. Такой самописный swagger получился, т.к. оригинальный меня не устраивает в некоторых местах.
1. Самая незначительная. Все запросы, кроме crud, нужно добавлять в роутер по-отдельности.
2. Валидация входных параметров. У грейпа она настолько крутая, что уже невозможно отказаться.
3. Генерация документации по апи для фронтендеров. Я написал себе небольшой класс, который парсит апи и отдает json с его структурой. Плюс html страничку, которая берет этот json и превращает его в множество интерактивных форм для отправки тестовых апи запросов. Такой самописный swagger получился, т.к. оригинальный меня не устраивает в некоторых местах.
1. Это да. И часто у меня функционал, который описать ресурсом не получится. Очень много ручных роутов. Но я с этим живу, путем разбивания роутов на отдельные файлы, в которых роуты для конкретных сущностей.
2. Я когда перешел на рельсы, то радовался, что валидатор находится в модели. Типа там, где ему и место. Как только пошли сложные данные, которые должны валидироваться, но не должны сохраняться в базу или на основе проверки менять данные для сохранения, то я понял, что так дело не пойдет. Пришлось писать свою обертку над стандартным валидатором, а для сущностей делать свои файлы валидаторов (где нужно со сложной логикой). Плюс подгонять их для работы с юнит тестами. Теперь хоть могу валидировать данные где угодно. Но это кастомное решение, над которым пришлось повозиться.
3. Вот этим я не занимался. Мне проще глянуть в роуты, если я чего забыл. А для тестирования АПИ я использую Postman
А вообще я перебрал уйму ЯП. И просто из любопытства и в поиске быстрого, удобного и универсального инструмента. И понял, что серебряной пули не существует. ЯП, к сожалению — это далеко не все, что должен знать и уметь хороший специалист.
Поэтому я остановился на очень гибком ЯП (руби), с очень приятным синтаксисом. В конце концов, все эти разговоры о производительности очень часто звучат от людей, которые не знают, что это вообще такое. Многие сидят на небольших проектах, с дневной посещаемостью в пару тыс. человек, в лучшем случае. А большинство тормозов возникает из-за БД и больших пингов.
2. Я когда перешел на рельсы, то радовался, что валидатор находится в модели. Типа там, где ему и место. Как только пошли сложные данные, которые должны валидироваться, но не должны сохраняться в базу или на основе проверки менять данные для сохранения, то я понял, что так дело не пойдет. Пришлось писать свою обертку над стандартным валидатором, а для сущностей делать свои файлы валидаторов (где нужно со сложной логикой). Плюс подгонять их для работы с юнит тестами. Теперь хоть могу валидировать данные где угодно. Но это кастомное решение, над которым пришлось повозиться.
3. Вот этим я не занимался. Мне проще глянуть в роуты, если я чего забыл. А для тестирования АПИ я использую Postman
А вообще я перебрал уйму ЯП. И просто из любопытства и в поиске быстрого, удобного и универсального инструмента. И понял, что серебряной пули не существует. ЯП, к сожалению — это далеко не все, что должен знать и уметь хороший специалист.
Поэтому я остановился на очень гибком ЯП (руби), с очень приятным синтаксисом. В конце концов, все эти разговоры о производительности очень часто звучат от людей, которые не знают, что это вообще такое. Многие сидят на небольших проектах, с дневной посещаемостью в пару тыс. человек, в лучшем случае. А большинство тормозов возникает из-за БД и больших пингов.
Боже мой! Как мне развидеть прочитанное?! Вся статья — это просто какой-то словесный понос! Примеров нет, каких-то описанных задач нет. Бизнес хочет экономить на ресурсах, это просто жесть! На каких ресурсах? Сэкономить на 32 гигах оперативы? С одной стороны говорят, что простой и понятный синтаксис, как вроде пишешь на английском, а потом говорят, что читать код невозможно. Вначале говорят, что ни хрена не развивается, мол все старое, а потом говорят, что развитие даже сейчас происходит. Все ноют про статическую типизацию (и это в интерпретируемом языке). На хрена она вам? Здесь строгая динамическая типизация. Ее более чем достаточно. Вся статья ни о чем! Одно какое-то бла-бла-бла. Пишут на руби и новые проекты и старые поддерживают! Вот уже альфа рельсов шестых вышла, релиз на подходе. Сам руби 2.5.3 в rvm доступна. Как вообще можно сравнивать Ruby с JS? Это же, млять, днище полное! Мол, пишет один, он такой из себя запупенный фулстек, но хочет уйти во фронт на реакте писать. Знать JS и React, как дополнительную технологию, я это еще понимаю, но уйти с бэкенда на фронт — это очень многое говорит о специалисте.
Руби и рельсы живы и будут и дальше жить. Это всего навсего инструмент. Отличный инструмент. А всякие хипстеры будут до конца дней своих скакать от технологии к технологии, разводя бизнес на бабки, внушая своим боссам, что важен именно ЯП, а не профессиональные специалисты, которые умеют строить архитектуру. На какой проект не попадешь, как откроешь запросы к БД, так, сука, плакать хочется. Ни индексов правильно расставить не умеют, ни запрос грамотно составить (вместо одного запроса тянут данные пятью и больше). Зато ЯП им виноват, давайте все на Go перепишем, он же быстрее.
А из свежих проектов, которые появились на рельсах и реакте — это проект по расчету стройматериалов e-tamarin.com Так что используют руби и рельсы, и ГитХаб тоже все устраивает. Растет и развивается. А тот, кто вайтишник, ему всегда будет что-то мешать, то плохие ЯП, то сложные БД, то слабые сервера, то отсутствие четвертого вэбпака в серверном языке (это вообще был перл).
Руби и рельсы живы и будут и дальше жить. Это всего навсего инструмент. Отличный инструмент. А всякие хипстеры будут до конца дней своих скакать от технологии к технологии, разводя бизнес на бабки, внушая своим боссам, что важен именно ЯП, а не профессиональные специалисты, которые умеют строить архитектуру. На какой проект не попадешь, как откроешь запросы к БД, так, сука, плакать хочется. Ни индексов правильно расставить не умеют, ни запрос грамотно составить (вместо одного запроса тянут данные пятью и больше). Зато ЯП им виноват, давайте все на Go перепишем, он же быстрее.
А из свежих проектов, которые появились на рельсах и реакте — это проект по расчету стройматериалов e-tamarin.com Так что используют руби и рельсы, и ГитХаб тоже все устраивает. Растет и развивается. А тот, кто вайтишник, ему всегда будет что-то мешать, то плохие ЯП, то сложные БД, то слабые сервера, то отсутствие четвертого вэбпака в серверном языке (это вообще был перл).
Но при этом существуют же некие преданность технологии и даже культ инструмента. Скажи пхп-шнику, что пора переезжать на .NET, услышишь «PHP отличный, полмира на нем пишет», или просто получишь в лоб.
Я из этой же кагорты. Для меня лучше Tcl/Tk ничего нет.
Sign up to leave a comment.
Пацаны, так Ruby умер или нет?