Довольно интересная новость от Dropbox, которые переписали свое хранилище с Go на Rust в целях оптимизации. Что показательно, не с Go на C++, а на Rust, что мне видится очень логичным и правильным ходом. Так что всех поздравляю, в полку серьезных решений написанных на Rust, к довольно долго одиноко там стоявшему Servo добавилось еще одно не менее сложное решение
Здравствуйте, kaa.python, Вы писали:
KP>Что показательно, не с Go на C++, а на Rust, что мне видится очень логичным и правильным ходом.
Давай подождём ещё немного.
Здравствуйте, Kernan, Вы писали:
KP>>Что показательно, не с Go на C++, а на Rust, что мне видится очень логичным и правильным ходом. K>Давай подождём ещё немного.
Ну давай подождем, а то я уже начал лопату расчехлять
Ответы разработчиков Dropbox про использование Rust.
Из показавшегося интересным мне:
> Are you happy using rust ?
Yes, overall the team has been very pleased with it. Compile times are the only serious complaint.
> How many lines of rust code are you using in production ?
About 60k of our own, about 300k incl crates.
> Are you using nightly? or just stable version of rust?
We're pinned to a particular nightly right now, as we rely on a fair amount of features that are still stabilizing. I imagine we'll be on a stable by this summer.
KP>Ответы разработчиков Dropbox про использование Rust.
Well, we basically needed C++, but:
Dropbox doesn't have a strong C++ ecosystem on the backend, and it takes a lot of work to build one.
Given (1), we had basically a blank slate, and our team is C++ and Haskell type folks, we decided to use Rust so we could get C++ with better type safety and fewer sharp corners.
So realistically, if we had been at a place with an awesome preexisting set of C++ libraries, practices, etc, we probably never would have used Rust.
At Dropbox we’ve spent the last year and a half building two cross platform mobile apps: the email client, Mailbox, and the photo gallery, Carousel. We started with the goal of a native look and feel with seamless performance but also needed to leverage a small team to build these apps on multiple platforms. We ultimately accomplished this by using C++ to share significant amounts of code in each app.
We’ll cover what portions of our apps we built in C++ and why we left some portions in the platform languages of Java and Objective-C, deep diving into some of the most important components. We’ll also discuss some unexpected benefits, areas we faced technical and human challenges, and some tips and tricks that you can use to leverage C++ to build very high performance apps.
EP>So realistically, if we had been at a place with an awesome preexisting set of C++ libraries, practices, etc, we probably never would have used Rust.
Всё верно, инфраструктуры не было ни для C++, ни для Rust. Выбрали C++? Но в принципе я согласен, пока что, от этого чудища (я о плюсах) довольно сложно отказаться, кто бы спорил. Но при том, каким сложным он становится и как быстро и хорошо развивается Rust, я полагаю, этот момент не за горами.
К примеру у нас в компании все больше и больше команд (включая нашу) отказывается от C++ в пользу чего-либо ещё.
Здравствуйте, kaa.python, Вы писали:
KP>К примеру у нас в компании все больше и больше команд (включая нашу) отказывается от C++ в пользу чего-либо ещё.
если не секрет в чем проблеммы с С++
и ведь необязательно использовать последний стандарт
Здравствуйте, kaa.python, Вы писали:
KP>Всё верно, инфраструктуры не было ни для C++, ни для Rust. Выбрали C++?
Может для Rust уже были необходимые библиотеки, по его словам не ясно
KP>К примеру у нас в компании все больше и больше команд (включая нашу) отказывается от C++ в пользу чего-либо ещё.
У нас основные неудобства от C++ это сборка и поддержка всех сторонних зависимостей под все три OS в нескольких конфигурациях. Но всё то же самое будет справедливо для любого другого native языка, да и не native тоже, ибо все эти зависимости именно native и без аналогов.
Проблемы которые решает borrow checker — это мизер, который мог бы сыграть роль только при прочих сферических равных. Возможно в других проектах как-то по-другому
По алгоритмической выразительности среди мэйнстрима C++ сейчас впереди всех.
Для сравнения C#, свежий пример
— на C++ десять строк (+ может несколько wrapper'ов, это максимум десятки строк), на C# — несколько сотен строк кода (1 + 2) причём включая кодогенетратор, который генерирует несколько тысяч строк, а алгоритм-то совсем пустяковый.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Может для Rust уже были необходимые библиотеки, по его словам не ясно
Да вроде всё очевидно, у Rust вообще мало что есть. Он же младенец
EP>У нас основные неудобства от C++ это сборка и поддержка всех сторонних зависимостей под все три OS в нескольких конфигурациях.
В Rust это решено довольно хорошо.
EP>Но всё то же самое будет справедливо для любого другого native языка, да и не native тоже, ибо все эти зависимости именно native и без аналогов.
Как я уже ответил sergey2b, проблема C++ в другом. Он очень очень сложный и подобрать команду, которая будет его хорошо знать требует невероятных усилий и далеко не все могут себе это позволить. Даже Гугл не может, чему Go отличное подтверждение.
EP>Проблемы которые решает borrow checker — это мизер, который мог бы сыграть роль только при прочих сферических равных. Возможно в других проектах как-то по-другому
Да не в этом проблема. Мы сейчас, к примеру, заменили C++ на Go в одном проекте. Просто тупо потому, что в Go почти ничего нельзя и написать на нем адов код сложно. При этом все необходимые базовые вещи есть.
EP>По алгоритмической выразительности среди мэйнстрима C++ сейчас впереди всех.
Да, верно. Но мы опять вернемся к вопросу цены всей этой радости и возможности набора большой команды способной это вытянуть. Я на C++ уже лет 15 и врятли буду с него уходить. Но все же отдаю себе отчет в том, что в большинстве случаев он просто неподъемно сложен для больших команд.
Здравствуйте, kaa.python, Вы писали:
S>>если не секрет в чем проблеммы с С++ S>>и ведь необязательно использовать последний стандарт
KP>Проблем в C++ нет. Проблемы в людях которые на нем пишут есть. Слишком часто хочется смотря на результат "обнять и плакать".
В инструментах проблем никогда не бывает. Проблема всегда исключительно с людьми, которые пытаются использовать инструменты. Других вариантов просто нет.
Здравствуйте, kaa.python, Вы писали:
KP>Довольно интересная новость от Dropbox, которые переписали свое хранилище с Go на Rust в целях оптимизации. Что показательно, не с Go на C++, а на Rust, что мне видится очень логичным и правильным ходом. Так что всех поздравляю, в полку серьезных решений написанных на Rust, к довольно долго одиноко там стоявшему Servo добавилось еще одно не менее сложное решение
Интересно, что их прижала не производительность CPU, а проблемы с памятью.
В принципе, если в языках со сборкой мусора писать в стиле
for (;;) {
rq = new Request();
rq.ReadFromNetrowk();
rq.Process();
rq.SendReply();
}
то эти самые rq будут накапливаться, как сумасшедшие, пока сборщик мусора до них не доберется. В Go, к тому же, довольно наивный escape analyser (штука, которая пытается понять, переживает ли объект выход из блока, в котором он создан с целью решить, создавать его в куче или на стеке), поэтому даже невинная декларация локальной переменной может обернуться тем, что переменная фактически будет создаваться в куче.
Но тем не менее, я почти уверен, что в их случае можно было бы обойтись переписыванием критического участка кода, без необходимости переписывать все подряд.
Здравствуйте, Pzz, Вы писали:
Pzz>Интересно, что их прижала не производительность CPU, а проблемы с памятью.
Да, это мне тоже кажется немного странным. Мы тут недавно общались с CloudFlare и по их утверждениям, на Go только DNS-сервер не вышел, ну, вернее вышел, но получился тормозной малек. А вот как и почему вылезли проблемы с памятью
Pzz>Но тем не менее, я почти уверен, что в их случае можно было бы обойтись переписыванием критического участка кода, без необходимости переписывать все подряд.
Согласен, уход с Go на мой взгляд немного странно выглядит, все же этот язык именно под сервисы и сети реально заточен. Ну, в любом случае Ave, Rust!
Здравствуйте, kaa.python, Вы писали:
KP>Довольно интересная новость от Dropbox, которые переписали свое хранилище с Go на Rust в целях оптимизации. Что показательно, не с Go на C++, а на Rust, что мне видится очень логичным и правильным ходом. Так что всех поздравляю, в полку серьезных решений написанных на Rust, к довольно долго одиноко там стоявшему Servo добавилось еще одно не менее сложное решение
вспомнилось
А теперь давай посмотрим на эту ситуацию с другой стороны. На эту/эти вакансии в ДБ так же придется сдавать зачет по алгоритмам, сортировать гномиков и заниматься другой аналогичной гомосятиной. Но, до кучи, тебе еще устроят зачет по Rust! Это реально возможность, факт
Ты, похоже что, не понимаешь самого главного. Важен не инструмент, супер языка не было и пока не предвидится. А вот предметные области были, есть и будут.
Только тут о другом. Haskell никогда и ничего не заменит, это был, есть и будет язык для энтузиастов. Rust – может основательно потеснить C++ в тех областях где C++ пока еще силен. И эта тенденция видна.
Здравствуйте, kaa.python, Вы писали:
KP>Как я уже ответил sergey2b, проблема C++ в другом. Он очень очень сложный и подобрать команду, которая будет его хорошо знать требует невероятных усилий и далеко не все могут себе это позволить. Даже Гугл не может, чему Go отличное подтверждение.
Go — да, но не Rust. Есть мнение, что зоопарк указателей в Rust (и преобразований оных) сравним по сложности с С++. И что если у тебя нет команды из людей, разбирающихся в хитросплетениях модели памяти Rust-а, то народ просто перейдет на повсеместное unsafe и на выходе ты получишь тот же овнокод, только вид сбоку.
Здравствуйте, jazzer, Вы писали:
J>Go — да, но не Rust. Есть мнение, что зоопарк указателей в Rust (и преобразований оных) сравним по сложности с С++. И что если у тебя нет команды из людей, разбирающихся в хитросплетениях модели памяти Rust-а, то народ просто перейдет на повсеместное unsafe и на выходе ты получишь тот же овнокод, только вид сбоку.
Не, ну это разрулить элементарно. Добавляешь в твой любимый CI сервер правило – нашли блок unsafe == сборка провалилась и проблема решена
