rust (не флейма ради)

ставить pip’ом было лень, поискал на AUR, нашел

Дальше не читал

ставить pip’ом было лень, поискал на AUR, нашел

Дальше не читал

Ну просто если штука поддерживается мантейнером как пакет, то штука обновляется, а если pip’ом, то крути свои. Разве что я не умею их готовить?

Мне тоже показалось, что это взаимоисключающие параграфы.

simple

[dependencies]
clap = "2.33.0"
termcolor = "1.0.5"
lazy_static = "1.4.0"
time = "0.1.42"
chrono = "0.4.9"
flate2 = "1.0.11"
filetime = "0.2.7"
pretty-bytes = "0.2.2"
url = "2.1.0"
hyper-native-tls = "0.3.0"
mime_guess = "1"
# Iron crates
iron = "0.6.1"
iron-cors = "0.8.0"
multipart = { version = "0.16.1", features = ["iron"] }
htmlescape = "0.3.1"
percent-encoding = "2.1.0"
path-dedot = "1"

Вся суть раста.

Для питона модуля SimpleHTTPServer не было

в смысле не было, он же там есть из коробки? В 3-м питоне запускается так:

python -m http.server

Вся суть раста.

Это еще до раста придумали, называлось SOAP. Угадай от какого слова ‘S’.

Но почему аж 151 пакет… IMHO это какой-то баг в dependencies.

python -m http.server

А, ну значит я еще тупее, чем думал. Спасибо. Свое я, правда, растопросточудом проверил, но на будущее хорошо знать.

(не флейма ради)

Врёшь прямо в топике

Разве это не перебор?

В растовом подходе к зависимостям - нет.

оно собирает 151 пакетов. Разве это не перебор?

они переписывают зависимости на раст. у тебя в системе зависимости на си(++)

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

По пакету на функцию - это баг или фича?

просто какой-то вброс

Да идите вы в сад. Я ничего против раста не имею. Всякие borrow references или как их там дисциплинируют. Я просто не понимаю зачем. Как никогда не понимал зачем мантейнеры дебиана делят программу на 100500 пакетов. Поэтому и спросил тут «зачем». Только не надо говорить, что «за шкафом».

А как твое приложение будут воспроизводить другие люди?

Я обычно делаю какой-нибудь venv и уже там ставлю то что надо приложению

Я обычно делаю какой-нибудь venv и уже там ставлю то что надо приложению

Зачем простому приложению «http сервер» 151 других приложений? Я понимаю, что там ядро, там прерывания, там OSI model, ну так может тогда сразу распространять приложение helloworld с зависимостями от, например, в частности, ядра, которое будет тут же собираться cargo и запускаться в каком-нибудь qemu.

Я просто не понимаю зачем.

Отчасти, потому что могут. Скажем, в С++ подключать зависимости непростой процесс и в результате удобнее использовать или «наборы библиотек» (вроде буста) или фреймворки (вроде Qt). В расте же подключать зависимости просто, ну и модульная структура тоже позволяет удобно дробить функциональность. В итоге даже если делаешь какую-то более-менее большую библиотеку, то всё равно естественным путём выделяются более мелкие части. Если они могут кому-то пригодится сами по себе, то почему бы и не опубликовать.

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

Согласен. Писать велосипеды на каждый чих – подход успешного здравомыслящего человека.

Allegro CL спасёт тебя от дурдома LLVM/Rust.

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

Так часто нужно обновлять основу твоего hello world что не выполнить pip update раз в год?

Нет. Это — нарушение авторского замысла в целостности программного обеспечения. Oracle, например, не предполагала, что её JRE где-то будут делить на множество мелких пакетиков, чтобы в одном из них уместить русификаци, к примеру.

Потому что у зависимостей есть зависимости. «151 других приложений» не являются приложениями, это обычные библиотеки. Нет ничего плохого в том, чтобы использовать готовый код и разбивать свой на более мелкие части, если это не усложняет разработку. В С/С++ добавление новых зависимостей затруднительно, многие приложения таскают все свои зависимости с собой. Rust (да и почти каждый современный язык) позволяет не париться с таким подходом. Смотреть на число пакетов вообще не стоит, какие-то из них состоят из одного-двух макросов (cfg_if, например) или типа данных (either).

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

Так часто нужно обновлять основу твоего hello world что не выполнить pip update раз в год?

Так а почему кернел не в зависимостях и не компилируется?

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

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

Тут Simple значит простой в использовании, а не обладает примитивной функциональностью или написан студентом, что не знал про то, что уже нужное реализовано в библиотеках. По зависимостям и видно что и сам за тебя сжатие будет поддерживать, сам угадывать тип файла и указывать в mime type, сам декодить и парсить будет URL с параметрами.

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

Жаваскриптеры набежали и испортили раст? left-pad не появился еще?

была actix-web. автырь правда вовремя бросил истерику и вернул репу взад.

А какой вообще смысл считать [b]количество[/b] зависимостей? Что вам даёт это число? Ну давайте посчитаем количество различных инклюдов в c++ проекте и поохаем

Приравнивать количество зависимостей к количеству инклюдов нет смысла. Ты ещё количество членов к арктангенсу приведи в качестве примера.

Никто их и не приравнивал.

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

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

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

В расте нельзя «удалять» зависимости полностью, так что ситуация как с left-pad невозможна.

Лорчую. Лучшую совокупность простоты, юзабельности и скорости сложно найти.

А бажного говнокода напихать очень даже.

Тогда можно забанить зависимость, например: https://github.com/EmbarkStudios/cargo-deny

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

Откат на предыдущую версию, баг-репорт/PR автору, и продолжаем.

Да, а где невендоренные зависимости никогда не ломаются?

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

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

Во по-этому на этом вашем расте ничего серьёзного до сих пор и не написано. Безответственных хипстерков к таким вещам попросту не подпускают.

Так где зависимости никогда не ломаются? В том же buildroot’е я вижу кучу патчей сторонних библиотек.

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

Неожиданно оно будет только если ты зависимости обновляешь бездумно.

Так какой из этого следует сделать вывод?

Не тащи в проект всё, что попадается на глаза.

В CPython 3 встроенный модуль называется http.server и поддерживает даже CGI. Для тестов должно хватить.

python3 -m http.server --help

Мне даже приходилось реализовывать с помощью этого модуля REST API сервер, все исправно работало, принимает и POST и GET запросы.

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

Не тащи в проект всё, что попадается на глаза.

Так там культура как раз тащить. Поэтому в том числе раст и невменяем.

Не сломается https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lock.html. Ты не в курсе матчасти того о чем пишешь.