Смешно. Масштабы Яндекса несравнимы например с масштабами Walmart, а там активно пользуются стандартными кубами, кафками и докерами.
Walmart может себе такое позволить. Закупки серверов это заметная часть CapEx'а Яндекса. Очень много человеко-лет закопаны в то, чтобы оптимально утилизировать оборудование. Плюс Яндекс технологическая компания, её ценность — в технологиях. Многие «велосипеды» либо в целом лучше, чем открытые аналоги и создают конкурентное преимущество, либо появились раньше, либо решают слишком специфические задачи. Там где можно переходить на стандартные технологии — переходят.
Года три назад уже почти была. Ну т.е. технологически была монорепа, но конечно туда далеко не все переехали и в масштабе Microsoft ещё долго не переедут.
Ну как слабо представляю. Я как раз такой сервис разрабатываю. Слепок одного шарда продакшен данных занимает почти целиком сервер с 256 Гб. Конечно мы умеем делать миниатюрную копию такого шарда с искуственными данными, но достаточно часто требуется именно полноценная версия. На ноутбуке это провернуть невозможно.
Я некоторое время участвовал в разработке одного сервиса-сателлита MS SQL и там вся разработка велась на рабочей станции, естественно под Windows. Мне не понравилось. MSFT не экономит на оборудовании, но если у клиентов характерные размеры баз по 50-1000Гб, а у тебя десктоп с 32Гб RAM, то это создаёт неудобства. Всё равно приходилось пользоваться виртуалками, только ещё и с RDP вместо консоли. Ну и скорость компиляции (если нужно локально собрать) оставляла желать лучшего.
Код ведь приходится не только писать, но ещё и читать и дописывать. К сожалению, красиво всё документировать слишком дорого и долго, поэтому часто надо уметь прямо по коду быстро понять что здесь происходит, зачем именно так и какие инварианты важно сохранить при правках. Ну и именно в Яндексе достаточно мест, где действительно меньше бизнес-логики на if-else'ах и больше обходов графов.
В целом на собеседованиях именно в Яндекс спрашивают очень простые задачи. Их смысл не в том чтобы проверить знание хитрых алгоритмов, а просто убедиться, что соискатель умеет писать код и не путаться в трёх итераторах.
Запускать и отлаживать локально программу, которая в продакшене работает на серверах с 56\80 ядрами и 256\512 Гб памяти конечно можно (в каком-нибудь усечённом варианте), но очень не удобно.
Там кажется компилятор слишком вольно реализуют aggregate initialization, если явно задать конструктор, то деструктор у lock'а зовётся там где ожидается. В целом да, выглядит как баг в gcc. AFAIK, в gcc про это (evaluation order и т.д.) достаточно багов было.
Это вроде бы понятная фича языка. Если конструктор объекта не завершился, а был прерван exception'ом, то деструктор не позовётся. Как можно сделать иначе? При этом все деструкторы для уже сконструированных объектов будут вызваны. В чём тут проблема?
Walmart может себе такое позволить. Закупки серверов это заметная часть CapEx'а Яндекса. Очень много человеко-лет закопаны в то, чтобы оптимально утилизировать оборудование. Плюс Яндекс технологическая компания, её ценность — в технологиях. Многие «велосипеды» либо в целом лучше, чем открытые аналоги и создают конкурентное преимущество, либо появились раньше, либо решают слишком специфические задачи. Там где можно переходить на стандартные технологии — переходят.
Я некоторое время участвовал в разработке одного сервиса-сателлита MS SQL и там вся разработка велась на рабочей станции, естественно под Windows. Мне не понравилось. MSFT не экономит на оборудовании, но если у клиентов характерные размеры баз по 50-1000Гб, а у тебя десктоп с 32Гб RAM, то это создаёт неудобства. Всё равно приходилось пользоваться виртуалками, только ещё и с RDP вместо консоли. Ну и скорость компиляции (если нужно локально собрать) оставляла желать лучшего.
В целом на собеседованиях именно в Яндекс спрашивают очень простые задачи. Их смысл не в том чтобы проверить знание хитрых алгоритмов, а просто убедиться, что соискатель умеет писать код и не путаться в трёх итераторах.