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

321–330 of 498 posts

Re: Cross-platform Rust rewrite of the GNU coreutils

#321

Post by pcwalton »

Dylan16807 wrote: post #319
pcwalton wrote: post #304

Earlier quoted context omitted.

> Or that an uninitialized variable is equivalent to initializing it with a semi-random number. This proposal destroys lots of dead code elimination optimizations that are very important in code post inlining (for example, in the STL).

Can you explain why? What if we relax it to say that copying from one uninitialized variable to another can be omitted?

Because uninitialized variables are allowed to change values arbitrarily over their (nonexistent) "live range". Your proposal would force them into having a real live range, with a stable value. See this section for an example, which shows examples of the kinds of optimizations this opens up:

http://llvm.org/docs/LangRef.html#undefined-values

There's also the issue that having a stable value forces the register allocator to keep a live range for the undefined variable, which can cause unnecessary spills or remat in other places. Especially on 32-bit x86, this can be a problem.

Re: Cross-platform Rust rewrite of the GNU coreutils

#322

Post by masklinn »

peterwwillis wrote: post #270
masklinn wrote: post #157

Earlier quoted context omitted.

That's not a question of certification or extensions, I'm talking about being able to write portable scripts . Due to the interaction between its definition and its extensions, echo is a prime example of being impossible to use portably (except in the very restricted case of only literal strings without escapes which don't start with a -). > Ultimately, each platform has quirks, and it is up to the developer to port…

Ok, I think I understand the confusion now. You seem to be of the impression that shell scripts are like bytecode executed in a virtual machine. That is the only way I know of that you could write an application for a platform that doesn't exist and expect it to work. But even for that to work, it would need to be the same VM, and bytecode generated by & for it, or there's still no guarantee it will work. Of course,…

> Ok, I think I understand the confusion now. You seem to be of the impression that shell scripts are like bytecode executed in a virtual machine.

What in bloody hell are you talking about?

> Of course, you can already write a shell script for a particular shell

Which is irrelevant to my comment as that's not what portability means.

> But that defeats the whole purpose of following a standard like POSIX

Exactly.

> Bottom line, though: two independent implementations of a standard provide no guarantee they will work together.

If following a standard can't ensure your program can work on two different implementations of the standard, you don't have a standard you have decorated toilet paper.

Which is more or less what the "commands and utilities" part of POSIX is.

Re: Cross-platform Rust rewrite of the GNU coreutils

#324

Post by jstimpfle »

pcwalton wrote: post #260
jstimpfle wrote: post #252

Earlier quoted context omitted.

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

Help me out here, I don't know much about Rust. Which bad programs does Rust rule out?

I know about the borrow checker, but I don't think ownership bugs is a type of bug that Mr. Hipp frequently produces. It's a program design issue -- not something you think about at every single line you write. A well-designed program does not do many ownership transfers.

As someone else noted, out-of-bounds errors are sadly a pain to debug in C. For testing code, C has at least valgrind (and certainly many less well-known tools). For production code, you might not want dynamic index checking. It would invalidate performance arguments for Rust.

I think the real nasty cases of UB in C, which frequently occur as not statically refutable, are signed arithmetic overflow and shifts. As with out-of-bounds errors, I don't think Rust has a better story here -- only better built-in tooling.

Re: Cross-platform Rust rewrite of the GNU coreutils

#325

Post by picozeta »

_ph_ wrote: post #244
jordigh wrote: post #217

Earlier quoted context omitted.

> Todays reality has Microsoft and Apple sharing part of their codebase under permissive licenses. In that case, they should have no problem sharing it back under a copyleft license either.

Well, there is a huge problem - copyleft does not only require you to share changes to the source you used and modified, but also to unrelated source of your own. Which kills it for most corporations. Some of their code might contain trade secrets or just isn't freely relicenseable by them as it might involve third party rights. Which is why LGPL mostly works for corporations but GPL not.

Can you elaborate on this? What exactly do you mean with unrelated source and might you give a concrete example what a company could NOT do if this code would be GPL'ed.

Re: Cross-platform Rust rewrite of the GNU coreutils

#326

Post by jahewson »

TallGuyShort wrote: post #296
jahewson wrote: post #273

Earlier quoted context omitted.

There's nothing wrong with reading the source code. You're allowed to read whatever you like! Just don't copy it.

Well there's the rub - once you see the source code, it's tough to say you weren't influenced by it. In for-profit endeavors this kind of thing is typically done by having two separate groups of people, one that sees the competing product and writes detailed descriptions of behavior, and one that never sees the product, only the product of the first group. If you're careful about this and go to pains to keep the grou…

> you're considered tainted from an intellectual property perspective.

No you're not. The law has exactly zero to say about this. The idea of "clean room" development is nothing more than a legal tactic used to ward off potential lawsuits from an aggressive adversary. It's in no way necessary to do this.

Re: Cross-platform Rust rewrite of the GNU coreutils

#327

Post by pg_is_a_butt »

andrewflnr wrote: post #264
weberc2 wrote: post #220

Earlier quoted context omitted.

> 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 don't have a dog in this fight, but I don't see how the burden of proof is on Hipp rather than the folks proposing the change. In other words, shouldn't the "rewrite it in Rust" folks have to prove that the cost of their propos…

Sure, the primary burden of proof is on those proposing a change. However, any time you stand up and make an argument, the burden is on you to make sure it actually makes sense, and that goes for both sides.

uh, both sides did make sense... they're also both irrelevant. you want to remake all stop lights to never turn green unless a sensor says no cars are approaching the intersection over 5 mph? ok, so you spend a trillion dollars and update every single stoplight everywhere... then the sensors start failing, things are worse, and more people die. what we have now works... the last thing we need is more rust in the infrastructure.

Re: Cross-platform Rust rewrite of the GNU coreutils

#328

Post by yincrash »

alixaxel wrote: post #275

The CoreUtils sort is amazingly efficient, it can sort files nearly as big as your hard drive without matching memory requirements. With all these node.js / Go / Rust CoreUtils implementations I'm still hoping for one of them to actually match the efficiency of the original implementation.

I wrote the initial sort about a year ago (w/o looking at GNU version's source). I just looked at the current version, and confirmed uutil's sort does not do any external sorting, meaning the entire input is stored in memory. Maybe someone can confirm that GNU's sort uses temporary file storage to do something like an external merge sort to reduce memory usage?

edit: confirmed. http://stackoverflow.com/questions/930044/how-could-the-unix...

Re: Cross-platform Rust rewrite of the GNU coreutils

#329

Post by viraptor »

andrewflnr wrote: post #264
weberc2 wrote: post #220

Earlier quoted context omitted.

> 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 don't have a dog in this fight, but I don't see how the burden of proof is on Hipp rather than the folks proposing the change. In other words, shouldn't the "rewrite it in Rust" folks have to prove that the cost of their propos…

Sure, the primary burden of proof is on those proposing a change. However, any time you stand up and make an argument, the burden is on you to make sure it actually makes sense, and that goes for both sides.

This is getting a bit meta, but I disagree. It would be trivial to abuse in discussions.

    A: Bash would be way better for SQLite, really!
    B: But Bash is a terrible choice because X, Y, Z, ...
    A: If you make those arguments, you have to prove them.

Re: Cross-platform Rust rewrite of the GNU coreutils

#330

Post by pcwalton »

wangchow wrote: post #314
pcwalton wrote: post #250

Earlier quoted context omitted.

> Correct code in C is actually easy since the language is very simple. 1. No, it's not. Witness the various arguments that have happened on HN over the years concerning whether the imprecise language of the spec makes some idiom undefined behavior or not. 2. The evidence over the past 35 years has not shown that correct code is "simple" in C. > For instance, parallelizing algorithms must take into account cache-alig…

"The evidence over the past 35 years has not shown that correct code is 'simple' in C." "Your firm belief is contradicted by 35 years' worth of memory safety track records of large-scale software written in C." Keep in mind, of those 35 years, it only makes sense to consider the last decade-onward (or so) in comparison. While the language hasn't changed a whole lot, programming methodologies certainly have. How many…

> Keep in mind, of those 35 years, it only makes sense to consider the last decade-onward (or so) in comparison. While the language hasn't changed a whole lot, programming methodologies certainly have.

The last decade has seen an explosion of modern C++ code using best practices that routinely exhibits the same memory safety issues. C is worse.

> There are definitely issues with C no doubt--but so many people say C is dangerous and difficult when in fact they don't even practice using the language.

I practice C all the time and I think it's dangerous and difficult. I've seen so many brilliant programmers accidentally create game-over RCEs via use after free, for example.

Post reply on HN