и как тут не поверить в раст заговор?

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

Без простоты втыкания любой библиотеки в проект, разработчики быстро забивают болт на обратную связь (напрягаться же лень). Без нее скорость развития резко падает. Не до нуля, но по сравнению с языками где есть ПМ, очень кисло смотрится.

Просто для примера. Я не ленивый, жабаскриптами тренированый, оформлять код привык. У библиотеки должен быть манифест для автоматической установки. И вот мне под свои эмбедные поделки получается что надо лепить конфиг для platformio, arduino, conan, cmake и еще хер-пойми что. Вот нафига мне такое счастье и на сколько хватит моего терпения?

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

Вы прослушали экспертное мнение JS-кодера о разработке библиотек на C/C++

Есть пакетный менеджер дистрибутива. В котором ставится версия libxxx 2.3.x и она будет весь период работы программы на этом дистре 2.3.х (максимум секурефиксы). Что даёт постоянное окружение и стабильную работу.

А не когда колхозник Петя изменил свой код left-pad, что по цепочке изменило 19000 пакетов, каждый из которых используется ещё в миллионах других пакетов. Ой, API поломалося, надо делать ребилд и редеплой на тысячи машин. Ой, а там нет удалённого ансибла, нужно ждать техника, который по медвежьему говну поедет в удалённое село с флешкой обновлять ваш продукт.

Не говоря уже о качестве того говна, что лежит в «пакетных менеджерах» типа npm/cargo и прочих

Ага, кое-кто именно прослушал. Мимо ушей.

Это все наверное очень важно и познавательно, только к развитию экосистемы не имеет ни какого отношения.

И вот экосистема без общепринятого ПМ

А общепринятый это какой из?

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

facepalm.jpg.2 Ну вот например есть разработчик на C для пром железа, нафейхуа ему ПМ убился? Или есть разработчик под оффтопик, зачем ему ваш ПМ?

IMHO имхо это довольно спорный подход, выбирать тех кому ПМ не нужен, и спрашивать, почему они должны им пользоваться :).

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

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

Это все наверное очень важно и познавательно, только к развитию экосистемы не имеет ни какого отношения.

Отсюда делаем вывод: экосистема она не для того, чтобы было легко в бою, а чтобы ленивый разработчик мог одной небрежной npm install пошатать предприятие.

качестве того говна, что лежит в «пакетных менеджерах»

В дистрибутиве-то точно качественное говно лежит.

В дистрибутиве нет малвари. О которой буквально каждая первая новость про npm

Ну-ну.

Да, только денег от этого больше не станет, разве что донат защекоинами.

это планомерная замена GNU лицензированных проектов на MIT-Apache-BSD эквиваленты

libxml2 — MIT, c-ares — MIT, LZMA (та часть xz, которая сжимает/разжимает) — Public Domain.

вам мало 350тр за переписывание libxml2?

Зарплата высококвалифицированного программиста за 1-2 месяца. Или джуна меньше чем за год. В libxml2-2.13.7 8 мегабайт кода на Си. 1 программист столько напишет за 2 месяца? А за год? А десяток за месяц?

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

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

Кто-нибудь всерьёз количественно исследовал? Хотя бы на том же уровне, как Eriсsson с Erlang-ом.

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

И разве можно при этом лицензию менять, просто переписав код проекта?

Если в проекте ничего от оригинального текста не осталось, не считая структур данных, то судя по прецеденту с Minix и Linux — можно.

разработчик на C для пром железа, нафейхуа ему ПМ убился

Вот я недавно разрабатывал для nRF52 с помощью nRF5 SDK. Итого по пакетам: собственно сам nRF5 SDK, который логически внутри разделён на несколько десятков пакетов, внешняя библиотека micro-ecc, также отдельный блоб S113 Softdevice, который тоже можно считать библиотекой. Также внутри nRF5 SDK ещё несколько десятков завендоренных библиотечек, из тех, которые я использую - Segger RTT, а так там и FAT32 и FreeRTOS, и protocol buffers, и какой-то рендерер для шрифтов и куча всего, очевидно, что люди это используют в разных проектах.

Менеджер пакетов для всего этого был бы весьма пользителен.

Я, конечно, одобряю отказ от переиспользования кода (включая libc) и с удовольствием буду писать всё с нуля в каждом проекте, но объективно признаю, что мир, включая мир embedded разработки, таки движется в другом направлении.

Я теоретически готов переписывать libxml2 за 200 тр в месяц. Я перепишу примерно 100 строк кода в день, это 3000 строк кода в месяц. В библиотеке сейчас 188 тысяч строк кода. Т.е. нехитрыми расчётами приходим к тому, что мне потребуется около 5 лет и 12 млн р.

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

350 тр за эту задачу определённо мало.

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