Речь про вот этот пост: Rewriting the heart of our sync engine. Dropbox переписал часть своей системы, отвечающей за синхронизацию, с Python-а на Rust и выкатил на публику победную реляцию об этом достижении.
Вот казалось бы, имей голову на плечах и напиши все сразу на C++... И работало бы это все годами.
Не нравится C++, а Rust-а еще нет не свете? Но ведь есть Ada, есть Eiffel...
Но нет. Сперва нужно написать на Python.
Поиметь в результате этого кучу геморроя. Убить уйму сил и времени в попытках привести чудо сие в норму.
А потом выбросить результаты всех трудов на помоечку (с) и с криками восторга и другими проявлениями щенячей радости переписать все на Rust.
Ну и для тех, кто типа умеет читать между строк: это пост не про то, что C++ хорош, а Rust плох. Rust хорош. И для подобных задач его выбор ничуть не хуже, а может и лучше, чем выбор C++. Он про то, что выбор по принципу "пользуем то, на что надрачиваем, а ничего другого просто не знаем", в конце-концов приводит к потере времени и денег.
Да и еще не могу удержаться и не пройтись по любимой теме:
Almost all of our code runs on a single thread (the “Control thread”) and uses Rust’s futures library for scheduling many concurrent actions on this single thread. We offload work to other threads only as needed: network IO to an event loop, computationally expensive work like hashing to a thread pool, and filesystem IO to a dedicated thread. This drastically reduces the scope and complexity developers must consider when adding new features.
Это как раз то, что SObjectizer умеет делать с самого начала: распределять работу между сущностями, каждая из которых работает на нужной ей контексте. Хоть на общей рабочей нити, хоть на пуле потоков, хоть на выделенной отдельной рабочей нити. Собственно, для этого SObjectizer и создавался много лет назад.
4 комментария:
Главное, как в Google, периодически всё переписывать (и не столь уж важно - менять при этом язык или оставлять прежний). Так новый народ лучше вникнет в детали имплементации
Если бы они изначально взяли какой-нибудь другой язык программирования, то, возможно, не успели бы вовремя занять нишу на рынке. Питон позволяет очень быстро набрасать код, который сразу начнёт работать. Ну, а в том, что прототип оказывается в продакшене, программисты, как правило, не виноваты.
@Unknown
Скопирую сюда часть комментария из обсуждения этой же темы в FB:
Более того, я сам советую первую (proof-of-concept) версию делать на том языке/технологии, которой разработчики владеют лучше всего. Чтобы сконцентрироваться на достижении цели, а не на осваивании инструментов для этого.
Тут другой аспект важен: сколько должно пройти времени и сколько должно быть вложено ресурсов в поддержание первой версии, эволюционным образом выросшей из прототипа, прежде чем решиться на big rewriting?
Вот в dropbox продолжали вбухивать средства в Python-овый sync engine classic в течении лет 7-8. Хотя, полагаю, надобность в переписывании стала маячить на горизонте где-то после 2-3 лет эксплуатации.
Но это же район 2010-2011 годов. Волшебной пилюли под названием Rust у них еще не было. Ну не могли же они C++, Ada и Eiffel выбрать, в самом-то деле.
У них и на server-side изначально Python использовался. А когда они Python-а наелись, то перешли на Go и в течении короткого времени наклепали более 1MLOC кода на Go (предположу, что приблизительно столько же Python-овского кода было выброшено). Хотя, если бы они начали делать server-side на Java (или начали использовать Java после того, как их первый прототип на Python-е взлетел), то может быть и не пришлось бы менять 1MLOC на Python-е на 1MLOC на Go.
Понятно, что история не знает сослагательного наклонения, но есть очень сильное ощущение, что люди упорно пытаются использовать только свои любимые игрушки вместо того, что оглядываться по сторонам и пробовать немодные, но работающие альтернативы.
Тот же GitHub нарисовали на Ruby on Rail, и народ им начал пользоваться, невзирая на столь странный выбор (интерпретатор языка плюс HTML-шаблонизатор в стиле раннего PHP). Поэтому пусть их развлекаются. Тем более что HighLoad всё расставляет по местам: если тут у авторов узкое место, оно будет оставаться узким, пока не перепишешь по-иному. А если упёрся в границы данного языка - перепишешь на другом.
Отправить комментарий