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

91–100 of 498 posts

Re: Cross-platform Rust rewrite of the GNU coreutils

#91

Post by kbenson »

jeena wrote: post #63
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?

Just to give an example: https://github.com/uutils/coreutils/blob/master/src/whoami/p... looks suspically simmilar to: http://code.metager.de/source/xref/gnu/coreutils/src/whoami....

I'm not sure picking a program where the portion that does any actual work is 3-6 lines in length is a good reference for whether they are copying code/algorithms. There's so little of substance to actually do differently, the chance of them looking similar in that respect if fairly high.

Re: Cross-platform Rust rewrite of the GNU coreutils

#92

Post by steveklabnik »

jblow wrote: post #78
steveklabnik wrote: post #44

Earlier quoted context omitted.

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

Oh, but I mean in Rust generally. Ideally any language that is not C would not depend on libc.

Ah. Well, right now, the standard library relies on a libc of some kind. If you use only core, then there's no reliance on a libc.

There has been some interest in making it easy to have stdlib without a libc; and some refactorings to std that may make it easier to do so, but those haven't come to fruition just yet.

Re: Cross-platform Rust rewrite of the GNU coreutils

#93

Post by gravypod »

wyager wrote: post #25
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?

You could just use atom and install some rust plugins.

I would, but the last time I installed atom and tried to start it the base text editor, without any added plugins, took 3 minutes to start and used ~600mb of system memory.

In comparison, Eclipse starts in under a minute and uses about half that on my system.

Atom when I tried it was much to large for my system. I might look at it again.

Re: Cross-platform Rust rewrite of the GNU coreutils

#94

Post by gravypod »

coldpie wrote: post #90
gravypod wrote: post #64

Earlier quoted context omitted.

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…

Yeah. I'm a vim guy myself, but I totally understand the appeal of IDEs. Luckily Rust is a well-defined language (unlike C and C++), so building a nice IDE shouldn't be too arduous.

Not only that, but it looks to have some very good tooling. Cargo should simplify things a lot for whoever writes IDEs.

Not only do you have a package manager, but a build system.

Re: Cross-platform Rust rewrite of the GNU coreutils

#95

Post by pcwalton »

masklinn wrote: post #39
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.

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 the important areas in practice than Rust (plus kcov [1] if you like) does. I think that's going to be pretty hard. (Especially if memory safety issues are the most important bug class you're concerned about: I think it's completely impossible for any C-based solution to compete with Rust here, regardless of how much tooling you add.)

Drawing an equivalence between undefined behavior and compiler bugs also doesn't make sense. Compiler bugs are way way less commonly encountered than undefined behavior in C. Also, they're qualitatively different: compiler bugs get fixed in new compiler versions, while UB is by design and doesn't get fixed.

[1]: https://users.rust-lang.org/t/tutorial-how-to-collect-test-c...

Re: Cross-platform Rust rewrite of the GNU coreutils

#96

Post by pcwalton »

haberman wrote: post #85
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

He certainly has a point, but I think he goes too far in assurances about the current sqlite3.so. Testing "every single instruction" does not guarantee that all C-level UB has been eliminated, because some bugs can be input-dependent. For example, even if your coverage tells you that this function has been tested, it could still trigger undefined behavior for other inputs that trigger overflow: int f(int x) { return…

For another example of this issue, consider the fact that data race detectors do not eliminate all data races in practice, because they only find races that show up on your test inputs.

Re: Cross-platform Rust rewrite of the GNU coreutils

#97

Post by 3JPLW »

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

Agreed; I'd go even farther to say that old is a feature. Now, as a side effect of its age, it may not conform to modern-day best practices and styles… which might make it harder to fix newly discovered bugs or add new features.

Heck, the increased difficulty in creating feature bloat could even be considered a feature in and of itself, too!

Re: Cross-platform Rust rewrite of the GNU coreutils

#98

Post by maaku »

micampe wrote: post #84
_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…

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.

Sometimes snapshot archives is exactly what's needed.

Re: Cross-platform Rust rewrite of the GNU coreutils

#99

Post by quotemstr »

ignoramous wrote: post #8

Rust is a great choice for systems programming it'd seem. Esp considering that a well-tested, battle-hardened code-base like SQLite faces problems [1] solely due to the nature of the language its written in. [1] https://news.ycombinator.com/item?id=11312918

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

Re: Cross-platform Rust rewrite of the GNU coreutils

#100

Post by quotemstr »

davexunit wrote: post #45
jamescun wrote: post #3

Could be useful given the choice of MIT license rather than a GPL variant.

They really should use the GPL and not a pushover license.

What is it with rewrite-the-world-in-Rust people being stridently anti-copyleft?
Post reply on HN