Я не знаю ни что такое GLSL, ни над чем вы работаете. Могу сказать, что если вы работаете над чем-то один или маленькой командой - вам точно не нужна монорепа. Вы не получите никакой выгоды от неё.
Речь ведётся о кодовой базе над которой работают ежедневно 100+ человек минимум.
Проблемы начинаются не тогда, когда API расширяется.
Проблемы всегда начинаются тогда, когда API ломается. Этот момент всегда максимально оттягивают, но это всё равно происходит. И вот тогда начинается веселье :)
Проблемы продолжаются тогда, когда в API обнаруживается уязвимость. Монорепа позволяет раскатать гарантированно фикс безопасности по всей кодовой базе за один коммит.
Хуже еще бывает, когда API ломается не по принципу поломки сигнатуры, а по изменению логики в передаваемой через API информации. Например, мы передавали некоторый документ в котором было полюшко quantity и оно означало количество денег в единицах валюты. А потом, по какой-то неведомой причине, quantity стало означать количество денег в тысячах единиц валюты. Например законодательство изменилось или там гиперинфляция случилась. Исправить такое в монорепе - куда проще. Хотя описаные события запускают такие волны говна, что так делают раз в тысячеление, но на масштабах жизни корпораций - это вполне себе возможный сценарий.
P.S.
Немножко проблем случается, когда реализация API под капотом меняется. Высокопроизводительный код (а у Яндекса он явно такой), иногда оч болезненно реагирует на внутренние изменения во внешне одинаковом API. Но это всегда уникальные случаи, тут моно/много-репность на ситуация никак не влияет.
как пакет с аккуратным версионированием по semver.
Если честно, я за всю карьеру не встречал ни одной библиотеки, в которой бы "аккуратно соблюдался semver" на сколько-нибудь долгом промежутке времени. Вот вообще ни одной. Я понимаю, что я один, а библиотек очень много, так что 100% такие существуют, но на деле - всем ваще пофиг.
Что будем делать, когда проекты, от которых мы зависим внезапно начинают использовать две разных схемы версионирования. Вот тут и начинается веселье.
Иначе это дорога в ад
Фраза "Dependency hell" существует не просто так. Разбитие кода на независимые репозитории - это тоже дорога в ад :)
в котором никогда не знаешь что и где тебе какое-либо изменение может сломать.
В том и прикол монорепы. Любое ломающее изменение - сломает тебе весь репозиторий. И ты это заметишь сразу. Из плюсов - ты можешь исправить проблему сразу везде, пускай это и потребует ресурсов. Но точно меньших, чем решать эту проблему силами разных команд 10 раз подряд, да еще и в разные временные интервалы.
Да, особенно удобно это для CI, которому каждый раз надо либо пересобирать и тестировать всю огромную монорепу
Эта проблема решается более продвинутой настройкой CI с анализом списка измененных файлов в коммите, не более. Как я и сказал - для поддержки монорепы в работоспособном состоянии - нужна отдельная команда. Не "группка человек из разных команд", а реально отдельная команда билд-инженеров.
для микросервисной архитектуры, по личному опыту, это боль.
Монорепа/"многорепа" и монолит/микросервис - это проблемы из разных миров, которые между собой мало пересекаются.
- Монорепа/"многорепа" - это способы решения проблемы шаринга кодовой базы между разными продуктами/сервисами
- Монолит/микросервис - это способы решения проблемы взаимодействия разных частей системы между собой.
Я слабо представляю как эти проблемы связаны между собой. Они параллеьны друг другу.
Опять же, надо помнить, что говоря о монорепе положительно, я обычно говорю только в ключе С++ разработки. Потому что в С++ до недавнего времени не было модулей вообще, а нормальных - нет и сегодня, на мой взгляд. И монорепа для С++ решает множество проблем.
Для языков с нормальными модулями и пакетными менеджерами, вероятно, монорепа и правда монструозная ненужная конструкция.
Ну, это даже близко не также. Шерлок холмс делает выводы по одному-двум признакам (и так-то занимается индукцией, но не суть). Что если в распоряжении у ИИ будет, ну скажем, 10000 факторов? С полной или не очень историей. Он сможет извлечь всю информацию из телефона человека, получит всю историю перемещения, переписок, покупок, фотки, и прочее и прочее. За мгновение. У любого человека.
С северной Кореей всё просто. Все граждане северной Кореи считаются гражданами южной, т.к. южная не признает разделения границ. Там у них отлаженная схема уже с беженцами.
У меня больше вопрос, насколько законно лишать гражданства полученного по рождению в принципе.
Вопрос не в том, что там написано, а что в итоге взлетит в массах.
И пока что Carbon выглядит как Kotlin для С++. И мне это нравится. А как выглядит Rust - не уверен. Концептуально Rust классный, я даже когда-то тут сам топил за него а каждом комментарии, но последнее время сомнения меня терзают.
Откуда я знаю, я ещё не заглядывал.
Мне не хватает возможности рисовать ровные линии и стрелки) Например по нажатию shift или отдельной кнопкой на панели.
Ну, например, так можно обозвать рабочие потоки)
У нас с женой было 65% от квартиры, но даже оставшееся - это охренеть сколько миллионов рублей)
Вы видели сколько-нибудь крупный проект у которого не было никаких проблем с архитектурой?
Вы видели хоть один проект, заточенный под реально высокую производительность, в котором вообще не используется грязные хаки?
Вы видели хоть раз кодовую базу для группы (от 5 штук) взаимоинтегрированных продуктов, в которой бы не возникало описываемых мною проблем?
Не, если видели такой и он был на С++ - скажите мне где, я пойду туда работать. На текущий момент я такого единорога не встречал.
Я не знаю ни что такое GLSL, ни над чем вы работаете. Могу сказать, что если вы работаете над чем-то один или маленькой командой - вам точно не нужна монорепа. Вы не получите никакой выгоды от неё.
Речь ведётся о кодовой базе над которой работают ежедневно 100+ человек минимум.
Проблемы начинаются не тогда, когда API расширяется.
Проблемы всегда начинаются тогда, когда API ломается. Этот момент всегда максимально оттягивают, но это всё равно происходит. И вот тогда начинается веселье :)
Проблемы продолжаются тогда, когда в API обнаруживается уязвимость. Монорепа позволяет раскатать гарантированно фикс безопасности по всей кодовой базе за один коммит.
Хуже еще бывает, когда API ломается не по принципу поломки сигнатуры, а по изменению логики в передаваемой через API информации. Например, мы передавали некоторый документ в котором было полюшко quantity и оно означало количество денег в единицах валюты. А потом, по какой-то неведомой причине, quantity стало означать количество денег в тысячах единиц валюты. Например законодательство изменилось или там гиперинфляция случилась. Исправить такое в монорепе - куда проще. Хотя описаные события запускают такие волны говна, что так делают раз в тысячеление, но на масштабах жизни корпораций - это вполне себе возможный сценарий.
P.S.
Немножко проблем случается, когда реализация API под капотом меняется. Высокопроизводительный код (а у Яндекса он явно такой), иногда оч болезненно реагирует на внутренние изменения во внешне одинаковом API. Но это всегда уникальные случаи, тут моно/много-репность на ситуация никак не влияет.
Если честно, я за всю карьеру не встречал ни одной библиотеки, в которой бы "аккуратно соблюдался semver" на сколько-нибудь долгом промежутке времени. Вот вообще ни одной. Я понимаю, что я один, а библиотек очень много, так что 100% такие существуют, но на деле - всем ваще пофиг.
Что будем делать, когда проекты, от которых мы зависим внезапно начинают использовать две разных схемы версионирования. Вот тут и начинается веселье.
Фраза "Dependency hell" существует не просто так. Разбитие кода на независимые репозитории - это тоже дорога в ад :)
В том и прикол монорепы. Любое ломающее изменение - сломает тебе весь репозиторий. И ты это заметишь сразу. Из плюсов - ты можешь исправить проблему сразу везде, пускай это и потребует ресурсов. Но точно меньших, чем решать эту проблему силами разных команд 10 раз подряд, да еще и в разные временные интервалы.
Эта проблема решается более продвинутой настройкой CI с анализом списка измененных файлов в коммите, не более. Как я и сказал - для поддержки монорепы в работоспособном состоянии - нужна отдельная команда. Не "группка человек из разных команд", а реально отдельная команда билд-инженеров.
Монорепа/"многорепа" и монолит/микросервис - это проблемы из разных миров, которые между собой мало пересекаются.
- Монорепа/"многорепа" - это способы решения проблемы шаринга кодовой базы между разными продуктами/сервисами
- Монолит/микросервис - это способы решения проблемы взаимодействия разных частей системы между собой.
Я слабо представляю как эти проблемы связаны между собой. Они параллеьны друг другу.
Опять же, надо помнить, что говоря о монорепе положительно, я обычно говорю только в ключе С++ разработки. Потому что в С++ до недавнего времени не было модулей вообще, а нормальных - нет и сегодня, на мой взгляд. И монорепа для С++ решает множество проблем.
Для языков с нормальными модулями и пакетными менеджерами, вероятно, монорепа и правда монструозная ненужная конструкция.
Удобно управлять внутренними и не только зависимостями. Особенно в С++ проектах. Удобно унифицироватб сборочный процесс.
Возникают сложности при обновлении версий библиотеки, но при наличии отдельной команды для этого дела - это не проблема.
Это нормальная реакция на монорепу, но потом ты поживешь в другом мире и каждый раз когда нужно сделать релиз, хочется вернуться)
Если сливать файлы частями, то процесс определения дат будет довольно затруднителен.
Люди куда более предсказуемы, чем погода.
Проблемы с погодой могли бы решить несколько сотен тысяч дополнительных детекторов просто это дорого.
Модели для прогноза погоды строил обычный интеллект. Мы понятия не имеем на что способен AI
Ну, это даже близко не также. Шерлок холмс делает выводы по одному-двум признакам (и так-то занимается индукцией, но не суть). Что если в распоряжении у ИИ будет, ну скажем, 10000 факторов? С полной или не очень историей. Он сможет извлечь всю информацию из телефона человека, получит всю историю перемещения, переписок, покупок, фотки, и прочее и прочее. За мгновение. У любого человека.
Не, ну если они начнут раздавать VR-шлемы бесплатно, как браузеры, то let it be, пусть живёт.
Это пока его нельзя выгодно продать) А появятся диски, о которых вы говорите, цена улетит в космос)
Я не математик, но не вижу принципиальной невозможности. Особенно если речь идёт не о точных предсказаниях, а о вероятностях.
*нереально учесть человеку :)
С северной Кореей всё просто. Все граждане северной Кореи считаются гражданами южной, т.к. южная не признает разделения границ. Там у них отлаженная схема уже с беженцами.
У меня больше вопрос, насколько законно лишать гражданства полученного по рождению в принципе.
Вопрос не в том, что там написано, а что в итоге взлетит в массах.
И пока что Carbon выглядит как Kotlin для С++. И мне это нравится. А как выглядит Rust - не уверен. Концептуально Rust классный, я даже когда-то тут сам топил за него а каждом комментарии, но последнее время сомнения меня терзают.
С тем же успехом можно говорить, что в YAML встретится невалидный синтаксис и результат разбора пойдёт в мусор.
Мелькал Carbon не так давно на какой-то конфе) Чисто концептуально он мне понравился больше Rust, я бы поставил на него)