Right now, there are zero usage cases in the source tree to require those compiler tools.

Все просто же.

Тео писал, что никто даже не попробовал портировать какой-нибудь маленький тулз на Rust в качестве P-O-C.

Только тут он серьёзно обосрался, да.

I wasn't implying. I was stating a fact. There has been no attempt to move the smallest parts of the ecosystem, to provide replacements for base POSIX utilities.

«I was stating a fact», а погуглить перед этим не смог?

Между прочим, а почему Rust, а не Ada? Многие проблемы в Си из-за которых стали делать Rust давно решены (или их и не было) в Ada. Давно стандартизированный язык, много интересных фич. Годится для embedded. И уж на i386 Ada сама себя точно собирает.

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

Только тут он серьёзно обосрался, да.

Где-то есть полностью OpenBSD-compliant софт на Rust?

4.2

И где там про интеграцию с дистрибутивами?

ЛОР не считается, я не совсем считаю это местом дискуссий

Лор теперь хостится в кладовке госдумы?

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

А вообще, если вдуматься, C и Unix - это довольно странный феномен в ИТ.

Язык Си был придуман, чтобы писать разные системные штучки на PDP-7/11 на чем-то повыше уровнем, чем ассемблер, но при этом без строгостей и дубоватостей тогдашних ЯВУ, но все же поудобнее, чем на bcpl

Unix была придумана как очень облегченный после Multics вариант системы, чтобы играть в игры на PDP-7. Ну еще тексты, чтобы набирать на ней... Изначальный Unix, читал, что был однопользовательским. То есть аккаунтов могло быть много, но одновременно работал только один, собственно потому она и была названа Uni-cs

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

C++ - тоже странный феномен. Бьярни просто взял и прикрутил к Си классы. Получилось нечто уродливое. Хотя уже был и Smalltalk и некоторые другие языки.

C++ - тоже странный феномен.

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

Где-то есть полностью OpenBSD-compliant софт на Rust?

А где-то говорилось про полностью OpenBSD-compliant софт на Rust?

А где-то говорилось про полностью OpenBSD-compliant софт на Rust?

Это в контексте то добавления Rust в base OpenBSD?

Тео потом сказал, что все остальные утилиты которые он знает, это не grep, sed, ls, а какие-то другие програмы, которые украли это имя, потому что они не posix compliant

что на самом деле не так чуть менее, чем полностью — и пробовали, и портировали (uutils или как его там)

Тео даже не погуглил

https://github.com/uutils/coreutils

Между прочим, а почему Rust, а не Ada?

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

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

Это не так.

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

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

Насколько оно функционально и как хорошо работает?

Попробуй, расскажешь нам)

Мне не нужны были, я из переписанного только ripgrep и fd юзаю, которые значительно быстрее своих GNU-братьев (grep и find соответственно)

Так мне тоже особо не нужны :)

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

А что GNAT проходил сертификацию?

Это не важно, он же гнутый, они им не будут пользоваться

Это не важно, он же гнутый, они им не будут пользоваться

Почему это? Вояки вполне пользуются GNAT Pro.

Потому что это фанатики из OpenBSD, а не вояки

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

Сказ о том как дядя Тео пёрнул в лужу.

А что GNAT проходил сертификацию?

Я почти уверен в этом. И думаю, что это стоило им больших денег

Например, кое-что здесь: https://www.adacore.com/products/certification-materials

А что GNAT проходил сертификацию?

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

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

Как я понимаю, наши используют то, чем могут компилировать при любых обстоятельствах и в чем уверены на 100%. А это Си и Си++.

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

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

Прежде всего - Аду никто не знает и изучать не хочет.

А я когда-то фанател от Ada-83. У меня несколько книг есть по ней. Это по сути был один из первых промышленных языков, где появились генерики. Правда, это было сделано многословно и не очень удобно

ваше мнение явно сложилось где-то год назад

Так говоришь как будто это очень давно. У nix-а другой масштаб времени, геологический

Но то что Ржавый двигается в этом направлении уже хорошо. А что там с либами? Как и во всех новомодных языках — своя вариация на тему pip/npm и сотня зависимостей подтянутых с гитхаба для любого проекта масштабнее хеловорда?

Так говоришь как будто это очень давно.

Учитывая что языку меньше 3 лет, да, это очень давно.

Как и во всех новомодных языках — своя вариация на тему pip/npm

Да

сотня зависимостей

Да, и это правильно, нехер в stdlib тащить всё подряд

подтянутых с гитхаба

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

Правильно пишет.

Долой жирные программы.

хорошо, что есть еще островок адекватности в опен сорсе в лице опенбзд.

У меня Rust на FreeBSD нужен только для запуска новейших версий Firefox. Больше ни для чего. Rust компилируется порядка 2 часов, Firefox-esr - полчаса. По-моему, выбор очевиден.

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

Между прочим, а почему Rust, а не Ada?

Потому что после Ada были: Opject Pascal, Modula 1/2/3, Oberon 1/2, Active Oberon, Zonnon, Go. Теперь понимаешь, почему Ada далеко не нужен?

Точно так же как и у обычных C++ных утилит, зависящих об всяких бустов итд.

Серьезно, какие объективные претензии есть к такому подходу? Удобное переиспользование кода — это плохо?

30-40 в среднем проекте, в мелкотне обычно 10-20, над реально крупными не работал, но реально крупные обычно уже на своих либах сидят (которые становятся в итоге частью публично доступной экосистемы, см. servo) помимо минималочки необходимой средняку потому что есть бабло на их разработку.

Ну и чем больше у проекта потребностей в интероперабельности с другими сервисами, тем больше: протоколы, итд. И это удобно — не нужно качать в дерево либы и менеджить руками: наличие нужного пакета нужной версии в хранилище гарантирует стабильность API в пределах минора/мажора

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

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

−20 бы тебе вручить — за неуважение к Ъ.

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

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

Возможно золотая середина в том что бы разделить либы на три типа:
1) Стандартная библиотека с базовыми вещами;
2) Расширенная стандартная библиотека покрывающая потребности большинства типовых проектов и плотно контролируемая разработчиками языка и умерено замороженное;
3) Всякое прочее, либо ещё слишком сырое, либо слишком специфичное для второй категории;

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

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

Удаление пакета с crates.io невозможно.

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

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

Тут нет такого звездеца как с pip и cpan, где пакетный менеджер дистра конфликтует с установленными руками пакетами через pip и наоборот: крейты нужны только в билдтайме, рантаймовые зависимости сводятся к базовым либам, которые есть в пакетной базе дистрибутивов в любом случае: openssl, libgit2, mysql-connector, ...

Стандартная библиотека с базовыми вещами;

Есть

Расширенная стандартная библиотека покрывающая потребности большинства типовых проектов и плотно контролируемая разработчиками языка и умерено замороженное;

Есть, некоторые проекты курируются и пилятся напрямую членами команды разработки языка и являются стандартом для своего спектра задач (см serde, futures, hyper). Ну и если что-то выходит за рамки маргинальщины и входит в мейнстрим — это стараются в близжайшее возможное время довести до 1.0 и заморозить API, как это произошло с serde пару месяцев назад.

То есть библиотеки, которые либо используюся повсеместно напрямую (serde) либо являются основой для разработки более юзер-френдли абстракций (hyper, futures, tokio).

3

Ну в этим ясно

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

Он 0.1.* не потому что кривой и не работает а потому что API не идеален и subject of change.

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

Не кажется, что это больше надуманная проблема?

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

Прям посмотрит с полноценным аудитом, а не мельком

Тут можно резонно заметить, что дистрибутивов херова туча

Но за раз используется только какой-то один. Используя Debian мне не нужно доверять мейнтейнерам Fedora

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

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

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

с их подходом к экосистеме :>

А что с ним?

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

Мейнтейнер дистрибутива это промежуточное звено между автором и пользователем в котором можно как то аудитить код. В npm-подобных подходах аудит может производить только сам пользователь (тот самый который до этого сделал curl | sh -).

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

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

Никто не запрещает мейнейнерам развернуть свой регистр пакетов прошедших аудит. Пользователи/мейнтейнеры будут брать пакеты из него. В таком случае, сложность добавления пакета в репозиторий будет равна сложности cargo build --features LIST. В редких исключениях будут заявки на аудит пакетов для добавления в регистр.