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

121–130 of 498 posts

Re: Cross-platform Rust rewrite of the GNU coreutils

#121

Post by codedokode »

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.com/uutils/coreutils/blob/master/src/du/du.rs...

Are they really starting a new OS level thread for every directory found? Looks like an easy way to exhaust system resources to me. Also I don't see the code that would collect error information if if the thread panics.

Re: Cross-platform Rust rewrite of the GNU coreutils

#122

Post by Dylan16807 »

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…

It's still important to distinguish the two. The source code has bugs, but in the year 2016 it builds binaries that do not have bugs.

Re: Cross-platform Rust rewrite of the GNU coreutils

#123

Post by gkya »

geofft wrote: post #105
_pfxa wrote: post #67

> Many GNU, Linux and other utils are pretty awesome, and obviously some effort has been spent in the past to port them to Windows. However, those projects are either old , abandoned, hosted on CVS , written in platform-specific C, etc. I have seen such a paragraph in another projects README, IIRC a Go rewrite of standard utilities. I do not understand why a project would be obsolete because it's on CVS or is old. CV…

Git makes it easier to accept contributions and code review from a larger developer community, thereby allowing building a higher-quality product. (Incidentally, while I think that part of the reason why Git is this way is due to design differences from CVS, this isn't essential to it being true. Git is also better than Monotone or Fossil or Bazaar, despite being much closer in design, because it has network effects…

> Git makes it easier to accept contributions and code review from a larger developer community, thereby allowing building a higher-quality product.

It is very easy to contribute if you know git. But you can mess it up if you don't know. I made a two-line bugfix patch to flycheck, and heck, I was nearly pasting the patch into a comment in issues because I didn't know anything about how to make a pull request on github and how to commit so that the puller would be happy. I didn't want to do sth. embarassing and spent two hours reading and reading how to submit my patch properly. And the whole fix was made and tested in about two minutes. If only I was able to submit a dumb patch, I wouldn't have to care if they used git, cvs, or tarballs and quilt.

Re: Cross-platform Rust rewrite of the GNU coreutils

#124

Post by yberreby »

gravypod wrote: post #64
theonewolf wrote: post #24

Earlier quoted context omitted.

I don't understand why you need an IDE, I believe Rust is simple enough that you can work on things in Notepad++ or Vim or Emacs.

Here are the features I like in an IDE that make be very productive: - Autocompletion - Mass rename - Source formatting - Integrated debugger interface with breakpoint insertion and overlying of state on source - Integrated VCS control - Automated deploy - Error display - Automatic importing of modules - Source cleanup (Automatic loop transformation) - Automatically building my project That's just a few things that I…

Autocompletion: YouCompleteMe + racer + racerd

Source formatting: rust.vim + rustfmt

Automatic building: https://github.com/passcod/cargo-watch

Error display: tmux, terminator or iTerm2 split planes

Rust has pretty good tool support in vim and Atom, for example (can't speak for the rest). We don't have stellar IDE support yet, but it's on the to-do list: https://www.rust-lang.org/ides.html

Personally, I don't miss IDEs. I like the approach of small, single-purpose, composable command-line utilities more.

Re: Cross-platform Rust rewrite of the GNU coreutils

#125

Post by 0xFFC »

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?

It is interesting no one suggested Rust project internal ide support. They are developing something called Oracle.This is basically everything IDE needs (autocomplete, reference finding, error checking, etc). Oracle haven't finished yet.But after Oracle being ready, I think every editor/IDE out there can provide best experience for rust by simply calling a bunch of API which is very simple thing to do compare to writing their own AST and autocomplete.

About the project, not being GPL is serious bummer for me. I don't want to GNU project isolate more than this and anyone other who has simple understanding of politics behind the scene will understand GNU as foundation have done a lot of good things for programmer/developer/hackers community.By far more than any other player in this area.

And since I have worked on Glibc for a while and I wanted to use rust just for experiment,I was seriously considering to work on this project if it were GPLv3.

Re: Cross-platform Rust rewrite of the GNU coreutils

#126

Post by dublinben »

epistasis wrote: post #77
pron wrote: post #55

Earlier quoted context omitted.

"Maybe glance" might well make it derivative.

This is very very weak grounds for any sort of lawsuit. But if having glanced at GPL source code prevents implementing similar functionalities in an entirely different language, that's a pretty darn strong argument for me to never look at GPL code again.

>that's a pretty darn strong argument for me to never look at GPL code again

This is only an issue if your derivative work is under a different license.

Re: Cross-platform Rust rewrite of the GNU coreutils

#127

Post by 0xFFC »

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 simple thing to do, but rust designed to do low-level stuff, and I cannot understand how having not having exception makes a language ugly (specially when you code in lowlevel).

Re: Cross-platform Rust rewrite of the GNU coreutils

#128

Post by catawbasam »

pcwalton wrote: post #95
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

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.

Re: Cross-platform Rust rewrite of the GNU coreutils

#129

Post by qznc »

catawbasam wrote: post #102
kbenson wrote: post #76

Earlier quoted context omitted.

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…

"while ignoring that it's caused many problems already" Really? I believe Mr. Hipp is claiming that it hasn't. Do you have evidence to the contrary? I don't think the argument is that these cases should be ignored -- they are now corrected, after all. It is that most of these cases should be treated as low priority compared to issues that are creating observable problems.

> The disagreement is not over whether or not [undefined behavior] is a problem, but rather how serious of a problem. Is it like “Emergency patch – update immediately!” or more like “We fixed a compiler warning” or is it something in between. –Hipp

In this specific case with sqlite it certainly is more of a fixed-compiler-warning. However, you could imagine some undefined behavior in SSL implementation to require emergency-patch level as well. I agree with you that undefined behavior "in most cases should be treated as low priority".

Post reply on HN