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

Так отлична же причина!
Линукс начал очищаться от запретительной GPLv3 в пользу свободных лицензий.
Как тут не порадоваться))

А заодно со временем избавится от гнутых версий util-linux, diffutils, findutils, procps, acl, sed и login. Плюс заменит древнюю дыряху на нормальный язык.
Шикарно же! Тот линукс, о котором мечтают все адекватные люди.

Да, так и есть. Простые вещи порой понять очень сложно.

Так с date и было "было пучком" на момент написания что "всё пучком".
А почему убунтоводы взяли версию месчной давности - вопрос к убунтоидам.

Ну и нужно понимать что это за цифры. Это успешность прохождения тестового набора GNU Coreutils. Если что-то тестом не покрыто, то отличие в имплементации будет даже при 100% прохождении тестов.

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

> Если изначально люди делали которые без unsafe не осилили...а зачем тогда вообще брались

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

Ох уж эти опеннетные непризнанные гении от п(р)ограммирования. ls на 5(!) с гаком тыщ строк им тривиален 🙄
https://cgit.git.savannah.gnu.org/cgit/coreutils.git/tree/src/ls.c
tail на 2500 тоже ...
как в прочем и date c вооот-такенным маном и поддеркой RFC/ISO/локалей/часовых поясов (и их сокращений) и т.д и т.п.

Как жаль, что гении не пишут код ☹

Что-то лучше, что-то хуже.

Напр. base64 медленнее на некоторых больших файлах.
А tr была в 9.8x slower, а сейчас в 1.58x faster.
sort: 3.72x faster (regular), 1.46x faster (numeric)
factor - медленнее

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

Интересно, а что с размером бинарников, по сравнению с GNU Coreutils?

c-ward

> gcc

clang

> bash

fish

'''
// libc api (unsafe, requires handling return code/errno)
pub unsafe extern fn gethostname(name: *mut c_char, len: size_t) -> c_int;

// nix api (returns a nix::Result<OsString>)
pub fn gethostname() -> Result<OsString>;
'''

То есть: libc дает лезвие, острое, заточеное со всех сторон и без ручки. Nix обматывает лезвие армированой изолентой. Не то, чтобы очень удобно, но хоть порезаться шансов меньше.

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

Напр. gethostname (github.com/nix-rust/nix/blob/master/src/unistd.rs#L1332)

Создали буфер, сделали unsafe запрос, убедились что результат null-terminated, вернули или его, или ошибку.
И так бы это все пришлось писать в каждом вызове gethostname.

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

Ну ты б ещё им лисп с окамлом предложил. )

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