Поддержу автора, тоже есть такое ощущение. Недавно ушел из очень крупной и богатой компании с высокой должности из за такого пма, то есть никакого. Токсичность, отсутствие базовых скиллы, хамство, не участие и тп.
Опять же вспоминаю что было 10 лет назад, в компании абак-пресс. Вот были люди, процессы, атмосфера.
Есть ощущение что профессию пма убили тем что в большинстве компаний теперь хотят что бы эту роль выполнял тимлид или продукт. Пмы многие тоже в продуктов подались. Наверно хорошие все же есть, но их доля очень мала.
Тот случай когда коммент важнее и экспертной статьи. Согласен, придерживаюсь такого же подхода. Менеджер это отдельная профессия и уважать его должны не за технические знания. В некоторых случаях при ведении он может быть и техническим лидером, но обычно это не так, это не нужно и не эффективно.
Например я технарь, а меня все в лиды зовут, а пил менеджмент и прочие 1 на 1 мне не доставляют.
Конечно может. У тимлида искажения, он обычно недооценивает. Оценивать должны исполнители и хорошо когда в целом они попадают и плохой знак когда регулярно ошибаются. Тимлид как раз должен помочь учесть риски, задать наводящие вопросы.
Статистики правдивой по стартапам у меня нет. На счёт популярности и кол-ва стартапов можно узнать у злых марсиан и еврон, например. Но по моей информации руби остаётся одним из главных языков для стартапов и очень популярен в штатах.
А на чем пишут стартапы по вашему чаще всего? Наверно для бека на первом месте Пайтон, на втором нода? (Сомнительно) А дальше? Вероятно руби.
Ну и кол-во не означает удобство, эффективность, удовольствие от работы, высокую оплату труда. Все это вы получите на руби.
Вы бы хоть изучили вопрос про большие компании. Гитхаб, гитлаб, шопифай, хоть тот же сбермаркет.
Как разработчик руби скажу что после руби писать на чем то другом очень тяжко по соображениям удобства, скорости разработки, читаемости и эстетики. Экосистема, комьюнити, подходы в сообществе значительно опережают конкурентов по-моему.
И да, за 10 лет работы преимущественно на высоконагруженных проектах случаев когда мы упирались в перформанс руби / рельс были единичные и там да писали 300 строк на го / си.
Также считаю что рельсы остаются лучше платформой для быстрой разработки и заслуживаю большей популярности.
По некоторым данным сейчас идёт ренессанс рельс, смотри Твиттер.
Яндекс конечно зло. По факту они убивают такси. Стало очень дорого и не приятно. Стараюсь пользоваться как можно реже. Опять же эта проблема с детскими креслами. Монополия зло. Государство обязано регулировать.
А ещё исключения очень дорогие и не позволяют выразить идею "эта функция ни при каких условиях не завершится с ошибкой".
Видимо я не понял проблему. Перехвати все стандартные (не системные) исключения вот и все.
> А громоздкость обработки ошибок через Result решается через комбинаторы/оператор вопросительного знака/do-notation.
Покажите мне пожалуйста красивый, не мусорный код на го где этак концепция применяется и не нужно после каждого вызова явно проверять код ответа.
> А как сделать свой доменный класс для ошибок и сделать так, чтобы ошибки из сторонних библиотек его наследовали?)
На руби это решается выносом базовых классов в базовую библиотеку (гем) или путем калбеков - одна библиотека выставляет калбек в котором ты в приложении можешь что-то проинициализировать (создать экземпляр нужного исключения) или на уровне конфигурации - передача прикладного класса исключения в приложении как опции для библиотеки.
И при этом сложно определить, когда исключение является обычной ошибкой, которую надо обработать, а когда - непредвиденной ситуацией, по которой нужно аварийно всё завершать.
Это легко решается создание своего класса исключения (прикладного) и наследования от него всей нужной иерархии и их обработки. При этом код не засоряется всем этим мусором бесконечным.
Как практик с 20 летним стажем, к сожалению я не понял что вы хотели сказать. Громоздкость зависит от языка. Не вижу громоздкости например в Руби. По не явному возврату значения тоже не понятно. Почему объект исключения не может содержать ссылки или значения дополнительные? Ну и в нормальном языке (например Руби) тебе никто не мешает создать объект / метод у которого будет результат, в том числе говорящей о ошибке и возвращающей доп. инфу.
Как практик, в принудительном навязывании способа обработки ошибок через явную обработку возвращаемого значения каждой функции, я вижу очень вредный подход, который засорят код и заставляет писать и читать весь этот мусор.
Экономить нужно когнитивный ресурс человека (прежде всего того который будет годами читать этот код).
А кто то может рассказать чем сейчас Андрей в Авито занимается? Сфинкс докручивает или что-то большее ? интересно. Много лет пользовались сфинксом, нравилось. Даже частную консультацию брали у Андрея.
А чем исключения плохи можете пояснить? если не говорить о перфомансе. Я вот ни как не могу принять эти "новые концепции обработки ошибок". Все эти проверки кодов ответа кажутся откатом к темным временам.
Elixir
Рекомендую взглянуть на язык Elixir. Это просто праздник какой-то!
Спасибо за статью по Elixir и OTP!
Нужно нести людям такие прекрасные технологии.
Поддержу автора, тоже есть такое ощущение. Недавно ушел из очень крупной и богатой компании с высокой должности из за такого пма, то есть никакого. Токсичность, отсутствие базовых скиллы, хамство, не участие и тп.
Опять же вспоминаю что было 10 лет назад, в компании абак-пресс. Вот были люди, процессы, атмосфера.
Есть ощущение что профессию пма убили тем что в большинстве компаний теперь хотят что бы эту роль выполнял тимлид или продукт. Пмы многие тоже в продуктов подались. Наверно хорошие все же есть, но их доля очень мала.
Тот случай когда коммент важнее и экспертной статьи. Согласен, придерживаюсь такого же подхода. Менеджер это отдельная профессия и уважать его должны не за технические знания. В некоторых случаях при ведении он может быть и техническим лидером, но обычно это не так, это не нужно и не эффективно.
Например я технарь, а меня все в лиды зовут, а пил менеджмент и прочие 1 на 1 мне не доставляют.
Конечно может. У тимлида искажения, он обычно недооценивает. Оценивать должны исполнители и хорошо когда в целом они попадают и плохой знак когда регулярно ошибаются. Тимлид как раз должен помочь учесть риски, задать наводящие вопросы.
На самом деле, это все настолько тонкая материя.
Это был ответ на
Статистики правдивой по стартапам у меня нет. На счёт популярности и кол-ва стартапов можно узнать у злых марсиан и еврон, например. Но по моей информации руби остаётся одним из главных языков для стартапов и очень популярен в штатах.
А на чем пишут стартапы по вашему чаще всего? Наверно для бека на первом месте Пайтон, на втором нода? (Сомнительно) А дальше? Вероятно руби.
Ну и кол-во не означает удобство, эффективность, удовольствие от работы, высокую оплату труда. Все это вы получите на руби.
На мой взгляд лучшее что есть в плане сочетания эффективности, перформанса, удобства, эстетики и читаемости. Жаль что популярность мала.
Вы бы хоть изучили вопрос про большие компании. Гитхаб, гитлаб, шопифай, хоть тот же сбермаркет.
Как разработчик руби скажу что после руби писать на чем то другом очень тяжко по соображениям удобства, скорости разработки, читаемости и эстетики. Экосистема, комьюнити, подходы в сообществе значительно опережают конкурентов по-моему.
И да, за 10 лет работы преимущественно на высоконагруженных проектах случаев когда мы упирались в перформанс руби / рельс были единичные и там да писали 300 строк на го / си.
Также считаю что рельсы остаются лучше платформой для быстрой разработки и заслуживаю большей популярности.
По некоторым данным сейчас идёт ренессанс рельс, смотри Твиттер.
Ruby and Rails forever!
Правильная и нужная статья! Доколе! А еще можно написать про Пандемическое соглашение...
Хотел бы гибрид. Офис нужен и полезен, как опция.
Яндекс конечно зло. По факту они убивают такси. Стало очень дорого и не приятно. Стараюсь пользоваться как можно реже. Опять же эта проблема с детскими креслами. Монополия зло. Государство обязано регулировать.
Видимо я не понял проблему. Перехвати все стандартные (не системные) исключения вот и все.
> А громоздкость обработки ошибок через Result решается через комбинаторы/оператор вопросительного знака/do-notation.
Покажите мне пожалуйста красивый, не мусорный код на го где этак концепция применяется и не нужно после каждого вызова явно проверять код ответа.
> А как сделать свой доменный класс для ошибок и сделать так, чтобы ошибки из сторонних библиотек его наследовали?)
На руби это решается выносом базовых классов в базовую библиотеку (гем) или путем калбеков - одна библиотека выставляет калбек в котором ты в приложении можешь что-то проинициализировать (создать экземпляр нужного исключения) или на уровне конфигурации - передача прикладного класса исключения в приложении как опции для библиотеки.
Это легко решается создание своего класса исключения (прикладного) и наследования от него всей нужной иерархии и их обработки. При этом код не засоряется всем этим мусором бесконечным.
Как практик с 20 летним стажем, к сожалению я не понял что вы хотели сказать. Громоздкость зависит от языка. Не вижу громоздкости например в Руби. По не явному возврату значения тоже не понятно. Почему объект исключения не может содержать ссылки или значения дополнительные? Ну и в нормальном языке (например Руби) тебе никто не мешает создать объект / метод у которого будет результат, в том числе говорящей о ошибке и возвращающей доп. инфу.
Как практик, в принудительном навязывании способа обработки ошибок через явную обработку возвращаемого значения каждой функции, я вижу очень вредный подход, который засорят код и заставляет писать и читать весь этот мусор.
Экономить нужно когнитивный ресурс человека (прежде всего того который будет годами читать этот код).
А кто то может рассказать чем сейчас Андрей в Авито занимается? Сфинкс докручивает или что-то большее ? интересно. Много лет пользовались сфинксом, нравилось. Даже частную консультацию брали у Андрея.
На главной же написано язык для людей. Тем не менее и для компьютера то есть быстрый.
Backend можно и даже очень хорошо. на счет UI не уверен. Не все сразу. Развивайте, двигайте. Я вот доначу регулярно уже много лет.
https://github.com/hugopl/gtk4.cr
Давайте популяризировать и развивать язык Crystal!
https://crystal-lang.org/
А чем исключения плохи можете пояснить? если не говорить о перфомансе.
Я вот ни как не могу принять эти "новые концепции обработки ошибок". Все эти проверки кодов ответа кажутся откатом к темным временам.