Programmer Humor

hideshow 6 child comments

parent

[–] KindaABigDyl@programming.dev 17 points 3 weeks ago (1 child)

were forthcoming about shelling out the real work to c

When did they shell out "real work" to C?

There is no C in the repo: https://github.com/uutils/coreutils

They aren't wrapping the GNU coreutils in a Rust shell; it's a total unaffiliated reverse-engineering

parent

[+] cockmushroom@reddthat.com [S] -19 points 3 weeks ago (1 child)

I forgot where I suggested that libc was a coreutils project but, if you find it, let me know and I'll be sure to make the apology and corrections, mr crabby pants.

parent

[+] expr@programming.dev 1 point 3 weeks ago

[deleted]

parent

[–] edinbruh@feddit.it 12 points 3 weeks ago (1 child)

I would like to interject for a moment. What you are referring to as coreutils Is actually coreutils+libc+Linux... And fill the rest yourself.

The "anti rust" crowd spends half of their time yapping about how you still need c in some places, then why did you get upset with calling into libc here? Are you suggesting to rewrite every rust program in C so you can have only c calling into c?

parent

[–] cockmushroom@reddthat.com [S] 1 point 3 weeks ago (1 child)

Generally I don't consider myself anti rust as a technology, and/since many of my favourite tools happen to be written in it. Consequently, I don't generally fall into the critics of c/unsafe usage.
That said, for the purpose of understanding the point being raised, it's important to understand the difference between uutils, its philosophy, and rust at large. This isn't just an arbitrary rust project, it's one that specifically claims to replace a C project. Is it the kind of thing I would encourage use of rust for? Absolutely not and I don't hold any ill will to people pursing these, or similar, projects for pedagogical reasons. That's not what uutils is or aims to be though. If the language's system API isn't ready for this sort of project, then I think that would be a more fruitful use of these people's time and whatever funds the project maintainers are collecting. I'm just a bum though, so don't mind me.

parent

[–] edinbruh@feddit.it 7 points 3 weeks ago (1 child)

Well, if you want to be pedantic, I'll entertain you a bit more.

You see, C and Unix were "born" together. So sometimes, POSIX intertwines them in weird ways. In this case, getlogin is declared in unistd.h because it's part of the Unix standard API, however the POSIX standard states that it must be implemented in libc. So the POSIX compliant way to getlogin is to call into libc, which doesn't need to be glibc, you could use musl and avoid the GNU dependencies. If rust's stdlib were to offer a getlogin function, the proper approach would be to still call libc. It's like if on windows you were to call into Win32 to getuser, except on *nix it's the same file as libc.

If you want to replace the getlogin implementation, the POSIX compliant place to do it is not in coreutils but in libc, like the aforementioned musl library does.

So the key here is that getlogin is not art of the c system API. It is actually part of the POSIX APIs, it is just "located" inside of libc, which by the way, does not need to be GNU if you are concerned with uutils' philosophy.

parent

[–] cockmushroom@reddthat.com [S] -2 points 3 weeks ago (1 child)

I don't think I do want to be pedantic but, to be explicitly clear, the philosphy I'm associating with uutils is capured by the "rewritie it in rust" mantra, so whether or not their posix compliant interface uses GNU code is beside the point.

More importantly, if their goal was a posix compliant api, then I'd have assumed they would have included that in their repo description, or even called the project posix.rs; but they didn't. What's more is that the rust standard library isn't equivalent to that of C, so it would still make sense that for a project whose goal was, or has simply become, to replace a C codebase would offer a safe C alternative to its dependencies. But maybe that's their next step; an internal library offering enough of a posix api to avoid surprises like these.

parent

[–] edinbruh@feddit.it 7 points 3 weeks ago

Not at all. I would not expect any riir project to reimplement the entire stack in rust. This is not calling a random C dependency. This is literally calling the OS's API. Literally there's just this and the kernel.

As you said its goal is to rewrite a C codebase. The C codebase is coreutils. The correct way to getuser is to use the OS's API, which happens to be inside libc.so, which has nothing to do with coreutils, it's an entirely different codebase. End of the story. The OS's API needs to be exposed as a c library, because c is the only language that can be imported from any other language. If you were to rewrite it in rust, it would use extern 'C' and it could not be any other way. And uutils would still import it from libc.

Maybe one day we'll see a rust rewrite of libc (tho it doesn't make much sense), but this has nothing to do with uutils.

If you are asking for a rust wrapper around the correct way to getuser, you have literally posted it. You can find it in uutils.

Also, being compliant is just being compliant. I wouldn't expect it to be called something like POSIX.rs unless it were implementing every part of POSIX. Which is clearly not what we have here. Or are you suggesting that bash should be called POSIX.c, because it's in c and it's POSIX compliant?

parent

[+] KindaABigDyl@programming.dev 1 point 3 weeks ago

[deleted]