понедельник, 19 августа 2019 г.

[prog.flame.c++] Dropbox выставляет свою Djinni на мороз

Кстати говоря, в делах и заботах упустил из виду вот эту публикацию: (Не очень) скрытые издержки общей кодовой базы iOS и Android

Между тем штука значимая.

Я вот несколько лет то тут, то там рассказываю про такую область применения C++, как написание "ядра" кросс-платформенных приложений. Типа того, что бизнес-логика пишется на плюсах, а GUI и какие-то штуки по интеграции с системно-зависимыми сервисами на родных для платформы языках (вроде Java на Android-е, Objective-C/Swift на iOS, C++ или .NET на Windows).

И в качестве примера приводил разработку Djinni от Dropbox-а.

А вот, оказалось, что Dropbox такой подход к кроссплатформенности запарил и они от него отказались.

В статье, однако, как мне показалось, внятно сформулирован только один раздел, под названием "Оверхед на найм, обучение и удержание разработчиков". Тут как раз ничего вопросов не вызывает. Сперва была хорошая команда толковых C++ников, которые этот подход опробовали и продвинули внутри компании. А потом разошлись кто куда. И заменить их не кем. Поэтому продолжать писать на C++ с должным уровнем качества уже некому.

Остальные же причины, в частности, про оверхед пользовательских фреймворков и библиотек, вызывают недоумение. Никто не заставлял Dropbox делать свою собственную библиотеку для работы с Json в С++. Очень похоже на NIH-синдром и его последствия.

Так что, с одной стороны, конечно, печалька. С другой -- лишнее подтверждение тому, что C++ все-таки больше инфраструктурный язык, писать на нем бизнес-логику, конечно, можно. Но дорого.

1 комментарий:

Alex комментирует...

Интересно что мой вывод из статьи про дроп бокс был такой же
Достаточно давно в теме (15 лет в с++) много собеседовал людей в разных странах. действительно, найти хорошего с++-ника - большая проблема, особенно в странах где с++ не так распространен. Соотвестственно привлечь крутого спеца на поддержку и развитие специфического кастомного фреймворка с не слишком востребованным технологическим стеком и не очень модным продуктом - сложная (если выполнимая)задача.
Как вариант решения - перенос разработки в БСССР с хорошей ЗП
С другой стороны возникает вопрос: а зачем? Если продукт уже выстрелил и можно разработку просто разделить и не усложнять себе жизнь с с++