Cross-platform Rust rewrite of the GNU coreutils

Post by steveklabnik » Tue, Mar 22, 2016, 7:08 PM UTC

teamhappy wrote: post #192

fsiefken wrote: post #144

Some people worry about the file size (which should be similar), but I worry about the speed. How much faster can we grep or sed with a Rust compiled grep vs a C compiled grep?

Likely not as fast as with a grep written in C, but FreeBSD's grep is (was?) pretty slow compared to the GNU version and nobody really cares (read: it's probably fast enough).

Post by jordigh » Tue, Mar 22, 2016, 7:10 PM UTC

binarycrusader wrote: post #158

pron wrote: post #52

Earlier quoted context omitted.

This is a terrific project idea, but I agree that it should likely be under the GPL. Even if it is not legally derivative, it would be nice to preserve the GPL.

Sometimes the maximising the likelihood of a set of components being used is more important than potential licensing constraints. In this particular case, if they're not GPL, they're more likely to be used for various *BSD systems and in a variety of embedded contexts. Improving the general security and reliability of all systems seems like it might potentially be a more valuable goal.

Post by nwmcsween » Tue, Mar 22, 2016, 7:12 PM UTC

_ph_ wrote: post #196

andrepd wrote: post #187

Earlier quoted context omitted.

Don't underestimate performance. I haven't seen the most recent benchmarks, but C/C++/Fortran are still unbeatable in raw speed. If you want maximum performance no matter what, these are the languages to choose, even if they sacrifice readability, maintainability or safety.

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…

Post by zurn » Tue, Mar 22, 2016, 7:13 PM UTC

nickpsecurity wrote: post #175

steveklabnik wrote: post #118

Earlier quoted context omitted.

The Rust standard library does assume that allocation succeeds. The language itself knows nothing about the heap, and so you can write allocators that do whatever you wish. Side note: on most Linux distros, overcommit is on, and so malloc will basically always succeed; the OOM killer will kill your program before you'd get a failure. I am less knowledgeable about OSX and Windows. I cannot speak to SQlite in this rega…

Holy crap, I'd never have imagined that... A design that assumes allocation always succeeds flies in the face of decades of safety/security-critical coding wisdom. I strongly recommend the team revisit and change that somehow to account for failures, NULL's, whatever. Actually, same anywhere a failure-prone, esp hardware, resource is acquired. C apps can handle this issue so Rust should as well if it's to replace the…

Post by jerf » Tue, Mar 22, 2016, 7:15 PM UTC

ktRolster wrote: post #155

kbenson wrote: post #76

Earlier quoted context omitted.

Prof. Regehr did not find problems with SQLite. He found constructs in the SQLite source code which under a strict reading of the C standards have “undefined behaviour”, which means that the compiler can generate whatever machine code it wants without it being called a compiler bug. That’s an important finding. But as it happens, no modern compilers that we know of actually interpret any of the SQLite source code in…

At some point some popular compiler is going to make a subtle but important change to some undefined behavior that's not going to be immediately obvious as to it's repercussions, and the fallout will be massive. Wait until you realize that the length of a byte in C is not clearly defined. Someday a processor will come along where a byte is 6 bits, and the fallout will be massive. (Really, it's happened before). No, a…