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

341–350 of 498 posts

Re: Cross-platform Rust rewrite of the GNU coreutils

#341

Post by gkya »

Sir_Cmpwn wrote: post #307
gkya wrote: post #123

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. 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 think it's easily fair to say that git is by far the superior option to CVS, and preferring CVS over git is objectively incorrect. I think that you would be wise to invest the time in learning how to use git correctly.

Objective truth is second to factual productivity. I did use git. It's powerful, but more than I need. CVS takes ten pages of reading to grok. And then it's out of my way. I couldn't learn git in years, and there's something new every other day, it gets in my way. And I don't have time to chase a command line on stack overflow, I need that time for what I'm actually doing.

Re: Cross-platform Rust rewrite of the GNU coreutils

#342

Post by jstimpfle »

nickpsecurity wrote: post #206
teraflop wrote: post #177

Earlier quoted context omitted.

> What he's essentially saying that the existence of compiler bugs in Rust refutes using it as a C alternative. That is not at all what Hipp's comment says, and the original author's response to it gives it a much more charitable reading than you seem to be.

Let me re-read it. He makes several points. The first is that they're intentionally relying on undefined behavior known to cause problems sometimes out of nowhere. He says it's OK they rely on it because it's not currently causing them problems. Relying on something impossible to rely on as kbenson worded it since that's working out so far. Reminds me of a George Carlin quip about people building villages on active v…

> Next, he conflates compiler bugs with undefined behavior.

Maybe Rust is just not specified for every corner case? The compiler could just do anything in such cases (e.g. what a C compiler would do -- not checking for arithmetic overflow, for example). You can then go ahead and claim it wasn't UB in Rust. But effectively it is the same, and you can't expect that Rust will specify that a compiler must check for arithmetic overflows in the future.

> Next, he delivers the argument: that compiler bugs mean you can't rely on Rust unless you check the machine code itself.

If there are more bugs in the Rust compiler than in GCC or LLVM (which I don't know, but it sounds reasonable to assume given Rust's age) then that's just a good engineer's pragmatic realism.

Re: Cross-platform Rust rewrite of the GNU coreutils

#343

Post by MrBuddyCasino »

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

Here is a talk I recorded about Linux systems programming with Rust. Quality is only 720p, but maybe you'll still find it useful. The speaker compares solutions in C with equivalent ones in Rust, and what kinds of advantages / safety features you gain:

https://www.youtube.com/watch?v=sCOO6WdDZuk

Re: Cross-platform Rust rewrite of the GNU coreutils

#344

Post by lotyrin »

viraptor wrote: post #329
andrewflnr wrote: post #264

Earlier quoted context omitted.

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.

"Bash would be terrible because using it would cause a fire"

Yes, arguments have a burden to make sense, and provide evidence...

Re: Cross-platform Rust rewrite of the GNU coreutils

#345

Post by StreamBright »

weberc2 wrote: post #220
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…

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

I like to swing it the other way, you have to prove me that the newly proposed solution is not worth it. You can check out Amazon's policy about driving change. The "will not work" camp has to do the work to prove that something is not going to work. I think this approach yields to better results in practice.

Re: Cross-platform Rust rewrite of the GNU coreutils

#346

Post by jstimpfle »

viraptor wrote: post #340
jstimpfle wrote: post #324

Earlier quoted context omitted.

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…

Rust allows you to specify the behaviour you want: Checked operations: https://doc.rust-lang.org/std/primitive.i8.html#method.check... Saturating: https://doc.rust-lang.org/std/primitive.i8.html#method.satur... Wrapping: https://doc.rust-lang.org/std/primitive.i8.html#method.wrapp... Wrapping with notification: https://doc.rust-lang.org/std/primitive.i8.html#method.overf... These apply to shifts too and you can tag t…

> If the requested behaviour is unspecified (just `a+b`), overflows cause runtime panic.

As far as I know most machines can't trap on signed integer overflow. Which means having runtime panic is not practical. The page you linked says "no checking by default for optimized builds".

Re: Cross-platform Rust rewrite of the GNU coreutils

#347

Post by DrJokepu »

pcwalton wrote: post #333
DrJokepu wrote: post #331

Earlier quoted context omitted.

There is no way to select over a range of TcpStream objects. There is no stable way to select over a range of mpsc channels. There is no way to access a TcpStream in a non-blocking manner. There is no support whatsoever for UNIX signals. I could go on.

I don't miss the things you mentioned very much, and I think it's an exaggeration to say that these things are what makes Rust's standard library not usable for anything serious. But anyway: > There is no way to select over a range of TcpStream objects. mio > There is no stable way to select over a range of mpsc channels. Yes, this is annoying. We should stabilize MPSC select. You can use BurntSushi's chan for now th…

Mio is not part of the standard library. Go, for example, has excellent support for UNIX signals.

Re: Cross-platform Rust rewrite of the GNU coreutils

#348

Post by _ph_ »

picozeta wrote: post #325
_ph_ wrote: post #244

Earlier quoted context omitted.

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.

The readline library for example. If I want to use it, I have to GPL my whole program. I probably might not have modified readline at all. Or any other GPL software which gets somehow linked together with my code. Just watch the controversy whether ZFS kernel modules may be delivered as pre-compiled binaries (sources are fully available). The output of compilers and parsers which are GPLed, also are implicitly covered by the GPL, unless there is a clear exemption, like with GCC.

While GPL software which is used as an entity, like Linux itself or applications like Emacs are fine, any closer contact to the software you are trying to sell is problematic.

Re: Cross-platform Rust rewrite of the GNU coreutils

#349

Post by mc808 »

randommodnar wrote: post #259

MIT license? Is open-source dying?

I was going to say it only takes about 30 seconds to fork and change the license if you want to. Then I decided to check if someone had already done so. Yep. https://github.com/ivegotasthma/coreutils/commit/4c7dcbd912a...

I didn't count, but that may have taken less than 30 seconds.

Re: Cross-platform Rust rewrite of the GNU coreutils

#350

Post by comex »

jstimpfle wrote: post #324
pcwalton wrote: post #260

Earlier quoted context omitted.

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

> I know about the borrow checker, but I don't think ownership bugs is a type of bug that Mr. Hipp frequently produces.

The borrow checker eliminates use-after-free. And use-after-free is one of the most common types of vulnerability exploited in practice today, if not the single most common. (For evidence, look at reports about Pwn2Own.)

Index checking is quite cheap for most programs, and LLVM is good at eliminating redundant checks. As a useful comparison in another languages, Chromium compiles with bounds checks on std::vector by default (the [] operator, not the at() method which is required to be checked.) Actually, there are a lot of issues with Rust's current machine code output that I think slow it down, but index checking isn't one of them.

Post reply on HN