Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cross-platform Rust rewrite of the GNU coreutils

github.com

Post reply on HN
Print view View original

41–50 of 498 posts

Re: Cross-platform Rust rewrite of the GNU coreutils

#41

Post by jblow »

steveklabnik wrote: post #34
z3phyr wrote: post #19

Rust is a fine language, no doubt. What worries me is the exact rewrite of the C code using the unsafe construct. Also a little out of topic; Can more light be shed by fellow HNers on the debugging tools for rust, the debugging experiences from the security research point of view?

It looks like there are 134 instances of 'unsafe', in 23,000 lines of Rust. And it looks like a lot of that unsafe is to FFI into libc. Rust works with GDB, so you end up debugging like anything else. IDE integration is being actively worked on, and sorta-kinda works in my understanding.

What is the roadmap on getting rid of the need for libc? Given how terrible libc is, I personally would make that a high priority, though I guess in Linux you can't even start up a process without libc (maybe that is a misunderstanding?), which makes the situation less clean, but at least you could get to a point where you never call back into it after entry into main.

Re: Cross-platform Rust rewrite of the GNU coreutils

#42

Post by plugnburn »

faaef wrote: post #2

It certainly beats using NodeJS. EDIT: Yea, this was meant as a reference to the coreutils-in-nodejs post on the frontpage.

NodeJS is for applications, Rust is for system programming. How does one beat another?

It's akin to saying "ARMv7 assembly beats using Java for Android programming".

Re: Cross-platform Rust rewrite of the GNU coreutils

#44

Post by steveklabnik »

jblow wrote: post #41
steveklabnik wrote: post #34

Earlier quoted context omitted.

It looks like there are 134 instances of 'unsafe', in 23,000 lines of Rust. And it looks like a lot of that unsafe is to FFI into libc. Rust works with GDB, so you end up debugging like anything else. IDE integration is being actively worked on, and sorta-kinda works in my understanding.

What is the roadmap on getting rid of the need for libc? Given how terrible libc is, I personally would make that a high priority, though I guess in Linux you can't even start up a process without libc (maybe that is a misunderstanding?), which makes the situation less clean, but at least you could get to a point where you never call back into it after entry into main.

I don't know what this project's stance is towards libc.

Re: Cross-platform Rust rewrite of the GNU coreutils

#47

Post by protomyth »

coldtea wrote: post #40
masklinn wrote: post #4

Rewriting coreutils is neat, but a project I'd really look forward would be a strict POSIX base expanded with warnings or errors on valid but risky constructs e.g. echo -n. Even more so if it included a shell (with static analysis of useless uses and dangerous patterns). That would make writing cross-shell scripts much easier.

What exactly is this thing with 3 people commenting "I'll bite"? How is that the most obvious response to parent's observation about echo?

"I'll bite" is a pretty common response when someone says something without elaboration that you sense they really want to follow up on. Maybe its a regional thing, but I'm having a bit of a problem thinking of another phrase.

Re: Cross-platform Rust rewrite of the GNU coreutils

#48

Post by stepvhen »

gbersac wrote: post #11

Is there a real need for this project ? I mean, this project has been used for a long time, could it really be better ? Do you intend to replace GNU coreutils ? Not to be mean, just a genuine question (and yes I read the Why section of the readme).

Multiple people have sought to rewrite coreutils, whether it be for fun, exercise, or out of frustration with the current utils. I know folk on 4chan's /g/ were rewriting them once, and the people at suckless are trying to do the same, only with a lot of options and features stripped out due to "bloat" (my word not theirs).

Your second question presumes that just because something is old means it is the best. Traditional things can indeed work out well, but challenging tradition is how progress is made. And you can't know if the coreutils can be improved if you don't try, right?

Re: Cross-platform Rust rewrite of the GNU coreutils

#49

Post by [deleted] »

niccaluim wrote: post #37
gravypod wrote: post #21

I'd really love to use rust, given the large growth of projects like this. I only need an IDE to get started, but it seems like there isn't one yet. Anyone have any pointers on where I can find a good IDE for Rust? Should I just start praying to lord-JetBrains for something that works?

If you've never programmed without an IDE I strongly encourage you to give it a go. You'll learn a lot! [Good lord, a downvote on this? I'm being completely sincere.]

[deleted]

Re: Cross-platform Rust rewrite of the GNU coreutils

#50

Post by saosebastiao »

niccaluim wrote: post #37
gravypod wrote: post #21

I'd really love to use rust, given the large growth of projects like this. I only need an IDE to get started, but it seems like there isn't one yet. Anyone have any pointers on where I can find a good IDE for Rust? Should I just start praying to lord-JetBrains for something that works?

If you've never programmed without an IDE I strongly encourage you to give it a go. You'll learn a lot! [Good lord, a downvote on this? I'm being completely sincere.]

I learned how to program without an IDE, and I'm a pretty big fan of it. And strongly typed functional languages with type inference tend to be really easy to write and refactor without needing specialized IDE tasks for the job.

That being said, nowadays I use an IDE because it is extremely helpful to have autocomplete (which is okay with Racer+Vim, but kinda hacky) as well as the hover for type information (name of types, type signature, etc.). Without the hover information, I usually end up doing ridiculous things like writing bogus explicit types to see what type an undocumented function from a library will return after compiling (Is it Option? or Result?). That is really annoying.

I didn't downvote you BTW.

Post reply on HN