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

331–340 of 498 posts

Re: Cross-platform Rust rewrite of the GNU coreutils

#331

Post by DrJokepu »

pcwalton wrote: post #316
DrJokepu wrote: post #172

Earlier quoted context omitted.

Writing Rust code interfacing libc is a rather frustrating experience though. Many libc interfaces use constructs that Rust really wants you to avoid (for very good reasons), things such as global mutable variables (errno and for callback functions without context pointers) or union types. I know about at least one cargo crate attempting to "Rustify" libc with some level of success. None the less, this is what I typi…

> Rust code as much of th Rust standard library is simply not ready for "serious" usage. Can you elaborate on this? I've been getting serious usage out of the Rust standard library for years...

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.

Re: Cross-platform Rust rewrite of the GNU coreutils

#332

Post by alkonaut »

yberreby wrote: post #124
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…

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

The problem with composable tools is that some things are really hard to compose and separate out, and have to be integrated: syntax highlighting, autocompletion and interactive debuggers are really hard to treat as separate programs.

You probably noticed how useless racer is on the command line: type code in your text editor and then when you want a completion, you go to your CLI and type "racer myfile.rs row,column" and there are your completions! :) Jokes aside: it's clearly superior (and intended) as an integrated tool than as a command line tool.

I'd argue that a debugger can offer the same kind of power being an integrated debugger as the (admittedly silly) racer example.

Re: Cross-platform Rust rewrite of the GNU coreutils

#333

Post by pcwalton »

DrJokepu wrote: post #331
pcwalton wrote: post #316

Earlier quoted context omitted.

> Rust code as much of th Rust standard library is simply not ready for "serious" usage. Can you elaborate on this? I've been getting serious usage out of the Rust standard library for years...

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

> There is no way to access a TcpStream in a non-blocking manner.

mio basically supports this, no?

> There is no support whatsoever for UNIX signals.

Do many languages have good support for this? The C and C++ standard libraries don't; that's part of POSIX. Signals interact very badly with garbage collectors, so I can't imagine many languages have this.

Re: Cross-platform Rust rewrite of the GNU coreutils

#334

Post by realityking »

jahewson wrote: post #254
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

The Federal Circuit Court of Appeals (and apparently the Supreme Court) would disagree with you on copyright protection for APIs.

https://en.m.wikipedia.org/wiki/Oracle_America,_Inc._v._Goog....

Re: Cross-platform Rust rewrite of the GNU coreutils

#335

Post by stcredzero »

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

...faces problems solely due to the nature of the language its written in.

Really, this is true of any programming language and any involved enough program. It's just that with C and security-critical programs, there's some unfortunate concordance between the errors you want to avoid and the errors that are harder to avoid.

Re: Cross-platform Rust rewrite of the GNU coreutils

#336

Post by alkonaut »

andrepd wrote: post #193
m0th87 wrote: post #168

Earlier quoted context omitted.

> Difficulty is relative. If you don't study modern C idioms your C code will be crap. Same goes for Rust. That's not a valid argument for why better tooling can't help alleviate some of the difficulty. > Honestly using higher-level languages is the same mentality as taking a pill to magically lose weight. It's quick, but detrimental (to programmers ability) in long term. If that were true, the most effective program…

>If that were true, the most effective programmers would only code on assembly. No, because C is as fast as hand-coded assembly in most of the cases. The same can't be said of any high level language in comparison to C (save for C++ and Fortran).

> The same can't be said of any high level language

Rust is basically a metal level systems language. Just like C. It has a nicer type system but it compiles to more or less the same thing in the end. Unless you make an error such as using freed memory, in which case it doesn't compile while the equivalent C code would often compile to a very high performance foot-gun. The Rust safety is paid for, for the most part, at compile time unlike the usual high level languages like java/C#/python/... which pay for it at runtime.

Re: Cross-platform Rust rewrite of the GNU coreutils

#337

Post by samth »

pcwalton wrote: post #271
samth wrote: post #263

Earlier quoted context omitted.

I don't think he's making the argument you think he's making. This is clearer in his later comments in the thread, in which he says that UB is much scarier in systems like Fossil. His argument is that achieving the level of quality that SQLite has requires verification (in a broad sense) after the compiler, and that's what he does. If you consider the goal to be producing quality-assured binaries, then you can treat…

> His argument is that achieving the level of quality that SQLite has requires verification (in a broad sense) after the compiler, and that's what he does. > If you consider the goal to be producing quality-assured binaries, then you can treat UB, compiler bugs, and many other things as falling in a similar category, which are almost certainly eliminated by an MC/DC test suite. I don't think that they're eliminated b…

> I don't think that they're eliminated because dynamic testing can't eliminate everything—it only finds bugs given its test inputs.

I can't think of an example of UB-exploit in the compiler that wouldn't result in different branch behavior, and thus, I think, in failure of MC/DC. But I may simply be insufficiently imaginative.

John makes the point about source code in a follow-up comment, and I agree, but I also see Hipps' perspective.

Re: Cross-platform Rust rewrite of the GNU coreutils

#338

Post by wangchow »

pcwalton wrote: post #330
wangchow wrote: post #314

Earlier quoted context omitted.

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

Well, you are probably right. :)

I am certainly biased as I enjoy procedural languages for their simplicity. So many constructs in the others. As the saying goes, C++ is my favorite 4 languages. I hope that doesn't become the fate of Rust. Go-Lang seems to get that part properly then that's probably debatable.

Re: Cross-platform Rust rewrite of the GNU coreutils

#339

Post by Rusky »

jblow wrote: post #81
alricb wrote: post #68

Earlier quoted context omitted.

Do you suggest they should use raw system calls? On most systems your options are either calling standard C functions or doing raw calls (not portable). Someone did start a C stdlib implementation in Rust, but it appears to be inactive: https://github.com/mahkoh/rlibc

Yes, the right thing is to port your language's standard library to whatever operating system you want to run on ... just like libc did. You could have a dummy version that just calls out to libc, for compatibility with systems that you haven't finished porting to yet.

And what about systems that don't have a stable interface below dynamically linking that platform's system-provided libc? Just let every program break when the system updates?

Re: Cross-platform Rust rewrite of the GNU coreutils

#340

Post by viraptor »

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…

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 types themselves to always behave one way. Overflows at compile time are caught as errors. More info at:

https://github.com/rust-lang/rust/issues/22020

If the requested behaviour is unspecified (just `a+b`), overflows cause runtime panic (edit: or wrapping behaviour in release build)

See https://doc.rust-lang.org/1.7.0/reference.html#behavior-not-...

Post reply on HN