Дядя Тео и Rust

Они пишут. Все.

Не соответствует действительности.

Надо покопаться во всех этих васюках. Пока мне не особо понятно на сколько оно всё адекватно, и в какую сторону движется

Может, но этого почему-то не происходит.

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

в какую сторону движется

В которую двигает сообщество. Было бы желание (у мейнтейнеров).

С их подходом к экосистеме случился curl|sh.

Ну я не могу хорошо относиться к проекту, который пытается быть FLOSS, но при этом кладёт болт на существующие практики дистрибуции софта и единственным официальным методом распространения тулчейна предлагает шелл-скрипт, а единственным официальным методом распространения софта — свой собственный ни с чем не интегрирующийся ПМ.

а единственным официальным методом распространения софта — свой собственный ни с чем не интегрирующийся ПМ.

Разве это «механизм распространения софта»?

По моему, это просто способ предоставить удобство для разработки. И тут раст совсем не одинок со своим «ни с чем не интегрирующимся ПМ».

Ужаленные плюсами хотят ещё одни плюсы, только с перламутровыми пуговицами.

По твоему разница между растом и С++ меньше, чем (например) между С++ и паскалем?

Почему? В смысле, разверни мысль. Почему «точно такое же» и как надо.

И тут раст совсем не одинок со своим «ни с чем не интегрирующимся ПМ».

Массовость явления не снижает его фэйспалмовость

Корпорациям нужен дурной язык для масс

Для «масс» не помешал бы язык попроще, тут С++ как-то плохо в теорию укладываются.

Дайте уже Тео макбук и позовите на лор

Неужели openssh и tmux написал лично дядя Тео?

Массовость явления не снижает его фэйспалмовость

Так может надо подумать почему люди продолжают так делать и какие альтернативы есть вместо того чтобы «фэйспалмить».

По твоему разница между растом и С++ меньше, чем (например) между С++ и паскалем?

Не правильная постановка вопроса. Важно что руст унаследовал куски синтаксиса С/С++, а этого вообще не нужно было делать.

Важно что руст унаследовал куски синтаксиса С/С++, а этого вообще не нужно было делать.

Почему? И какие именно унаследованные куски по твоему вызывают проблемы?

Опять же, ты ведь понимаешь, что можно найти какие-то «общие куски» (не важно «унаследованные» или просто одинаковые решения) в С, С++ и паскале? И о чём это будет говорить?

Для «масс» не помешал бы язык попроще, тут С++ как-то плохо в теорию укладываются.

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

Почему?

Плохая наследственность это не есть хорошо.

И какие именно унаследованные куски по твоему вызывают проблемы?

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

Я там выше высказывал свои мысли на этот счёт

А я когда-то фанател от Ada-83. У меня несколько книг есть по ней.

Хех. У меня до сих пор в столе лежит книга Вегенера.

Это по сути был один из первых промышленных языков, где появились генерики

И относительно нормальные AlgDT. И исключения. И многозадачность.

Массовость явления не снижает его фэйспалмовость

А чем это более фейспалм, чем обычное:

(curl something-X.Y.tgz | tar xz) && (cd something-X.Y && ./configure && make)

По-моему, cargo (и даже npm) - это строго лучше, чем помойка из тарболов.

Тем что make в норме не качает автоматически ещё десяток тарболов и не компилит их. Вообще большинству прикладного софта хватает либ из дистрибутива (во всяком случае если это Debian)

Тем что make в норме не качает автоматически ещё десяток тарболов и не компилит их.

Но ты качаешь их сам. Это лучше?

Вообще большинству прикладного софта хватает либ из дистрибутива (во всяком случае если это Debian)

Это редкое счастливое исключение. Впрочем, к Rust это неприменимо пока.

Но ты качаешь их сам. Это лучше?

Да. Особенно учитывая что конпеляция это не та вещь которую рядовые пользователи делают ежедневно.

Это редкое счастливое исключение. Впрочем, к Rust это неприменимо пока.

По моему опыту исключение это скорее сишный/плюсовый софт с зависимостями которых нет в репе. На сколько могу вспомнить проблемы с этим у меня были только когда сидел на какой-то некро-версии Ubuntu (там либы были просто слишком старые), и ещё один раз когда хотел собрать ffmpeg именно с новыми версиями libvpx и x265 (или там были нужны какие то креативные экспериментальные параметры сборки, не помню)

Тем что make в норме не качает автоматически ещё десяток тарболов и не компилит их.

Но ты качаешь их сам. Это лучше?

Да.

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

Мне это не нравится, просто альтернатива мне не нравится ещё больше. Неявное автоматическое впиливание в систему кода из кучи разных источников это несколько стрёмно.
Уж лучше я напрягусь и сам сделаю wget && tar && configure && make чем что то вроде curl http://some.url/ | su - или «дайте нам рутовый доступ к вашему серверу и наш бот вам всё настроит» (помнится такой вариант установки предлагала какая то софтина про которую тут была новость)

Собственно проблема всех этих npm-ов в опухании очень слабо контролируемых зависимостей

Мне это не нравится, просто альтернатива мне не нравится ещё больше.

В обоих случаях результат одинаков, но в случае ручной работы - это 1) ручная работа 2) результат не поддается учету.

Уж лучше я напрягусь и сам сделаю wget && tar && configure && make чем что то вроде curl http://some.url/ | su

curl | su - это не хуже make && su -c 'make install'. Впрочем, Rust не требует su.

проблема всех этих npm-ов в опухании очень слабо контролируемых зависимостей

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

Тео прав. Всех этих страдающих от синдрома утенка, желающих переписать все на очередном язычке, нужно гнать ссцаными тряпками.

В обоих случаях результат одинаков, но в случае ручной работы - это 1) ручная работа 2) результат не поддается учету.

Вот только в случае с configure && make зависимостей меньше и они [почти] все уже в репах, а в случае с npm/pip/etc зависимостей зачастую до чёрта и они чёрт знает где

Проблема в том что зависимостей много и процесс их попадания от разработчика в целевую систему не предусматривает посредника который мог бы проверить код.
Я считаю что либы правильнее устанавливать из репозитория дистрибутива, а wget && tar && configure && make это запасной вариант для редких случаев. Но приблуды вроде pip делают процедуру аналогичную configure && make очень простой, и поэтому она вытесняет более правильный вариант с apt/rpm/etc

P.S. make install тоже может работать без su, use --prefix, Luke. Нафиг слакваризировать родную бубунточку?

В обоих случаях результат одинаков, но в случае ручной работы - это 1) ручная работа 2) результат не поддается учету.

Вот только в случае с configure && make зависимостей меньше и они [почти] все уже в репах,

Сколько зависимостей - зависит от культуры разработки; что есть в репах - зависит от свежести дистрибутива (Debian stable к третьему году жизни). Ну а если ты предлагаешь Rust ждать, пока дистрибутивные мейнтейнеры занесут библиотеки в репозитории... думаю, с твоим предложением согласится ровно 0 человек.

Ты упорно отказываешься понять простую вещь - все эти npm и cargo всего лишь автоматизируют то, что пришлось бы делать руками (то же делают apt-get и yum, кстати). Разработка программ идет быстрее, чем успевают поворачиваться мейнтейнеры дистрибутивов.

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

P.S. make install тоже может работать без su, use --prefix, Luke. Нафиг слакваризировать родную бубунточку?

Ты сказал, что root может потребоваться в новой схеме - я напомнил, что он может потребоваться и в старой. В остальном - curl | sh тоже может работать без su, и cargo тоже.

Сколько зависимостей - зависит от культуры разработки

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

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

Сколько зависимостей - зависит от культуры разработки

Собственно к ней-то у меня и претензии.

Боюсь, здесь ничего сделать нельзя.

Но обсуждаемые инструменты делают такую культуру разработки возможной

Обсуждаемые инструменты выполняют те же функции, что и apt/yum. Если у тебя нет претензий к apt, то твои претензии к cargo тоже неуместны.

Свои мысли на счёт того какой могла бы быть более вменяемая альтернатива этим стульям я излагал выше

Всё в репозиториях дистров? Это не работает уже давно.

И есть ли сейчас свободные и бесплатные компиляторы Ады для разработки коммерческих приложений? Так время диктует свои правила

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

Если что, с gnat из gcc коллекции можно получать бинарники с таким же Runtime Library Exception, как и с компиляторами gcc/g++/...

Обсуждаемые инструменты выполняют те же функции, что и apt/yum

apt/yum работают с централизовано управляемым репозиторием. А NPMы с олимпиардом разрознено управляемых репозиториев. Получается что-то вроде apt к которому подключили вообще все ppa сразу

Всё в репозиториях дистров? Это не работает уже давно.

Нет, в другом треде подробно писал. Дядя Тео и Rust (комментарий)

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

Если что, с gnat из gcc коллекции можно получать бинарники с таким же Runtime Library Exception, как и с компиляторами gcc/g++/...

А это давно появилось? Скажем, лет 5 назад так было? То есть, я могу бесплатно разрабатывать закрытые программы на Ada? Хотя начинаю вспоминать. На Windows можно разрабатывать бесплатно? :)

А это давно появилось? Скажем, лет 5 назад так было? То есть, я могу бесплатно разрабатывать закрытые программы на Ada?

Очень давно, скорее даже всегда: коллекция gcc, ведь.

Хотя начинаю вспоминать. На Windows можно разрабатывать бесплатно? :)

Если купили готовый ПК, то, наверняка, на нём есть наклейка.

Ага, ну и как ты предлагаешь заставить все дистрибутивы вовремя добавлять пакеты в свои репозитории? Да если бы не тот же pip, очень многое не работало бы, потому что какой-нибудь Debian stable надо ждать ~10 лет. Именно поэтому альтернативные пакетные менеджеры пилятся и будут пилится, иного решения для удобной и своевременной доставки зависимостей пока нет.

Да если бы не тот же pip

…разрабы старались бы не использовать модули которых нет в репах попсовых дистрибутивов. Потому что смысл им писать софт который не будет работать у большинства пользователей без мануального секаса с тонной зависимостей

Короче читай коменты выше, не хочу в третий раз то же самое повторять

Там один идеалистический бред. Ты не знаешь как обновляются репы дебиана или какого-нибудь ALT? Что бы по-твоему старались использовать разрабы, если в дебиане всё протухло, а в арче всё самое свежее? Какую-же версию либы брать, а? Или вот какой-то дистр заартачился, не принял либу, её там нет. Что тогда делать?

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

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

К.О. мог бы тут отметить, что со старыми версиями либ использовались бы старые версии софтины, но его нет.

Это при условии что либы вообще есть в репах. Потому что не каждый разраб утруждает себя их туда отправлять. Но даже если заявка отправлена, нужно долго ждать, в случае с дебианом - несколько лет, и то если повезёт. Что в таком случае сделали бы разрабы софтины? Правильно, сторонние репы или подтягивание с гитхаба.

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

Использование гитхаба / мавена тоже не надёжно - проекты иногда выпиливаются и зависимость пропадает. Да, тоже говна наелся с этим.

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

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

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

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

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

Почему то сишный и крестовый софт в основном замечательно обходится либами из реп.

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

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

Если купили готовый ПК, то, наверняка, на нём есть наклейка.

Молодец! Рассмешил под конец рабочей недели. Очень кстати

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

При такой стратегии нормальная кроссплатформа невозможна, снижается количество пользователей. А если это коммерческий софт? Ну-ка объясни эффективным менеджерам, почему они должны потерять часть клиентов, либо влить лишнюю кучу бабла на разработку. А потом приходи ныть на ЛОР, что этот твой люникс никому не нужен кроме 0.0000001% задротов.

То, что обходится либами из реп, в основном написано под конкретный дистр. Либо это очень распространённые либы, которые гарантированно везде есть. Хотя и тут весело. Например, в Qt был баг с утечкой памяти в медиаплеере (не знаю, пофикшен ли). И либо юзер откуда-то обновит Qt, либо будет страдать.

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

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

Ну уменьшай - это же OpenSource, никто тебе не запрещает. Потом кинешь пулл реквест, все будут рады.

Код свежестянутый с гитхаба или сайта разработчика (последний стабильный релиз) обычно нормально компилится в каком нибудь debian stable, не говоря уж про бубунточки

В-четвёртых, с сосуществованием нескольких версий как раз таки у C и C++ всё очень плохо

Что-то не помню проблем с пакетами вида libastagal1 libastagal2. Конечно разработчикам приходится следить за совместимостью интерфейса libastral-1.0.1 и libastral-1.0.2, но разве это плохо?

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

Код свежестянутый с гитхаба или сайта разработчика (последний стабильный релиз) обычно нормально компилится в каком нибудь debian stable, не говоря уж про бубунточки

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

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

Что-то не помню проблем с пакетами

С ПАКЕТАМИ. _ПАКЕТАМИ_, понимаешь? Пакеты делают мейнтейнеры дистрибутивов, а не разработчики. Практически всегда.

Конечно разработчикам приходится следить за совместимостью интерфейса libastral-1.0.1 и libastral-1.0.2, но разве это плохо?

Проблема в том, что _разработчики_ не следят за этим в 99% случаев. Если мы говорим именно про возможность сосуществования на одной системе.

Я не про кодовую базу конкретных проектов, а про кодовую базу всяких npm-ов в целом, и уменьшать нужно не колличество года, а количество проектов. В общем NIH-синдром сообщества нужно лечить

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

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