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

171–180 of 498 posts

Re: Cross-platform Rust rewrite of the GNU coreutils

#171

Post by habitue »

codedokode wrote: post #134
0xFFC wrote: post #127

Earlier quoted context omitted.

>Also Rust doesn't have exceptions so you have to wrap almost any function call with let/match/Ok/Err. Ugly. respectfully, This is pure nonsense. First of all rust does not have runtime and AFAIK for providing exception you should have runtime to manage stack. Second not every language should be like high-level languages, it is not the rule to be like C#,Java,Python,etc. I use a lot of them for my work when I need si…

I mean if you have to write that match construct around every function call the code quickly gets bloated, doesn't it? And that is not good.

Rust has macros, so boilerplate can be swept up pretty tidily. In the case of propagating up errors, there is the try! macro that encapsulates a match that returns early with the error

Re: Cross-platform Rust rewrite of the GNU coreutils

#172

Post by DrJokepu »

wyldfire wrote: post #154
quotemstr wrote: post #99

Earlier quoted context omitted.

Rust is a terrible choice. Its standard library assumes malloc never fails.

I suppose this coreutils impl doesn't do it but one could perhaps use rust w/o its standard library and use strictly some libc instead. Would probably still be a net win.

Writing Rust code interfacing libc is a rather frustrating experience though. Many libc interfaces use constructs that Rust really wants you to avoid (for very good reasons), things such as global mutable variables (errno and for callback functions without context pointers) or union types. I know about at least one cargo crate attempting to "Rustify" libc with some level of success.

None the less, this is what I typically end up doing when writing Rust code as much of th Rust standard library is simply not ready for "serious" usage.

Re: Cross-platform Rust rewrite of the GNU coreutils

#173

Post by rhelmer »

Redox has been working on smaller, more BSD-like versions of the basic Unix utilities, also written in Rust:

https://github.com/redox-os/coreutils

I am excited to see this as I was working on a similar project last year (rewriting the BSD userland in Rust), but it's from pre-1.0 Rust so not really as idiomatic as what is coming out of the Redox project.

Re: Cross-platform Rust rewrite of the GNU coreutils

#174

Post by nickik »

wangchow wrote: post #160
thegeomaster wrote: post #12

Earlier quoted context omitted.

Not sure why you're being downvoted. I don't see why we shouldn't be moving to languages like Rust given the chance, as C makes it far more difficult to write safe and correct code.

Difficulty is relative. If you don't study modern C idioms your C code will be crap. Same goes for Rust. Honestly using higher-level languages is the same mentality as taking a pill to magically lose weight. It's quick, but detrimental (to programmers ability) in long term. Programming becomes easy but in the long term most people forget how algorithms and data structures work, in addition to cache mechanisms and oth…

I disagree. When programming C you have to remember so much stuff and be so carful about even the simplest things, this mental effirt takes from your resources, and I dont care how good a C programmer you are.

The mental capacity saved can be invested in higher level design issues that gone get you a lot more in the long run.

Re: Cross-platform Rust rewrite of the GNU coreutils

#175

Post by nickpsecurity »

steveklabnik wrote: post #118
haberman wrote: post #110

Earlier quoted context omitted.

This is downvoted, but I'd rather see it refuted. Is this false? Is SQLite as written tolerant of malloc() failure?

The Rust standard library does assume that allocation succeeds. The language itself knows nothing about the heap, and so you can write allocators that do whatever you wish. Side note: on most Linux distros, overcommit is on, and so malloc will basically always succeed; the OOM killer will kill your program before you'd get a failure. I am less knowledgeable about OSX and Windows. I cannot speak to SQlite in this rega…

Holy crap, I'd never have imagined that... A design that assumes allocation always succeeds flies in the face of decades of safety/security-critical coding wisdom. I strongly recommend the team revisit and change that somehow to account for failures, NULL's, whatever. Actually, same anywhere a failure-prone, esp hardware, resource is acquired. C apps can handle this issue so Rust should as well if it's to replace them.

EDIT: Thanks to replies for clarification that it's just one allocator, aborts, and others are available. Still feel weird about it but that's better.

Re: Cross-platform Rust rewrite of the GNU coreutils

#176

Post by tmerr »

codedokode wrote: post #134
0xFFC wrote: post #127

Earlier quoted context omitted.

>Also Rust doesn't have exceptions so you have to wrap almost any function call with let/match/Ok/Err. Ugly. respectfully, This is pure nonsense. First of all rust does not have runtime and AFAIK for providing exception you should have runtime to manage stack. Second not every language should be like high-level languages, it is not the rule to be like C#,Java,Python,etc. I use a lot of them for my work when I need si…

I mean if you have to write that match construct around every function call the code quickly gets bloated, doesn't it? And that is not good.

Yeah Error handling bloat is a problem.

You can use convenience functions: expression.expect("panic with this message if expression evaluates to an Err")

You can also use macros: try!(expression) makes it so if expression evaluates to an error it returns the error immediately, otherwise it does nothing.

This approach is still more verbose than using exceptions but on the flip side dealing with errors up front can make it easier to write reliable code.

Re: Cross-platform Rust rewrite of the GNU coreutils

#177

Post by teraflop »

nickpsecurity wrote: post #167
masklinn wrote: post #39

Earlier quoted context omitted.

I expect it's because because the first part is essentially preaching to the choir, and because Richard Hipp very much disagrees with the second part[0] > Rewriting SQLite in Rust, or some other trendy “safe” language, would not help. In fact it might hurt. (see link for expansion on that matter, which is a question of tooling and testing) [0] http://blog.regehr.org/archives/1292#comment-18452

Wow. I was surprised that comment came from a smart, accomplished guy. It's nonsense. What he's essentially saying that the existence of compiler bugs in Rust refutes using it as a C alternative. Let me try that: the existence of hundreds of compiler bugs in C compilers over past years means it can be relied on either. CompCert had a few at spec level so we throw it out, too. Realistically, you rewrite the components…

> What he's essentially saying that the existence of compiler bugs in Rust refutes using it as a C alternative.

That is not at all what Hipp's comment says, and the original author's response to it gives it a much more charitable reading than you seem to be.

Re: Cross-platform Rust rewrite of the GNU coreutils

#178

Post by ktRolster »

amelius wrote: post #62
mapleoin wrote: post #22

What are the licensing implications for this kind of work? I assume the authors used GNU coreutils as more than just inspiration. They probably read all the original code and reused some of the solutions (obviously ported to Rust). Shouldn't the derivative work still be covered by the GPL?

Isn't this the same question as Google copying the API of Oracle's Java libraries?

That case is still ongoing. Right now they are fighting it out in a district court, trying to decide who will be on the jury, and whether or not statutory damages should be decided.

Re: Cross-platform Rust rewrite of the GNU coreutils

#179

Post by jfoutz »

gkya wrote: post #153
jfoutz wrote: post #137

Earlier quoted context omitted.

there are two things that are nice about svn if you use it just like cvs. 1, atomic commits. I edit ten files, that's one checkin, rather than the per file checkins of cvs. On a low volume project, not a big advantage. if you've ever conflicted on a bigger project with cvs, it can be kind of a pain to resolve. seeing the whole commit of the other guy is helpful. If you don't run into this more than, say, monthly, it'…

All appreciated, but nowadays my biggest repo is my emacs config, some tens of thousand SLOCs, about 2000-2500 of which I authored (I commit packages I use too, no elpa). And my repositories are local, i.e. they are in /var/cvsrepos. Other than that, I admit that SVN is indeed superior. I believe that one should use the best tool for the case, not the overall best tool in every case. That said, I'll give a look at SV…

If it's just you, everything is local, it's probably not worth the overhead. Sounds like you have a good, efficient setup.

If you're learning for the sake of learning, i'd dig into git. i'm getting better, but some cases still frighten me.

Re: Cross-platform Rust rewrite of the GNU coreutils

#180

Post by mzs »

gkya wrote: post #143
heavenlyhash wrote: post #119

Earlier quoted context omitted.

Open source is useless if the majority of people in the open community -- for whatever reason -- can't build it. If a person can't build the thing, they effectively have no power to contribute to changing it. If they have no power to contribute to changing it, it's... spiritually, missing the most essential parts of open source. This is the fundamental issue driving comments like the quote above. You can tell me that…

This project does not really improve upon the situation, as it uses what it is to replace for building, and a very complex Makefile where there's no need for one. I've said nothing about dependency management as in fetching code that the project depends on. I'm talking about compilation dependencies, i.e. file a.o depends on a.c, a.h, b.c and b.h. Make is for this: a.o: a.c a.h b.c b.h cc -o ${.TARGET} ${.ALLSRC} But…

On line 4 ifneq appears which is a GNU make feature. .ALLSRC is a BSD feature. It's a fine GNU makefile. Also you should look at Cargo.toml to see better what is going on.
Post reply on HN