Комментарии 142
Вы там карму (метафизическую, уточняю) себе чистите, что-ли?
Я бы в первую очередь предположил, что спасают, что еще можно с тонущего корабля (и спасибо за это, clickhouse очень вовремя отделился например).
Буквально вчера заметил, что Clickhouse поменял организацию/namespace свой. Думаю вы правы
Clickhouse ещё и выпустил антивоенный пост в блоге, чего Яндекс себе совсем позволить не может.
delete
Компания со штаб-квартирой в Калифорнии, соучредители и инвесторы из США, 3 месяца назад оказывается выпустила антивоенное заявление.
Действительно удивительно)
Внезапно, Clickhouse Inc – это не Яндекс, там иностранный капитал на 300 миллионов и американские соучредители.
In September of 2021 in San Francisco, CA, ClickHouse incorporated to house the open source technology with an initial $50 million investment from Index Ventures and Benchmark Capital with participation by Yandex N.V.[2] and others. On October 28, 2021 the company received Series B funding totaling $250 million at an evaluation of $2 billion from Coatue Management, Altimeter Capital, and other investors. The company continues to build the open source project and engineering cloud technology.
Вовремя предать - это не предать, а предвидеть. (С)
согласен, всё это смахивает на вывод активов под соусом выпуска в опенсорс.
Если это так, то могу только восхититься руководством Яндекса. Но не слишком получается верить.
здесь явно такое... что лучше утащить на дно к скорому полному погружению )
Как читать-то? юзер-вер или ю-сервер?
u-server, по русски читается как "у-сервер"
Название появилось благодаря следующим трансформациям: берём слово 'microserver', сокращаем его согласно международной системе единиц СИ, получаем 'µserver', превращаем букву 'µ' в 'u' (чтобы проще было в коде использовать).
Тут православное: "Юзер! Верь!"
Это что получается, обратно свой продакшн веб-сервисы с ржавы на С++ переписывать? :)
запилите реализацию бенчмарков, чтобы попасть сюда https://www.techempower.com/benchmarks
С подозрением смотрю на микросервис на с++, который используется для "еды"...
То есть нужен C++-фреймворк. Язык хорош ещё и тем, что не зависит от одного вендора/компании, является статически типизированным и одним из самых эффективных языков программирования.
Wait a minute..?
Хорошо что он останется только за дверями яндекса )
В современном мире такое точно не нужно
В какой-то момент разработчики столкнулись с проблемой, что быстрый рост популярности Лавки привёл к непропорционально большому росту нагрузки на сервисы. Назрела необходимость переносить их на более эффективный язык программирования.1. А на чём до этого было?
2. Проще полностью на новом языке написать, чем оптимизировать существующее?
Разработчики столкнулись с отсутствием функциональности в используемом фреймворке.Какая особая функциональность нужна в крудах, которой нет в типичных фреймворках, но есть в userver?
Какая особая функциональность нужна
Нам важна проработанность различных компонентов и плотная их интеграция друг другом. Например в каких-то фреймворках есть драйвер для некоторых баз данных, в каких-то есть библиотека для изменения конфигурации сервиса без рестарта, где-то есть библиотеки для записи метрик. Фреймворков на C++, где есть все эти компоненты и они состыкованы друг с другом - до сегодняшнего момента не было.
Вот пример, для чего нам нужна состыкованность:
Мы пишем статистики по неудачным запросам. На их основе можно делать алерты - всякие рассылки разработчикам "Внимание! Происходит что-то странное, ваш запрос стал в 10 раз чаще завершаться с ошибкой". Получив такой алерт разработчик пойдёт диагностировать проблему. И например поймёт, что внезапно количество пользователtй стало в 10 раз больше. После чего разработчик с помощью динамической конфигурации, увеличит количество соединений с базой данных. Проблема уйдёт, при этом рестарт сервиса или его перевыкатка не потребовались.
Нам показалось хорошей идеей поделиться с миром своим фреймворком, чтобы он нашёл применение в новых полезных направлениях.
Пожалуйста, поделитесь с миром своими фотографиями, которые сделаны в Музее Яндекса, и звукозаписями, которые там сделаны.
Спасибо.
Про фотографии запрос понятен, подумаем. Звуки уже выложили под свободной лицензией.
Объясните пожалуйста заплюсованность статьи, я не понимаю. В чем профит фреймворка для крудов на плюсах в 2022? Проще реализовать бизнес-логику? Может, быстрее таймтумаркет? Или стала проще поддержка кода? Или на волне хайпа плюсов на рынке много дешевых плюсовиков? Такое ощущение, что в штате яндекса просто скопилось много олимпиадников и менеджмент просто не мог придумать более толковой задачи, ну или я просто чего-то не понимаю.
Проще реализовать бизнес-логику?
Зависит от бизнес-логики. Если нужны эксперименты - проще, т.к. есть динамические конфиги. Если нужно чтобы бизнес-логика укладывалась в таймауты - проще, есть готовые кеши, метрики и возможность на лету менять таймауты.
Может, быстрее таймтумаркет? Или стала проще поддержка кода?
В гите лежат шаблоны сервисов, они ускоряют первые шаги в разработке и улучшают таймтумаркет. Готовая инфраструктура для тестирования микросервиса, поднятия базы и мока сервисов - тоже положительно влияет. Отлаженность инструмента на масштабах большой компании - тоже плюс, поддержка кода сильно проще. Статсистика, опентрейсинг и изкоробочное логирование помогают диагностике и тоже положительно влияют на таймтумаркет и поддержку.
Вы не спросили про другие важные пункты:
Эффективность по CPU - да, есть. Железо нынче дорогое, это важно.
Эффективность по времени ответа - да, есть. Времена ответа бека влияют на удобство пользоватлей, влияют на частоту использования сервиса.
Простота написания кода - да, есть. Вся асинхронность и коллбеки спрятаны, при разработке не надо страдать с ними.
Ну и от себя могу сказать следующее: лично я всегда рад когда какой-то проект выходит в опенсорс. Я не знаю, какая технология мне понадобится завтра, возможно что та, которую открыли вчера. А ещё в опенсорс проектах всегда можно найти интересные решения, научиться чему-то новому и в дальнейшем использовать в своей разработке.
Как плюсы могут положительно влиять на поддержку кода, особенно где много бизнес-логики? Как?) Как?) Читаешь исходник через месяц, а там account.#$%&!÷%Delete(#)(,#@==_ dfr<>fromDatabase$#(÷[][(÷)...
>Эффективность по цпу. Ну ок, 3 плюсовика пишут эффективно, остальных бэкендеров перекинули с прекрасных выразительных языков со сборщиком мусора на плюсы и памяти больше нет, ага.
Дальше даже не хочется спорить, мне в принципе без разницы, опенсорс это конечно хорошо, но выглядит так, будто вы мне не как разработчику объяснить пытаетесь, а пытаетесь мне это продать, в принципе то же самое и в статье. Ну или это просто плюсовый стокгольмский синдром, не знаю, время покажет...
Как плюсы могут положительно влиять на поддержку кода, особенно где много бизнес-логики?
Через простоту читаемости кода на плюсах. Его детерминированность, если хотите.
Через простоту читаемости кода на плюсах. Его детерминированность, если хотите.
а потом:
Монолитное приложение — плохое решение с точки зрения отказоустойчивости. SegFault во второстепенном модуле роняет весь сервис. При этом, не дождавшись ответа от бэкенда, клиент сделает перезапрос, затем ещё один — и вот уже три инстанса монолита находятся в нокдауне. В теории пара десятков таких клиентов могут привести к полной неработоспособности сервиса. Разумеется, у нас множество механизмов для предотвращения подобных проблем. Но всё равно неприятно.
Сочетание "низкоуровневое программирование + отсутствие ГЦ + популярный ЯП + бизнес-логика" порождает противоречия и в дело вступают трейдоффы. Тут примерно такая же история, как и в случае CAP-теоремы для бд. Будет не лучшим выбором изначально писать бизнес-логику на плюсах (особенно, когда у нас есть выбор, а он у нас на самом деле есть, я объясню далее), потому что это низкоуровневый язык и мы имеем дело с массой объектов, которые мы всегда должны держать в уме помимо бизнес-логики. Что не так с бизнес-логикой? Условия меняются буквально каждый день и, соответственно, код будет меняться тоже практически каждый день. Например, код на плюсах будет окей для условного ядра новой базы данных, потому что там да - важна скорость и логика будет меняться не так быстро, потому что ядру базы данных плевать на изменения в обществе, плевать на какие-то новые законы, плевать на решения менеджмента, желания разработчиков/пользователей/кота и тд и тп. И вот помимо всего этого вам нужно думать о памяти, о синтаксических/семантических особенностях плюсов, что только увеличивает и время разработки и количество ошибок в коде.
Почему же у нас есть выбор писать на других языках и что же мы такого важного забыли? Фреймворк для микросервисов (как постулируется в статье). Ещё раз, микросервисов. Не монолит, микросервисы. Что же нивелирует все профиты плюсов в контексте микросервисов? Правильно, сеть! Суть микросервисов - работа по сети и тут встаёт, соответственно, вопрос - а даст ли фреймворк на плюсах вообще хоть какой-то профит, когда большая часть ожидания уходит на сеть?
Универсальный ответ Питон или Джава/Котлин. Смысл использования чего-то другого для сервисов где основное время это IO непонятен.
Питон если проект ближе к стартапу и все будет пять раз переписано с хорошей вероятностью.
Джава если проект ближе к энтерпрайзу и код будет жить годами.
Питон или Джава/Котлин
C# ещё :)
Питон если проект ближе к стартапу
Джава если проект ближе к энтерпрайзу
Везде встречаю мысль что на путоне писать быстрее чем на жава, но понять не могу почему. Пишем же не на голой жаве, а с использованием популярного фреймворка. Пишем в ИДЕ, запускаем, отлаживаем в ИДЕ, деплоим из ИДЕ, БД подключаем в ИДЕ, сервер предоставляется фреймворком. Плюс, фреймворк диктует сразу правильную структуру приложения (хотя, конечно, никто нам не запретит писать спагетти-код...). Плюс, имеем нормальные средства отладки. Плюс, можем сразу делать заготовки под документацию.
Так в чём знаменитая скорость разработки на путоне? Многословность жавы? Сейчас уже нет. Есть ИДЕ с автогенерацией стандартного кода, есть Ломбок, есть жава-17 с новыми типами (мы же про стартап, значит используем последнюю ЛТЕ, верно?).
Так почему такая прорва того же вэба на путоне? Вон, на аутсорс-площадках не протолкнуться: "спасити-памагагити, надо дописать к нашему серверу на этом вашем Джанго"?
Простота? Нет! Вон, для приёма на стажировку по жава надо уметь наколотить вэб-круд на Спринге с бд и фронтэндом. Т.е. это достаточно просто даже для новичка.
Так в чём дело?
Динамическая типизация (соглашусь, тут можно поспорить, сейчас почти везде есть инференс типов, но всё же), упрощённое ООП (не нужно даже писать геттеры/сеттеры по факту, не говоря уже о разных паттернах), огромное количество готовых/полуготовых решений для чего угодно - генерация файлов от изображений до пдф, аутентификации через сторонние сервисы, работу с геоданными в той же джанге подключить на раз два, достаточно заюзать геоджанго и постгис, легко делать простые дашборды с тем же dash или хотя бы фласком и тд и тп
>Вон, для приёма на стажировку по жава надо уметь наколотить вэб-круд на Спринге с бд и фронтэндом. Т.е. это достаточно просто даже для новичка.
А может, дело как раз в этом?) В случае питона, зачастую, этого достаточно для мидла. А для собеса на джаву пойди выучи всю теорию работы jvm, ооп, разницу между версиями и в какой версии какие фичи можно юзать, а потом ещё будь добр уметь в круды (спринг, работа с бд и минимальный фронт, что на самом деле тоже огромная нагрузка).
Если вы имеете ввиду что брать в дополнение к вашему стеку для узких задач, то ответ классический - it depends. Недостатки будут в любом случае, вопрос в том, с какими из них вы можете позволить себе жить дальше с минимумом проблем. Например, в случае питона можно писать код на cython, который позволит убрать какие-то боттлнеки по скорости. В случае, если вам нужно написать сервис для вашего приложения, обрабатывающий огромное количество сетевых соединений, например чатик на вебсокетах, то, возможно, неплохим решением будет найти разработчика на том же go, если текущий стек имеет проблемы с этим. Всё зависит от задачи, от бюджетов, от штата разработчиков. Какие-то задачи уже вполне решены и оптимизированы на тех же сях или плюсах и имеют высокоуровневые интерфейсы - например, задачи машинного обучения или просто матлибы, которыми куда проще пользоваться из того же питона. Если у вас есть задача сверхбыстрого оптимизированного запроса для бд и штат из разрабов, умеющих в запросы, но не умеющих в бэк на вашем стэке - мб даже будет оптимальным решением решить этот вопрос на стороне бд в условных хранимках, кто знает, тут нет универсальных решений.
Rust же
В чем профит фреймворка для крудов на плюсах в 2022?
Если видим новую библиотеку на java, то круто, парни поработали! Видим новую библиотеку на python, отдично, дайте две!!! Видим библиотеку на с++, фуууу, сожгите ее исходники в адском пламени! Как-то так? С++ популярный язык программирования, открыли код интересной библиотеки. Спасибо авторам. Разработчики, которые пишут на с++ будут использовать, остальные пройдут мимо.
Где бы еще взять c++ разрабов…
А акторы и стриминг будут? Как в dapr или akka?
Если он подходит под ваши нужды - то почему бы не использовать. Нам не подошёл по ряду причин :(
В то время был vendor lock на технологию - страшненько писать код на платформе, которую контролирует одна корпорация, с не самой хорошей репутацией.
Для ряда задач очень мешает GC, сталкивались на проде с проблемами.
Большая кодовая база на C++ и штат С++ специалистов подталкивают к использованию этого языка, как и некоторые CPU ресурсоёмкие задачи.
Не поймите неправильно, я ценю вклад Яндекса в оупен сорс, в частности и кликхаус, и юсервер, и вообще последние шаги в этой сфере радуют.
Но вы вы пишете, что не самая хорошая репутация микрософта помешала воспользоваться его фреймворком. А решение принималось, судя по всему, во времена Яндекс защитника и Яндекс бара. "И эти люди запрещают мне ковырять в носу"
Недавно еще ydb заопенсорсили
Еще из значительного натренированную сетку со 100 миллиардами параметров выкладывали. Я посмотрел гитхаб Яндекса, там более ста репозиториев. Некоторая часть - клиенты API их сервисов или SDK для работы с устройствами, но есть и значительное количество универсальных решений.
Такой подход современного Яндекса я только приветствую.
Зачем яндексу какие-то решения от Майксрософта, если Яндекс сам обладает интеллектуальными ресурсами, сравнимыми с Майкрософтом (а может и превосходящими его), и может при желании реализовать что угодно in-house, хоть операционку свою создать, если это зачем-то будет нужно.
Речь, вероятно, о не самой хорошей репутации внезапно прекращающих развивать свои старые технологии в пользу более модных. Это имеет значение при выборе платформы, а не отношение пользователей к MS.
А как насчет GoLang? Мне кажется производительность его не хуже плюсовых на задачах связанные с бэкендом, а на выходе выйдет более симпатичный код. Было бы не плохо услышать, до userver на чем был написан backend в командах.
Блин, что с хабром? Не комментарии, а белки_у_дерева.jpg
Как вышло, что C++ и 2022 год оказались в один момент в одной Вселенной? А как же Rust? У него же binding.
blocking_task_processor — name of task processor for background blocking operations
Подскажите, пожалуйста, про какие блокирующие операци тут идет речь (это документа из раздела про PostgreSQL)?
Сам на С++ не пишу, но хочется понять, как реализован драйвер для PG, чтобы сравнивить с java-подходами.
Подскажите, пожалуйста, про какие блокирующие операци тут идет речь
В самом начале подробно объясняется про coroutines: https://userver.tech/d6/d76/md_en_userver_intro_io_bound_coro.html , и блокирующие операции это соотвествено те которые блокируют поток выполнения ОС.
Судя по коду, i/o там асинхронное, но используемая библиотека может "за кадром" блокирующе читать такие файлы как /etc/hosts или там /tmp/krb5cc*.
Блин. Спасибо за поправку. А то я уже честно поверил, что кодогенератор воспринимает коммент с ракетой как await. )))
Расскажите уже тогда, как реализована асинхронность — это поинтереснее крудов ) что там внутри? И в C++ же есть корутины, почему их было не заюзать?
Антон уже делал доклады на эту тему на конфах. Например вот
Насколько я всё понял. Асинхронность реализована через boost::context, это stackfull-корутины. В С++ же stackless-корутины, которые везде мусорят новыми ключевыми словами, и не дают возможности один и тот же код использовать как в обычном тредовом контексте, так и в корутиновом.
По сути, для stackless-корутин требовалась именно такая поддержка языка, а stackfull можно уже было сделать давно (boost::coroutines и boost::asio). При этом выбор всегда за разработчиком (я лично только за stackfull, потому что с ними можно иметь единый код для очень разных режимов работы). Userver - это очень промышленная библиотека stackfull-корутин (в отличие от академического boost), в которой отработаны и удобрены нужными инструментами все самые частые и полезные юзкейсы.
В статье просто пример, или вы так и пишите — голый запрос в БД напрямую в контроллере?
Именно так мы и пишем. Фреймворк проверит количество аргументов в вашем запросе и количество переданных параметров, превратит запрос в prepared statement... И когда выполнение дойдёт до строчки с запросом, по сети полетит идентификатор prepared statement и параметры в бинарном виде (не в текстовом как это делает libpq).
Есть ещё конечно ORM, но это отдельный проект и многие им не пользуются
const char* statement = "SELECT ok, baz FROM some WHERE id = $1 LIMIT 1";
auto row = psql::Execute(trx, statement, request.id)[0]; // ?
if (!row["ok"].As<bool>()) {
Жесть какая, куча лишних buzzword и синтакического мусора. Не лучше ли было сделать транслятор с Python/php ?
Блин, как обидно-то!
Такая классная статья и комменты, а я почти нифига не понимаю(( Уже одно это мотивирует учить языки и матчасть.
Супер. А по асинхронному клиенту Kafka и асинхронному File IO есть какие-то планы? За WebSocket я уже проголосовал в issue на github.
В какой-то момент разработчики столкнулись с проблемой, что быстрый рост популярности Лавки привёл к непропорционально большому росту нагрузки на сервисы. Назрела необходимость переносить их на более эффективный язык программирования.
Вот это в принципе звучит диковато. Хочется думать о хорошем и предположить, что сначала устранили все неэффективности в существующем решении, оценили какой прирост производительности принесет переписывание (да на самом деле с чего угодно) на с++ и только потом переписывали, а не "стало медленно, айда перепишем".
Но. Профиль объем нагрузки лавки можно прикинуть на глаз (она не то, чтоб прям огромная). Более того, у одного конкурента лавки с большей нагрузкой никаким с++ и не пахнет, тем не менее он живет и чувствует себя очень хорошо.
Внимание вопрос, а как-то оценивалось какой прирост производительности был получен, а главное какой ценой, насколько возросла стоимость поддержки и развития.
Отдельно в сторону замечу, что аргумент "у нас тут уже есть библиотеки на любой вкус" звучит так себе, например в jvm, python, js мире этих библиотек...
Видимо у технического директора, или как у них он называется, любовь к с++. Программисты хотят программировать свои сложные и большие системы. Руководство с удовольствием платит им за это. Даже для сообщества получился профит.
А то что это успешно делается всеми без с++ дело третьестепенное.
Вдруг через 10 лет это будет крутиться на байкалах. Тогда вылезет весь профит в своих реализациях всего туллинга и даже каких-то инфраструктурных блоков.
Почему не на Golang пишите эти сервисы?
Антон, спасибо за статью и новую классную библиотеку.
Когда-то Хабр был просто нереальным кладезем интересных вещей, как и людей. А сейчас я вижу в комментах кучу недопрограммистов, которые вообще ничего не смыслят в программировании, им бы лишь новомодные библиотеки/языки использовать. Куча вопросов : а почему не язык Н? А вы, товарищи, хотя бы подумайте о том, зачем использовать ваш язык, если есть C++, есть программисты, которые лучше знают этот язык, он удобен и эффективен. Подумали теперь? Все еще нет? Тогда удосужьтесь, хотя бы, написать в чем удобство предлагаемого языка, желательно со сравнением времени time-to-market и производительности в любых задачах, которые не только предполагают складывать 2 числа.
он удобен и эффективен
Если бы это было правдой, то до сих пор был бы такой набор языков:
Fortran, Lisp, Cobol, Basic, Pascal, C++, Smalltalk, Ada.
Последующие языки появились как раз из-за наличия в вышеперечисленных неудобств и неэффективностей. Подумайте об этом. Зачем вам новомодный C++, когда есть проверенный временем Fortran?
Иногда попадаются люди, которые умеют думать, деньги считать, проектировать - у них и фортран, и С, и другие паскали уживаются с растами, питонами, явами :)
А я и не говорил, что другие языки неудобные и неэффективные. Просто почему-то многие думают, что
а) вот так вот легко взять, и перейти на другой ЯП
б) не приводят никаких аргументов ЗА
в) думают, что на С++ ОЧЕНЬ сложно писать, хотя сами его в глаза не видели
И так сложилось, что в яндексе, да и в некоторых других компаниях есть люди, которые знают С++ лучше, чем другие языки, которые тоже могут подходить под данные задачи. И по опыту, если посадить плюсовика писать код на той же Java (хотя этот язык без хаков не подходит под данные задачи, как было описано в статье), то он все равно будет писать по плюсовому, и пройдет неизвестно сколько месяцев-лет, пока он не "перестроится".
Ну, вы как-то странно сначала назвали всех, кто выбирает не C++ недопрограммистами, а потом C++ программистов выставляете какими-то тугоумами, которым тяжело другой язык освоить.
В моём понимании Senior Software Engineer должен нормально владеть хотя бы 5 языками программирования, а шапочно знаком быть ещё с большим кол-вом. Иначе он тупо не сможет выбирать стек, наиболее подходящий под задачу и будет как в анекдоте микроскопом гвозди заколачивать, а значит и лычку Senior не заслуживает. Поэтому по первому вопросу - да, я считаю, что сеньору легко взять и перейти на другой язык.
Что касается аргументов "ЗА", они зависят от конкретной ситуации. В подавляющем большинстве веб-проектов большая часть времени уходит на IO - работу с СУБД, файлами, внешними сервисами и т.д. Поэтому разумнее для большинства проектов выбирать те языки, на которых проще описывать бизнес-логику с минимальным кол-вом синтаксического шума.
С++ имеет смысл рассмотреть для отдельных сервисов в проектах с целевой нагрузкой более 10k rps.
И да, на нём действительно сложно писать. Я вполне осознанно его забросил, потому что мне не нравится отвлекаться на ручное управление памятью и помнить 100500 случаев, когда возможно UB. Это создаёт когнитивную нагрузку, которая сильно отвлекает вас от основной логики проекта, замечаете вы это или нет.
Когда стоит цель выжать из имеющейся железки максимум, например, при написании AAA-игры, этот tradeoff оправдан. Но когда вы за все ваши неудобства получите +5% или, если повезёт, +10% к производительности вашего веб-приложения (а на приложениях с нагрузками порядка 100-1000 rps так и будет по факту), то C++ неудачный выбор.
По-моему, вы утрируете и я такого не писал.
сначала назвали всех, кто выбирает не C++ недопрограммистами
Я такого не говорил. Просто многие пишут о C++ и <своем любимом ЯП, который отлично подходит под данную задачу> без аргументов, да иногда еще не прочитав статью полностью. Вообще, странно писать что-то в статье про библиотеку, написанную на C++ , не зная C++ на хоть каком-то уровне.
а потом C++ программистов выставляете какими-то тугоумами, которым тяжело другой язык освоить.
Опять же, я такого не говорил. Я считаю, что если взять программиста, который лет 5, или может 10, писал в основном на C++, и пересадить его на Java, то в 90% случаев он будет писать так, как привык на C++, особенно если учесть, что синтаксис очень похож. И пройдет какое-то время, пока он освоится. А если посадить целый отдел, который писал на C++, писать на Java, то тут может ничего хорошего не выйти, в любом случае нужна подготовка и/или помощь более опытных в этом ЯП коллег.
Поэтому по первому вопросу - да, я считаю, что сеньору легко взять и перейти на другой язык.
Это не вопрос, и речь не про инженера, а про компанию, где миллионы строк кода написаны на <ЯП X>.
Что касается аргументов "ЗА", они зависят от конкретной ситуации.
Почему же тут каждый второй пишет : а почему вы не использовали ЯП X, хотя в статье явно указаны проблемы некоторых ЯП, с которыми не хотелось мириться? В моем понимании, такие люди свой ЯП то до конца не изучили (хотя бы на 50%, до конца навряд ли хоть кто-то знает какой-нибудь ЯП).
С++ имеет смысл рассмотреть для отдельных сервисов в проектах с целевой нагрузкой более 10k rps.
Если мы говорим именно про сервисы и компания, которая делает что-то новое, без собственной кодовой базы, то вероятно, это так.
И да, на нём действительно сложно писать. Я вполне осознанно его забросил, потому что мне не нравится отвлекаться на ручное управление памятью и помнить 100500 случаев, когда возможно UB.
Сложно возразить без примеров. На C++ не так сложно писать, как лет 10 назад.
Ok, думаю, теперь лучше стало понятно, что вы имели в виду. Призывы переводить компанию, которая уже пишет на языке X и имеет большой штат программистов им владеющих, на какой-то другой ЯП действительно выглядят весьма странно.
На C++ не так сложно писать, как лет 10 назад.
Ну, может, как-нибудь загляну поизучать современный C++. Пока меня Rust устраивает в качестве альтернативы. Но допускаю, что и в C++ действительно стало сильно лучше, чем было. С годами вы почти угадали, наверно даже на пару лет больше, чем 10, уже прошло))
В моём понимании Senior Software Engineer должен нормально владеть хотя бы 5 языками программирования
У меня, наверное, слишком завышенные требования к понятию "владеть", поэтому не очень понимаю о чем вы. Могли бы вы привести список из 5 языков для примера?
Очевидно же: HTML, CSS, SQL, JS, что-то для бэка.
Ну, к примеру: Ruby, Elixir, Rust, JavaScript, C#
Как тут уже написали, SQL тоже можно посчитать, хотя вряд ли кто сейчас активно хранимки на нём пишет. А чисто запросы, наверно, на полноценный ЯП не тянут. HTML и CSS, пожалуй, тоже не стоит в этот список включать))
А вообще, конкретный набор не столь важен. Важно, чтобы они были разноплановые, в разных парадигмах. Потому что переключаться между языками в рамках одной парадигмы - это вообще дело техники.
P.S. Термин "владеть" для простоты определим как "мочь решать задачи бизнеса при помощи данного ЯП". Какого-то супер-пупер олимпиадного уровня знаний каждого закоулочка стандартной библиотеки и всей экосистемы я не вкладывал в этот термин.
Ну, вы как-то странно сначала назвали всех, кто выбирает не C++ недопрограммистами
Он не говорил же такого. Зачем так передергивать?
Просто поражает то, что больше 50% комментариев к статье крутится вокруг фразы типа: "Зачем писать на с++, если есть мой любимый язык <youFavoriteLang>? Для него же есть прекрасный <youFavoriteFramework>. И на с++ так не удобно следить за памятью и нужно бороться с утечками памяти."
1) предлагаю задуматься над вопросом, м.б. вы пишите на python/java/go и т.п. просто потому, что для них уже есть в доступе flask/django/spring и т.д.? И дело только в том, что они в открытом доступе и на хайпе? И теперь у них есть еще один хороший конкурент?
2) в с++ уже давно есть умные указатели и ключевое слово auto. И если бы при использовании других языков память не текла, то на хабре не было статей (не обсуждаю хорошие они или не очень, они просто есть):
течет питон https://habr.com/ru/company/otus/blog/448474/
течет питон https://habr.com/ru/company/domclick/blog/532030/
течет java https://habr.com/ru/post/132500/
течет го https://habr.com/ru/company/ncloudtech/blog/675390/
течет c# https://habr.com/ru/company/ncloudtech/blog/675390/
Резюмирую: с++ это один из популярных языков, и появление в открытом доступе нового фреймворка для него - это хорошо (вангую, мы еще увидим его биндинги для питон и java) память течет везде, если за этим не следить. Спасибо авторам за появление еще одного фреймворка для веба)
У вас для C# и Go одна и та же ссылка почему-то
У вас для c# и Go одна и та же ссылка почему-то
Cпасибо, течет с# https://habr.com/ru/company/otus/blog/536942/
Боже. Мои глаза!
Голые sql запросы в 2022 году. А если схема БД поменяется? Будете руками в 1000 мест править?
Как у вас с обработкой ошибок? Умеем корректно отменять иерархию корутин, при возникновении исключения? Исключения поддерживаются? Бизнес ошибки же надо как-то передавать . . .
Вот истину говорят. Пока Java программисты делают успешные проекты и считают кэш $$, C++ мастера пишут свой класс строки в 10 раз. И он будет уж точно самым быстрым!
Как у вас с обработкой ошибок? Умеем корректно отменять иерархию корутин, при возникновении исключения? Исключения поддерживаются? Бизнес ошибки же надо как-то передавать . . .
Всё хорошо, исключения работают из коробки, иерархии корутин автоматически отменяются м все деструкторы отрабатывают (RAII разумеется работает).
Пока Java программисты делают успешные проекты...
Наверное поэтому ПО для банковских терминалов, медицинского оборудования, самолётов, космических аппаратов и автомобилей, сапр написано на C++. Как кстати и userspace некоторых ОС, браузеры, игровые движки, интернет поисковики, таксишные и другие агрегаторы, рендеры для мультиков и блокбастеров, фотошопы и 3d моделирование, видеообработка, машинное обучение, распознавание образов, рассчёты для CERN и всякие поиски бозонов, химические и геодезическое ПО, компиляторы для вашей любимой Java, да и вообще большинство компиляторов, трансляторов и jit...
Если вы не сталкивались с успешной разработкой на C++, то посмотрите например туториалы и исходники того же userver. Откройте для себя современный C++, а не то `char* str = malloc(10);` подобное безобразие, что многие видели в бездарных учебниках начала века.
Антон в одном из ваших выступлений, вы говорили, что используя самописный LRU получилось сэкономить 250 ядер. У вас есть инфа, сколько получилось сэкономить мощностей заюзав userver в проде?
Соптимизированный LRU как раз является частью userver https://userver.tech/d5/d9c/classcache_1_1LruSet.html
Так что сэкономили минимум 250 ядер :) Увы, более точные замеры сделать проблематично, но постараемся что-то придумать к релизу
codegen планируется выпускать в опенсорс? Ну пожалуйста :)
Венгерская нотация?? Вы серьезно!??
Яндекс выложил в опенсорс бету фреймворка userver