Hacker News Reader

Comment by Alupis | Hacker News Reader

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

> // not about to implement GNU parse_datetime.

> // http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob_plai...

View on HN

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.

Rust is still behind C, but I feel that's just a maturity issue. C has had nearly 50 years to get to where it is in performance Rust hasn't had 5.

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.

A nitpick: C has been able to achieve the same performance as Fortran since C99 introduced the "restrict" keyword.

I was reading the other day that Windows doesn't really support most of C99, is restrict part of that or not?

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.

Ugh, yes, I should have said "MSVC++," or "Microsoft." Thank you.

MS specifically implemented __restrict:

> __restrict is similar to restrict from the C99 spec, but __restrict can be used in C++ or C programs.

http://msdn.microsoft.com/en-us/library/5ft82fed.aspx

As of VS2013, MS supports almost the entire C99 spec.

Reply on news.ycombinator.com