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

131–140 of 498 posts

Re: Cross-platform Rust rewrite of the GNU coreutils

#131

Post by cbsmith »

kbenson wrote: post #76
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

Prof. Regehr did not find problems with SQLite. He found constructs in the SQLite source code which under a strict reading of the C standards have “undefined behaviour”, which means that the compiler can generate whatever machine code it wants without it being called a compiler bug. That’s an important finding. But as it happens, no modern compilers that we know of actually interpret any of the SQLite source code in…

Really, if your project intends to be portable C code, you need to compile it with undefined behaviour generating an error.

Re: Cross-platform Rust rewrite of the GNU coreutils

#132

Post by jandrese »

ape4 wrote: post #51
masklinn wrote: post #36

Earlier quoted context omitted.

http://www.in-ulm.de/~mascheck/various/echo+printf/ is the raw data version. POSIX defines echo as only taking string parameters and no options, but notes that behaviour facing `-n` is implementation-defined. BSD and GNU echo implement `echo -n` as not printing a trailing newline, but `echo` commonly calls to a shell builtin which may or may not follow that behaviour (and may switch behaviour depending on whether the…

Whoever wrote the POSIX spec was too conservative. -n should mean no newline(s). Anything else is wrong.

The POSIX spec is basically the minimal intersection of all commercial UNIX distros of its day. It defines a minimal system that happened to be what everybody already had implemented. For the most part you are allowed to add features to a POSIX base to make a real OS, since that's what everybody had.

This is also why the old Windows POSIX subsystem was so useless. It implemented only the minimal amount needed to check off the box on a feature list, and none of the stuff you need to actually make a system usable.

That said, POSIX has a fair bit of braindamage baked in and people can be excused for ignoring the worst parts and instead doing the right thing.

Re: Cross-platform Rust rewrite of the GNU coreutils

#133

Post by bigdubs »

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

Though I like ideas behind Rust but the code is awful. If you look at the code you'll see a lot of misterious symbols (as in Perl) and strange constructs like wrap, unwrap, Arc etc. They make the code less readable. Also Rust doesn't have exceptions so you have to wrap almost any function call with let/match/Ok/Err. Ugly. I looked at one random file which turned out to be a `du' command implementation: https://github…

>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…

Comment OP's stance is valid. "Magic" in this context are keywords or symbols that are not immediately clear to programmers that don't work in rust. One of the reasons golang is so successful is that there is very little magic in the syntax, and even when there is it's fairly easy to grok (an example would be the `go` keyword).

FWIW I also share their opinion that rust is unapproachable.

Re: Cross-platform Rust rewrite of the GNU coreutils

#134

Post by codedokode »

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

Though I like ideas behind Rust but the code is awful. If you look at the code you'll see a lot of misterious symbols (as in Perl) and strange constructs like wrap, unwrap, Arc etc. They make the code less readable. Also Rust doesn't have exceptions so you have to wrap almost any function call with let/match/Ok/Err. Ugly. I looked at one random file which turned out to be a `du' command implementation: https://github…

>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.

Re: Cross-platform Rust rewrite of the GNU coreutils

#135

Post by aidenn0 »

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…

Even with overcommit on, malloc can return NULL on linux.

Re: Cross-platform Rust rewrite of the GNU coreutils

#137

Post by jfoutz »

gkya wrote: post #109
micampe wrote: post #84

Earlier quoted context omitted.

I could see preferring svn to git because of the simpler model, but cvs ? No thanks, a vcs without atomic commits is not much better than snapshot archives, maybe worse actually.

For my use case, it's way more preferrable: a) SVN seems daunting and complex, tho I didn't ever dive into it. CVS is so simple and easy, a half-arsed programmer like me can actually understand it. Things like git and mercurial are way more complex. b) RCS is real handy for single files, e.g. a free-standing text file or shell script. But when the thing grows up, it is very easy to integrate the fileset into a CVS re…

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's not worth it.

2. offline diffs. svn has a whole copy of the repo, so you can compare history even if the central repo is down, or you're working from the beach. This one is pretty nice regardless.

svn is a pretty nice upgrade, if you're working with a distributed team.

Re: Cross-platform Rust rewrite of the GNU coreutils

#138

Post by pcwalton »

catawbasam wrote: post #128
pcwalton wrote: post #95

Earlier quoted context omitted.

Disappointing to see Hipp make that argument. It's trivially refuted. Yes, all programming languages allow the programmer to write bugs. But languages very much vary in how many , and what kinds of bugs programmers write in practice . Saying "well, Rust doesn't eliminate all bugs" is attacking a straw man. If you want to argue that Rust isn't worth it, you need to convince me that C plus gcov results in fewer bugs in…

'Saying "well, Rust doesn't eliminate all bugs" is attacking a straw man.' This is itself a straw man. Follow the link to Mr. Hipp's comments and read them. He did not say this. That a programmer who has produced such high-quality and rigorously tested software as sqlite should be portrayed as either cavalier or naive about software quality is something I find profoundly mis-guided.

> This is itself a straw man. Follow the link to Mr. Hipp's comments and read them. He did not say this.

"Rust doesn't eliminate all bugs" is a rephrased version of "Some well-formed rust programs will generate machine code that behaves differently from what the programmer expected."

> That a programmer who has produced such high-quality and rigorously tested software as sqlite should be portrayed as either cavalier or naive about software quality is something I find profoundly mis-guided.

I don't think he's cavalier or naive about software quality! SQLite's quality speaks for itself, and he is completely correct about what you need to do to achieve the level of correctness that SQLite has. He knows a lot more than I do about the rigor needed to ensure that amount of software quality. I do think, though:

1. The amount of testing that SQLite undergoes is not economically feasible for most software.

2. Rust's testing tools would allow for the same level of code quality in the absence of evidence otherwise. (The example he cited, code coverage, is wrong, as kcov is available for Rust.)

3. There is value in static analysis above and beyond the value of testing (also vice versa), because testing only reveals bugs that manifest themselves in inputs available in the test suite. This is true regardless of the code coverage of the tests.

In other words, I think Hipp's argument would make sense if it were something along the lines of: "I couldn't test a Rust SQLite as well as I can test the existing SQLite because kcov is missing features X, Y, and Z, and the value I get from the static analysis is less than the value I get from those code coverage tools, since we've found lots of bugs from those code coverage features and haven't found as many memory safety/data race bugs". That'd be totally valid. But as a blanket statement that Rust would make things worse, it doesn't make sense to me.

Re: Cross-platform Rust rewrite of the GNU coreutils

#139

Post by codedokode »

bigdubs wrote: post #133
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…

Comment OP's stance is valid. "Magic" in this context are keywords or symbols that are not immediately clear to programmers that don't work in rust. One of the reasons golang is so successful is that there is very little magic in the syntax, and even when there is it's fairly easy to grok (an example would be the `go` keyword). FWIW I also share their opinion that rust is unapproachable.

Golang has some magic too - for example magic with capital letters in exported symbols. But generally golang is easier to read than line like this:

> static NAME: &'static str = "du";

Re: Cross-platform Rust rewrite of the GNU coreutils

#140

Post by ktRolster »

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…

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

Clarifying note: this is configurable.

Post reply on HN