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

251–260 of 498 posts

Re: Cross-platform Rust rewrite of the GNU coreutils

#251

Post by pcwalton »

andrepd wrote: post #191
nickik wrote: post #174

Earlier quoted context omitted.

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.

It will be slower, though. C is king in raw performance, and in critical areas where that does matter you don't really have a choice but to write it "by hand" (aka in C).

Can you name particular areas in which C allows you to get the performance that Rust does not? Be specific.

Re: Cross-platform Rust rewrite of the GNU coreutils

#252

Post by jstimpfle »

pcwalton wrote: post #138
catawbasam wrote: post #128

Earlier quoted context omitted.

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

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

I think that sounded more like "Many of the programs which are UB in C are also UB in Rust, even though not (yet) specified as such."

Re: Cross-platform Rust rewrite of the GNU coreutils

#253

Post by Jach »

hobarrera wrote: post #120
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…

vim (+ sh) cover all those things, except maybe the last two.

The last two items are definitely achievable. As a saying goes, "vim is my editor, Linux is my IDE." I'd rather learn a handful of tools that will last me my career and be valuable in many different circumstances in and out of work and more formal "programming" than learn a new IDE per language and/or a new Master IDE for multiple languages every few years.

Re: Cross-platform Rust rewrite of the GNU coreutils

#254

Post by jahewson »

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?

No. It's not a derivative work. Creating a compatible piece of software is not copying. Even if you've seen the original code. If you're not literally copying and pasting code, it's fine.

Copyright protects the code itself from being copied, but the ideas, abstractions, overall design, and even individual APIs are not eligible for copyright protection

Re: Cross-platform Rust rewrite of the GNU coreutils

#255

Post by gkya »

jfoutz wrote: post #179
gkya wrote: post #153

Earlier quoted context omitted.

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.

> If you're learning for the sake of learning, i'd dig into git.

Well, nearly everything moved to git. I've used it for a while, mostly commit/pull/clone. I actually moved to CVS from git :) It's a bit like perl, git, you either need to be an expert at it, or else you can get going, but at the end you create a mess.

> [...] it's probably not worth the overhead. Sounds like you have a good, efficient setup.

Mostly, yes, but mostly because I don't really need that much more than recording my history, and occasionally looking at what I did in the past and more rarely working on short-lived branches. But there are a couple tools that if I ever code them up, I will make opensource. Tho if I ever do, and they take on, I'll use a 'just send a patch on the mailing list' approach. I believe it's easier to deal with. No flamewars on VCSes :)

Re: Cross-platform Rust rewrite of the GNU coreutils

#256

Post by _ph_ »

nwmcsween wrote: post #225
_ph_ wrote: post #196

Earlier quoted context omitted.

That is, in this general form, wrong. Most compiled languages can match or sometimes exceed C speeds, depending on the task at hand and the algorithm chosen. There are a lot of very inefficient C programs around - because they are badly written. More high-level languages allow the programmer to focus on speed where it matters. And in the current day and age, there should be no reason to favor raw speed vs. program co…

You see code size and linearity is very important for anything non-trivial and hot. New languages tend to have abstractions built upon themselves making understanding and optimizing a pain.

Well, I have plenty experience of working with SBCL which directly gives you access to the assembly produced, allowing extremely good control of the code quality in hot spots. Just

(disassemble 'my-function)

would give a nice printout. There are also lots of other languages, which might be high-level, but still give you excellent code quality - I used Modula-2 a long time ago which did back then beat the resident C-compiler in generated code quality. Yes, many C compilers are very good and some new stuff not much so, but claiming in general that "C" is fast is an oversimplification.

Re: Cross-platform Rust rewrite of the GNU coreutils

#257

Post by geofft »

gkya wrote: post #123
geofft wrote: post #105

Earlier quoted context omitted.

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

I can't speak for other projects, but for anything I maintain on GitHub, "Hi, I don't know how to use git, but here's a patch file" is a perfectly acceptable bug report! I'm not claiming that git makes it 100% easy, just that it makes it more easy.

That said, GitHub does let you use a web-based editor to create a git branch behind the scenes and open a pull request, with no VCS client required at all. So that's a point in GitHub's favor. (Again, it's not inherent to git, and a hypothetical CVSHub could do that, but GitHub exists.)

Re: Cross-platform Rust rewrite of the GNU coreutils

#258

Post by Alupis »

pcwalton wrote: post #240
Alupis wrote: post #113

Earlier quoted context omitted.

> 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 agree in principal, however the timing is wrong. Rust is a very new language (less than 6 years old), and is undeniably totally unproven. It is the latest "buzz" language, and may not be around long term... nobody knows. What-more, a full-fledged re-write of CoreUtils in…

> Flatly, re-writing a several decade's old, matured codebase in today's flavor-of-the-week language is not a good idea. It's odd that so many in the computing industry are unwilling to move on from a language from 1978 . We think of ourselves as one of the most fast-moving industries, but we have this odd reverence for early C and Unix that makes us stubborn and resistant to change. The fact is: we didn't know how t…

> We think of ourselves as one of the most fast-moving industries

We're fast-moving because our foundation is solid and not changing (ie. CoreUtils and gang). It's an assumption that these things "just work" with zero fuss and weirdness between systems.

We build on-top of these systems, so changing them out from underneath us all is a dramatic shift.

Perhaps Rust is the key to making these things better. I never claimed Rust is bad. I've only claimed that Rust may or may not be the right choice here, and since it's so young and unproven, we should wait before trying to re-write "all the things" in Rust. Today, Rust is a pet language... tomorrow, maybe not.

Remember, it took C many years to "catch on", and even longer to become the de facto standard for systems work. We can't rush this sort of thing... especially given the sheer magnitude of things depending on this code.

We should also be careful who actually does the re-write when the time comes. New CS grads who cannot understand the old C code and therefore feel [insert-new-hip-language-here] is better... are not the best ones to tackle this sort of endeavor. This requires deep, deep understanding of the entire package, how all the components interact, legacy behavior and the reasons behind design decisions, etc...

Re: Cross-platform Rust rewrite of the GNU coreutils

#260

Post by pcwalton »

jstimpfle wrote: post #252
pcwalton wrote: post #138

Earlier quoted context omitted.

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

> "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." I think that sounded more like "Many of the programs which are UB in C are also UB in Rust, even though not (yet) specified as such."

> I think that sounded more like "Many of the programs which are UB in C are also UB in Rust, even though not (yet) specified as such."

Well, this seems either (a) false or (b) uninteresting to me. It's false because C and Rust have different semantics, and Rust rules out lots of programs that C doesn't. It's uninteresting because if the point is that Rust has accidental undefined behavior due to compiler bugs (and it does), then that UB is so rarely hit that it doesn't matter nearly as much in practice as the UB in C.

CPUs have bugs, too. Do we consider Java an unsafe language because of rowhammer?

Post reply on HN