Сложности сопровождения rust

Динамические библиотеки — зло. В 70-х их придумали от безысходности, очень хотелось дорогое дисковое пространство сэкономить, а мы теперь страдаем, изобретаем докеры-флатпаки, либо просто носим с каждой программой ворох нужных ей файлов в папочке.

Динамические библиотеки — зло.

А за модульность и плагины тогда наверное сразу на кол сажать, при такой логике?

Чё сразу запрещать то? более того именно из-за наличия явных и отслеживаемых компилятором времён жизни необходимости в запрете нет; нужно, например, для хранения ссылок на объекты со статическим временем жизни(обычно строки) и это не будет нарушать смысловую целостность понятий предметной области, которые выразили в виде структуры, или внутри библиотеки где это самая целостность побоку, а нужно соптимизировать

Модульность не имеет к обсудаемой теме никакого отношения, а плагины вносят новую функциональность, в отличие от динамических библиотек, которые ничего не добавляют, а только делают жизнь админов сложнее.

и лайфтаймы не костыль, это так задумано, гораздо лучше когда знание о них в явном виде(особенно в апи) и формализовано и проверяется компилятором, особенно для больших программ, а не размазано по документации

а плагины вносят новую функциональность, в отличие от динамических библиотек

А как по-твоему возможна реализация плагина без динамических библиотек?

Куча вариантов, можно вкомпилить, статически, компилятор lua, и писать плагины на луа. Можно реализовать плагин через внешний процесс и общаться средствами ipc. Но я рад, что вы сразу отвергли 99.9% случаев использования динамической линковки, т.к. они явно бесполезные.

Ну ок, вот есть такой проект VLC, плеер такой для видео.

Поддерживает кучу разных форматов и кодеков, каждый кодек - отдельная подключаемая библиотека, часто большая. Еще и загружаемая не сразу а в момент использования.

Без динамической подгрузки он будет стартовать наверное секунд 15. Это помимо огромного размера самого бинарника.

Теперь что касается самого бинарника и его конских размеров.

На свете есть такой класс софта, называется «антивирусы», которые перед каждым запуском бинарника его сперва анализируют на наличие всякого плохого, чем вызывают видимые глазу тормоза даже на мощном железе.

Если запускали когда-нибудь инсталлятор в виде одного большого бинарника на пару гигабайт - могли наблюдать.

Если у вас все разбито на библиотеки и эти библиотеки не изменились с прошлого запуска - антивирус их пропустит (он не тупой), но вот если все приложение - один большой бинарь, то тормозить антивирус будет каждый раз, при каждом запуске.

Почему линуксоида должны волновать проблемы какого-то мифического антивируса? Я про эти антивирусы уже лет 20 ничего не слышал. Ну пусть ОС даст антивирусу интерфейс - менялся ли файл с такого-то времени.

Антивирусы есть подо все, Касперский есть под линукс, все кто держат свои почтовые сервера про это в курсе.

каждый кодек - отдельная подключаемая библиотека

Взял человек в руки молоток и каждая проблема кажется ему гвоздём. Вы буквально спрашиваете «как подключать библиотеки, если не подключать библиотеки». Естественно, никак. Надо подняться на уровень выше и переформулировать задачу. Я бы подумал в сторону подхода netfilter, где есть некое подобие виртуальной машины в ядре в которую из пространства пользователей можно загружать-выгружать инструкции, но это не единственный способ.

Теперь что касается самого бинарника и его конских размеров.

Вот, из-за вот таких любителей «уменьшать размеры бинарника», застрявших на уровне технологий пятидесятилетней давности, нам и приходятся таскать образы докера гигабайтного размера.

называется «антивирусы», которые перед каждым запуском бинарника его сперва анализируют

Это что-то виндовое? А винда эта такая система, где каждая программа тащит с собой целиком все копии всех библиотек? Вам не кажется, что есть какой-то порок в практике из-за которой сначала борятся за уменьшение размера, а потом, благодаря этому же подходу начинают носить с собой горы мусора?

все кто держат свои почтовые сервера про это в курсе.

И какое отношение почтовые серверы имеет к теме? Если кто-то пошлёт, либо: а) бинарник со статически добавленными в него фрагментами некоторых библиотек; б) бинарник со всеми библиотеками целиком, то во втором случае суммарный размер файлов больше и антивирусу больше работы. Такие дела.

Я бы подумал в сторону подхода netfilter, где есть некое подобие виртуальной машины в ядре в которую из пространства пользователей можно загружать-выгружать инструкции, но это не единственный способ.

А в чем тогда разница с отделяемой библиотекой, не просвятите?

нам и приходятся таскать образы докера гигабайтного размера.

Главное берегите спину, образы тяжелые.

А винда эта такая система, где каждая программа тащит с собой целиком все копии всех библиотек?

Нет это Mac. Но для вас полагаю разницы нет.

благодаря этому же подходу начинают носить с собой горы мусора?

Кому мусор а кому - требуемые опции и нужный функционал. Обратная сторона популярности решения.

Вопрос был из серии «зачем мне гордому линуксоиду знать что такое антивирус», я и объяснил.

Но из-за наплыва малвари уже и на линуксовом десктопе постепенно антивирусы появляются, например в виде встроенной защиты в последние версии Хрома. Там уже вполне себе сканер загружаемых бинарников.

А в чем тогда разница с отделяемой библиотекой, не просвятите?

Здесь технология употребляется, когда она уместна, а не как попало везде и всюду, просто потому, что деды так завещали.

Нет это Mac. Но для вас полагаю разницы нет.

Вы правы.

Главное берегите спину, образы тяжелые.

Понятное дело, если заливать проблему ресурсами, то всё равно какие там технологии использовать. Админы потрудятся, а пользователи тем более подождут когда там всё загрузится и запустятся, чай не баре.

а кому - требуемые опции и нужный функционал.

А вот и нет. Если вы из разделяемой библиотеки использовали всего одну функцию, то будете таскать с собой всю библиотеку целиком. Статическая компиляция же напротив, позволяет забрать с собой только нужное.

Но из-за наплыва малвари уже и на линуксовом десктопе

Вы что-то делаете не так. Не могу сказать что именно.

Здесь технология употребляется, когда она уместна

А вы точно понимаете разницу между «некое подобие виртуальной машины в ядре в которую из пространства пользователей можно загружать-выгружать инструкции» и банальной отделяемой библиотекой? В ней если что тоже инструкции, которые также выгружаются-загружаются.

Статическая компиляция же напротив, позволяет забрать с собой только нужное.

А если это «нужное» лишь одному пользователю? А другому нужно «другое»? Собирать другой бинарь?

А если разный функционал нужен в разное время и с разными условиями? Это внезапно называется опции, например опциональное логирование на удаленный сервер, которое можно отключить. Попробуйте опции, вам понравится.

Стили отображения для QT/GTK никогда не настраивали кстати? Они (сами движки) тоже отделяемые и выгружаемые, в виде библиотек.

Хотя у вас же наверное Xmonad какой-нибудь, а за еретическую идею «перемещения окна мышкой» вы бы с радостью сжигали на костре, дай вам волю.

Стили отображения для QT/GTK никогда не настраивали кстати? Они (сами движки) тоже отделяемые и выгружаемые, в виде библиотек.

Движки в виде библиотек выпилили ещё в GTK+3. Для GTK более актуальный пример это модули поддержки форматов изображений.

Движки в виде библиотек выпилили ещё в GTK+3.

Вот как бы еще я узнал что Gtk дорос до 4й версии? Только из срача на ЛОРе.

Песец время летит, когда только успели. Еще вчера же на 2.х все работали.

А вы точно понимаете разницу

Вы что-то доказать пытаетесь, так говорите прямо, не стесняйтесь.

А если это «нужное» лишь одному пользователю? А другому нужно «другое»? Собирать другой бинарь?

В каждом конкретном случае можно принять уместное решение, но даже если собрать бинарник и с той, и с другой функциями, всё равно выйдет меньше размером, нежели собрать бинарник и положить обе библиотеки рядом целиком и с нужными функциями и с бесполезными.

Стили отображения для QT/GTK никогда не настраивали кстати?

Я когда винду поставил (Win98SE — лучшая винда всех времён и народов!) как-то с этим наигрался и больше не тянуло.

а за еретическую идею «перемещения окна мышкой»

Когда нужно, при обсуждении технологий у вас фантазия отключается и кажется, что привычный вам способ — единственно разумный и даже возможный. А когда не надо, начинается какое-то безудержное фантазирование про костры и инквизицию. Не надо так.

Gtk дорос до 4й версии?

Уже грозятся начинать GTK5.

https://www.phoronix.com/news/GTK5-Likely-After-GTK-4.12

Last year was also talk of possibly dropping X11 support with GTK5 to make it Wayland-only. It will be interesting to see what changes end up materializing for this eventual GTK5 release.

Вангую что кончится как с 6м перлом. Хотя это же phoronix, все всегда likely и «по секретным документам».

Да о чём вы все? ) в расте есть поддержка динамической загрузки

Вы что-то доказать пытаетесь, так говорите прямо, не стесняйтесь.

Что не стоит сисадмину лезть в разработку, тем более в проектирование софта.

нежели собрать бинарник и положить обе библиотеки рядом целиком и с нужными функциями и с бесполезными.

А вы не задумывались вообще о природе «ненужного» ?

Вот допустим есть библиотека, реализующая подключение к СУБД - взаимодействие с базой данных это ее основная фукнция и смысл существования.

Сколько по вашему внутри может быть этого самого ненужного?

Количество используемых функций из этой библиотеки со стороны вашего приложения будет ну штук 5 - как раз то что теоретически поддается вырезанию при вашей любимой статической линковке.

В процентном соотношении это где-то 1% от всего кода библиотеки, остальное автоматическому вырезанию не поддается, только вручную, с залезанием в проект.

Чтобы в этом убедиться, достаточно сопоставить размер бинарника со статической линковкой с обычным, добавив размеры библиотек.

Максимальный выхлоп без ухищрений будет где-то 15-20% уменьшение размера.

Что не стоит сисадмину лезть в разработку

Мне ж потом за вами подчищать приходится.

Сколько по вашему внутри может быть этого самого ненужного?

Очень много. Случаи, когда ваш брат разработчик тащит фреймворк ради пары функций не поддаются учёту. Ну, что ж поделать, такие вот люди, у них на ноутбуке компилируется, значит всё в порядке. А как там в реальности продукт будет работать их не волнует.

Максимальный выхлоп без ухищрений будет где-то 15-20% уменьшение размера.

Будет просто замечательно, если вы сможете обосновать эти цифры.

Мне ж потом за вами подчищать приходится.

Вот такая тяжкая доля: запускать чужие программы за зарплату.
Раньше вот на вахте сидели, теперь в серверной, только жалобы на жизнь не изменились.

Случаи, когда ваш брат разработчик тащит фреймворк ради пары функций не поддаются учёту

Это иллюзия, не верьте. Я специально привел максимально близкий вашему случаю пример с клиентской библиотекой для СУБД.

А как там в реальности продукт будет работать их не волнует.

Еще как волнует, если не будет продукта, то не будет и вашей работы по его поддержке. Надо быть благодарным, как минимум за рабочее место, не находите?

Будет просто замечательно, если вы сможете обосновать эти цифры.

Вы можете и сами проверить, я же описал как. Будет видно даже на тестовом проекте на каком-нибудь жирном QT/Gtk.

Причина в том что «мусора, поддающегося автоматическому вырезанию» как такового нигде нет.

Тем не менее, я прекрасно понимаю о чем вы пишете и действительно реализовывал на практике вашу заветную мечту о «вырезании всего ненужного».

Путем глубокого залезания руками в каждую щель и под каждый камень. В результате размер сборки уменьшился со 120Мб до трех.

Но стоило это такой крови и денег, что просто так подобным заниматься не стоит. Даже ради вашего душевного спокойствия.

Очень много. Случаи, когда ваш брат разработчик тащит фреймворк ради пары функций не поддаются учёту. Ну, что ж поделать, такие вот люди, у них на ноутбуке компилируется, значит всё в порядке. А как там в реальности продукт будет работать их не волнует.

часто у разраба и выбора нет. у него есть только динамическая либа от третьей стороны, и он должен оттуда что-то поюзать.

смысл динамической либы в том, что ее будут использовать несколько апп одновременно, и потому если одна дернула пять функций, другая еще пять, третья - 10 и так далее. но это все будет один экземпляр кода.

динамическая либа, которая столь уникальна, что не преполагает одновременного использования несколькими аппами в вашей конфигурации - это неверный вариант применения такого механизма. но относительно терпимый. тут статическая линковка обьективно выгодней, если код можно статически влинковать.

Поддержка-то есть, но нет стабильного ABI. Любое обновление библиотек потрбует перекомпиляции. А без стабильного ABI динамическая линковка бесполезна.

Вот такая тяжкая доля: запускать чужие программы за зарплату.

Я не удивлён, что администраторы локалхостов не понимают сложность чужой работы. Собственно, если б вы понимали проблемы и усилия по их устранению, то вы бы не говорили ваших глупостей. Однако, за недостатком опыта вы на это не способны. Зря я вообще затеял что-то объяснять, но может другой кто прочитает.

Это иллюзия, не верьте.

Люди, придумавшие left-pad (почти два миллиона загрузок на этой неделе), не внушают доверия.

Надо быть благодарным, как минимум за рабочее место, не находите?

Нарочно делать кривой продукт, чтобы заставлять больше платить за его сопровождение? Со мной спорите, ладно, но хоть Бога-то побойтесь!

Вы можете и сами проверить,

Всё ж бремя доказательства ваших слов лежит на вас.

В результате размер сборки уменьшился со 120Мб до трех.

Мелочь какая. Сверх того напомню, что размер это только часть проблемы. Вторая и ещё более страшная и ужасная — хрупкость среды исполнения. Чтобы программа запустилась, нужно чтобы необходимые файлы лежали на соответствующих местах. А ещё нужно, чтобы в будущем никакие действия не испортили среду исполнения. Все люди разрабатывающие и поддерживающие все дистрибутивы, изобретатели виртуальных окружений, свой велосипед для каждого языка, бывает и не один, создатели контейнерных технологий, создатели флатпаков, снапов, аппимеджей, все эти люди занимаются онанизмом вприсядку, просто потому, что мы не можем собрать статичный бинарник и сказать: „сделайте ему chmod 775 и положите куда-нибудь в $PATH, поздравляю, развёртывание завершено, вы великолепны“.

смысл динамической либы в том, что ее будут использовать несколько апп одновременно

Это хорошая теория (и в прошлом — практика), но сейчас всё изменилось. Индустрия выбрала докер потому, что проще заплатить избыточными ресурсами и с каждой программой таскать собственные копии нужных библиотек, зато быть уверенными, что единожды собранный образ будет запускаться и работать всегда и везде.

Сейчас получается как-то так:

$ docker image ls                                                                                                                                         
REPOSITORY                                                                      TAG                    IMAGE ID       CREATED         SIZE
XXXXXX.dkr.ecr.eu-central-1.amazonaws.com/YYYYY                                 16.9.2-29a1a2adc064a   aee0892c37ea   8 months ago    1.9GB
XXXXXX.dkr.ecr.eu-central-1.amazonaws.com/ZZZZZ                                 0.1.1                  1f04055ecd0b   14 months ago   2GB

и это не то, чтоб круто. Не то чтоб я сгораю со стыда, но всё-таки хотелось бы как-то гордиться своей работой что ли.

Так его вообще нет, для плагинов достаточно стабильно

Я не удивлён, что администраторы локалхостов не понимают сложность чужой работы.

Специально для вас написано, можно сказать мемуары.

Цитата из последнего (2004й год на минуточку):

Думаю мало кто может похвастаться опытом настройки домашней локалки на бл#ть маршрутизаторе уровня ядра, пусть и очень недолгом — мне его дали для обновления прошивки и настройки.В этой йобе даже BGP был!

Вот моя старая учетка тут, от 2007 года, пароль не нее забыл к сожалению.

Не подумайте что хвастаюсь (хотя это так), просто чтобы понимали кому пишете.

сделайте ему chmod 775

Удивительно что никто из коллег вопросов не задал. Вы точно сисадмин?

Или готовый крейт https://lib.rs/crates/abi_stable заюзать, решают люди то

Теперь что касается докера и всех прочих современных штук, которые вы так сильно не любите. Они очевидно имеют проблемы и недостатки, но только замены и альтернативы им нет. Потому что «лучшее» лишь означает что другие - еще хуже.

Проблема товарищей вроде вас, что вы при всем вашем опыте не способны в конструктивный диалог. Отсюда следует неумение доносить мысли, нежелание и неумение сотрудничать. А значит весь полученный за жизнь опыт уйдет в свисток вместе с вами.

Чтобы что-то изменить к лучшему в используемых инструментах надо уметь договариваться и убеждать, но точно не поливать все вокруг говном. Так это не работает.

Кстати да, это интересный момент, что на других языках ты городишь ссылки в структурах данных и потом долго мудохаешься с NRE. А в расте тебя заставляют страдать на каждую лишнюю ссылку и иной раз ты лучше скопируешь(или move сделаешь), чем вот это вот всё.

иной раз ты лучше скопируешь(или move сделаешь), чем вот это вот всё.

А память у вас в расте при этом не заканчивается?

А должна? Как говорил классик: «premature ejaculation is a root of all evil».

Если я скопирую один лишний раз структуру, пусть даже в полсотни байт, от этого никому хуже не станет. А вот если я, только чтобы её не копировать, буду городить сложночитаемый код - хуже станет в первую очередь мне.

Если я скопирую один лишний раз структуру, пусть даже в полсотни байт, от этого никому хуже не станет.

Вот это то что я не понимаю.

В вашем расте есть некий «третий путь» управления памятью. Нечто называемое «ownership». Не GC но и не полностью вручную.

Поэтому чем закончится clone() вызванный миллион раз для меня загадка.

Нормально ты прошелся :-)

Нет никакого третьего пути. Если использовать ссылки, то borrow checker не даст их использовать некорректно. Такой же код, переписанный строчка в строчку на C просто окажется кодом с багами, только сказать об этом некому.

А по ссылке говорят что есть:

Some languages have garbage collection that regularly looks for no-longer-used memory as the program runs; in other languages, the programmer must explicitly allocate and free the memory. Rust uses a third approach: memory is managed through a system of ownership with a set of rules that the compiler checks

Кому верить?

В вашем расте есть некий «третий путь» управления памятью.

Там концепт простой - компилятор следит, чтобы если ты что-то создал, то было только одно место в котором это что-то используется в каждый момент времени. Как статический планировщик при компиляции.

Ну типа выделил переменную на стеке, передал в функцию, попытался использовать дальше - тебе компилятор по рукам даст, мол я это уже move сделал, харам. оно ушло в новый стекфрейм и там зачистилось.

Если ты сделал Box, то это считай unique_ptr, через который можно достучаться в тот кусок хипа, но это всё ещё умный указатель, который лежит на стеке и когда его стекфрейм кончится - вызовется free(). Ну да ты логику smartpointers понимать должен и без меня.

Весь вот этот овнершип это и есть смартпоинтеры с активным использованием move семантики и слежением со стороны компилятора за тем, чтобы этот самый смартпоинтер два раза, без явного намерения, не потрогали из разных мест.

А дальше на это навешиваются Rc, Arc, RefCell и вагон всего, который нужен для обеспечения всё той же задачи ограничения доступа к памяти из одного места в программе, но уже в рантайме.

Всё то же самое ты делаешь в голове, когда на плюсах пишешь, а тут приходится формализовать и обьяснять компилятору явно.

Поэтому чем закончится clone() вызванный миллион раз для меня загадка.

Да ровно тем же самым, что и если вызвать миллион раз замыкание с передачей по значению.

Ну там описывается RAII, такой же самый как и в C++.

Там концепт простой - компилятор следит, чтобы если ты что-то создал, то было только одно место в котором это что-то используется в каждый момент времени. Как статический планировщик при компиляции.

Стесняюсь спросить, что же тогда происходит при многопоточности. Компилятор настолько умный получается?

При многопоточности происходит довольно простое - ты не можешь сделать move переменной между потоками, без дополнительного телодвижения, которое будет удовлетворять условию «реализован трейт Send», реализация которого означает «тут знают что делают».

Например можно в Mutex завернуть, можно в Cow и т.п. А компилятор, за счёт очень активного использования системы типов это всё может разрулить статически при компиляции.

Это если совсем поверхностно, там в глубине неочевидные нюансы начинаются, которые надо учитывать. Но концептуально примерно так, но может лучше объяснит кто.

чуть подробнее тут https://doc.rust-lang.org/nomicon/send-and-sync.html

А, я там с формулировками сам уже запутался слегка. Короче, без Send потрогать переменную из соседних потоков не получится потому что компилятор по рукам настучит.

Спасибо за столь глубокое раскрытие темы, все же есть какие-то проекты на расте в РФ?

Про РФ хз, кто-то из нагруженных бэкенд крутил, авиасейлз вроде, но могу путать.

У меня есть кой-какая рабоачя мелочь, которую удобнее всего делать на расте, по разным причинам. Но то не показатель.

авиасейлз точно не показатель - они ради удержания кадров переписывают свой софт с нуля раз в полгода.

Там уже и джава и го и плюсы и скала и js - все уже было.

не стоит сисадмину лезть в разработку

А вот и стоит, точнее, стоило раньше, и с большой дубиной в руках. Потому что без этого обезьяны наловчились изготавливать автомобили, которые могут ехать только внутри сборочного цеха. А «раньше» я сказал потому, что теперь для организации постоянного сборочного цеха вокруг едущего автомобиля (см. «контейнеризация», «оркестрация» и проч.) придумали аж отдельную профессию «девопс», и платят им побольше, чем обезьянкам с ключами, которые по инерции убеждены, что они что-то там «думают», «программируют» и тем более «проектируют» .

А по поводу срача - динамические либы нужны, а вот насчет разделяемых всякий раз надо сильно думать. Оба правы.