> For consistency purposes. We're not interested in a license debate and will continue to use the MIT license, as we did with [our] Coreutils.
Putting this much good effort into building a strong implementation of the core Unix utilities under a permissive license is frankly kind of a shitty thing to do and is part of the reason why there is such a philosophical barrier to getting this kind of work fully upstreamed: the goal of the original coreutils wasn't merely to have high-quality portable Unix utilities, it was to ensure we'd always have them, as they belonged to the community in a way that permissively licensed code can never be... and, further, they've provided an incentive for operating systems that might otherwise end up as a locked/proprietary system to be forced open (an effect that would have been even stronger if only anyone had predicted the need for GPL3 back decades earlier), lest they have to put up with the less fully-featured BSD tooling. In a very real sense, the license is not even just a feature of the tooling: it was its defining feature, and it should be worth considering as part of "bug-for-bug compatibility".
"Rust offers several advantages over C/C++, particularly in terms of memory safety, concurrency, and performance."
Coreutils have been written in plain C.
Rust offer several advantages over C and C with classes from '90s, which is known in some circles as C++.
Modern C++ standards offer excellent memory safety, which is not too far from Rust's. Especially since we have smart pointers, move semantics, and great STL containers, it can be used securely.
C and C++ have always offered best performance. Coreutils performance was and is great, with the caveat described below.
C and C++ were always able to offer concurrency, but that was not easy. Rust excels here, especially with async/await. Majority of Coreutils programs are not multithreaded.
Were Coreutils written in modern C++, they would have had no need to rewrite to Rust. It is reluctance (or inability) to use modern C++ in these projects responsible for bugs and security issues.
The size of produced binaries is smallest with C. And it sometimes matters a lot.
> For consistency purposes. We're not interested in a license debate and will continue to use the MIT license, as we did with [our] Coreutils.
Putting this much good effort into building a strong implementation of the core Unix utilities under a permissive license is frankly kind of a shitty thing to do and is part of the reason why there is such a philosophical barrier to getting this kind of work fully upstreamed: the goal of the original coreutils wasn't merely to have high-quality portable Unix utilities, it was to ensure we'd always have them, as they belonged to the community in a way that permissively licensed code can never be... and, further, they've provided an incentive for operating systems that might otherwise end up as a locked/proprietary system to be forced open (an effect that would have been even stronger if only anyone had predicted the need for GPL3 back decades earlier), lest they have to put up with the less fully-featured BSD tooling. In a very real sense, the license is not even just a feature of the tooling: it was its defining feature, and it should be worth considering as part of "bug-for-bug compatibility".