Unix core utilities implemented in Haskell

I read your blog. Maybe you should take a look at some of the other utils. I worked on sort and ls and both have long been faster than their GNU equivalents.

> They don't seem to get enough experienced programmers fixing them up or usage for me to actually recommend anybody use them, but maybe that's changing.

The issue is obviously compatibility and the uutils won't be broadly "usable" or stable until is hits 100% PASS/0% FAIL on the GNU test coverage, although the numbers are getting better and better. See: https://raw.githubusercontent.com/uutils/coreutils-tracking/...

> A lot of the Rust coreutils were written by people learning the language,

I really, really hate this way of framing the project -- which implicitly sounds like GNU is full of pros. Yes, lots of code was written by people just learning Rust and systems programming. Once it reaches parity on GNU test coverage, which it is rapidly approaching, GNU coreutils would wish it had this kind of enthusiasm behind it.

> and the code is often _more_ complicated than the corresponding code for the Unix utils.

I think it really depends. Much of the code is much simpler. For instance -- I think it's much easier to generically do hashing in Rust, and it shows.

I get what you're saying, but I don't care how it's called. Some things must die. Eg. Python 3 and the depreciation of was a very controversial step, but ultimately the right choice at the right time.

For one thing, a "string" in Haskell by default is a linked list of unicode characters, so right out of the gate you've got big performance problems if you want to use strings. The exact way laziness is done also has serious performance consequences as well; when dealing with things as small as individual characters all the overhead looms large as a percentage basis. One of the major purposes of any of the several variants of ByteString is to bundle the bytes together, but that means you're back to dealing with chunks. Haskell does end up with a nice API that can abstract over the chunks but it still means you sometimes have to deal with chunks as chunks; if you turn them back into a normal Haskell "string" you lose all the performance advantages.

It can still come out fairly nice, but if you want performance it is definitely not just a matter of opening a file and pretending you've just got one big lazy string and you can just ignore all the details; some of the details still poke out.

C is simple enough to know what is going on, IMO.

For example:

    numbers = [1, 2, 3, 4, 5]
    squared_numbers = [num * num for num in numbers]
    print(squared_numbers)

    fn main() {
        let numbers = vec![1, 2, 3, 4, 5];
        let squared_numbers: Vec<i32> = numbers.iter().map(|&num| num * num).collect();

        println!("{:?}", squared_numbers);
    }

    #include <stdio.h>

    int main() {
        int numbers[] = {1, 2, 3, 4, 5};
        int squared_numbers[5];
    
        // Squaring each number
        for (int i = 0; i < 5; i++) {
            squared_numbers[i] = numbers[i] * numbers[i];
        }
    
        // Printing the squared numbers
        printf("[");
        for (int i = 0; i < 5; i++) {
            printf("%d", squared_numbers[i]);
            if (i < 4) printf(", ");
        }
        printf("]\n");

        return 0;
    }

What I am trying to say is that the C implementation is more straightforward, IMO.