Rust 1.34

Идея, что добрый дядя модератор решит все наши проблемы утопична по сути

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

Так почему нельзя так же сделать расту?

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

Не лучше ли просто дать им удобные инструменты?

раст за явные косяки сразу лупит палкой по рукам.

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

Динамичность ограничена циклом релизов. Это только для стабильных компонент прокатывает. Предложение от дядь модераторов хорошее, но 100% потребностей закрыть не может. Поэтому в убунте есть ppa, который регулярно выручает.

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

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

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

Хмм, а что растовые либы уже можно ставить через apt, как хаскельные или перловые? По слову rust apt ни одного крейта не находит...

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

Ну пока с пакетами там вообще жидко. Язык молодой, нормальное дело. Рассосется со временем. В ноде поначалу тоже с пакетами был полный ад, со временем наладилось.

IMHO это все-таки больше особенности экосистемы любого молодого языка, а не следствие технических фич.

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

Смысл моего предложения в том, что оно менее конфликтное и затратное.

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

Ну значит либо разработчик попотеет, либо возникнут форки. Так весь опенсорс же устроен. Просто нужно время, чтобы устаканилось. Такие процессы - более общие вещи, не особенность языка.

Никто не мешает тебе нанять модераторов или искателей пакетов

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

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

ХЗ. В ноде вроде справляются, а там зависимостей не меньше, и язык на месте не стоит. Хаскеля не знаю, комментировать не могу.

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

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

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

Как продвинутый нодоюзер

Так там не бывает конфликтов по зависимостям? В смысле когда одному нужна конкретная версия либы, а второму - конкретно другая версия той же либы?

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

А раст так не умеет? Вроде мозиловцы с нодой хорошо знакомы.

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

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

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

А раст так не умеет?

Умеет. Можно хоть 10 разных версий одной либы использовать. И оно не даст их смешивать.

И эта привязка всех к cargo. Смерть руби из за своего пакетных менеджера их ничему не научила.

А что ж питон не сдох из-за своих ПМ? А перл?

Ты прочитай всю цепочку комментариев. Я как раз утверждал что это так, но тебе (или другому анону) это за аргумент не прокатило.

Почему же тогда программировать на современном C++ проще, чем на C++ двадцатилетней давности?

чукча не читатель же

И JS туда же. И у Java тоже была какая-то нёх с манифестами, которая сама всё тащила, а то и не одна. Тысячи их.

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

Слишком жирно.

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

обычно нужно не более трех вариантов: self, &self, и &mut self

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

А раст так не умеет? Вроде мозиловцы с нодой хорошо знакомы.

npm сам чуть ли не на расте написан

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

Это что-то новое. Откуда такая информация?

раст еще не настолько хорош чтобы заменить божественный яваскрипт :)

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

https://github.com/npm?utf8=%E2%9C%93&q=&type=&language=rust

https://www.youtube.com/results?search_query=npm+rust+talk

речь, вроде бы, идет о сервер-сайде

не знаю насчет студентов, баба, читавшая доклад, «sits on the board of directors of the Node Foundation», что бы это не значило. но звучит внушающе

«На постоянной основе пишет 10 человек на весь мир» - ложь, пока нет пруфов обратного.

Конечно ложь, и десяти не наберётся.

#define ПОСТОЯННАЯ_ОСНОВА

Основной ЯП

Только компилятор rust больше 100 человек разрабатывают

А ядро linux тысячи, вот только НЕ на постоянной основе.

Твои весы пошли по второму кругу.

Потому что ты программируешь на нём уже 20 лет? Основная проблема ЦПП как раз в том, что для получения более-менее приличного программиста даже из способного человека нужно 5-7 лет граблебоя. Причём с усложнением ЦПП, увеличением числа стандартных библиотек и уровней абстракции проблема только усугубляется, поскольку все старые варианты остаются в строю и продолжают активно использоваться предыдущими поколениями программистов, а также теми нубами, которые ещё не разгребли свои грабли.

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

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

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

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

Как только ты начнёшь решать задачи решаемые С/С++ - ты получишь те же проблемы на любых недоязычках. Хотя нет, ты их не получишь, ведь они попросту не могут эти задачи решать.

каминг-аут же один раз совершается?

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

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

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

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

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

Потому что ты программируешь на нём уже 20 лет?

Это поэтому я теперь могу вместо:

for(my_vector::const_iterator it = cnt.begin(), it_end = cnt.end(); it != it_end; ++it) {
   ...
}

for(const auto & v : cnt) {
   ...
}

Но это просто цикл foreach обхода последовательности, генерируемой стандратным итератором, который в D или go или Python (в последних двух называется он for) давно уже есть. И тем более в функциональных языках. Он также подразумевает невозможность изменения её элементов, что логично. Это хорошо, что можно теперь так писать, но в этом ничего революционного нет. Плохо то, что по-прежнему можно писать по-старому и многие продолжат так делать.

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

Он также подразумевает невозможность изменения её элементов, что логично.

Не подразумевает.

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

Подводные камни C++ никуда не делись. Современный C++ не защищает, например, от вот таких граблей:

const std::string &
get_or(const std::string & key, const std::string & default_value) {
   ...;
   return default_value;
}

А вот страшилки на счет «если ты один и если новый код, а вот если старый...» еще непонятно, насколько соответствуют действительности. Дебилов, которые не могут освоить новый foreach, auto, overload или делегирующие конструкторы хватает. Но их везде хватает, может быть даже в Java таких еще больше будет. Делают ли они погоду?

ИМХО, разве что в LOR-овских срачах.

Дебилов, которые не могут освоить новый foreach, auto, overload или делегирующие конструкторы хватает.

Меня больше смущает https://en.cppreference.com/w/cpp/language/value_category

Переодически хочу всякие форичи и типизированые контейнеры в сях. Открываю c++. Блюю. Дизассемблю крестовую программу. Блюю ещё.

Я не спорил с тем, что C++ стал сложнее. Речь о том, что не смотря на возрастающую сложность, использование C++ оказывается все проще и проще. Поэтому тезис о том, что увеличивающаяся сложность похоронит C++ является спорным, по меньшей мере.