Curious to the benefits of this. Is Rust performant and on par with the native C version of coreutils? Seems the readme makes a big deal about being easy to compile on windows (which has never been a problem for me, I just use Cygwin or something).
Also, comments like this make it seem this is not "fully baked" yet and still needs some dev time:
> fn parse_date(str: &str) -> u64 {
> // This isn't actually compatible with GNU touch, but there doesn't seem to
> // be any simple specification for what format this parameter allows and I'm
From my understanding, Cygwin should almost be considered a different platform than Windows proper. Projects like MSYS do a much better job of being Windows-native.
Rust definitely needs more dev time, but if coreutils already has such an excellent test suite, this sounds like a great way to test Rust in action.
I am a performance noob, but given that fortran can be faster than C due to increased information about aliasing, and given how much more aliasing information Rust has, I don't see why Rust couldn't eventually even beat C on certain kinds of things. (And obviously, aliasing is only a tiny part of performance, just something that comes to mind.)
That said, I am FAR more concerned about shipping a solid 1.0 than on a maximum performance one. It'll be a while, but we'll get there.
Visual Studio ships only with a C++ compiler. That doesn't mean you cannot use other C compilers on Windows.
Still, there seems to be something similar since VS2005. »__restrict is similar to restrict from the C99 spec, but __restrict can be used in C++ or C programs.«: http://msdn.microsoft.com/library/5ft82fed.aspx
PellesC has a new release candidate. LCC-WIN32 (compatible with what standard???) has a steady stream of releases. Openwatcom v2 has also changes. VS is only good for VisualD.
Also, comments like this make it seem this is not "fully baked" yet and still needs some dev time:
> fn parse_date(str: &str) -> u64 {
> // This isn't actually compatible with GNU touch, but there doesn't seem to
> // be any simple specification for what format this parameter allows and I'm
> // not about to implement GNU parse_datetime.
> // http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob_plai...