Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Rust for Low-Level Linux Programming?

groveronline.com

Post reply on HN
Print view View original

191–200 of 231 posts

Re: Why Rust for Low-Level Linux Programming?

#191

Post by jabl »

kbenson wrote: post #87
bitwize wrote: post #80

Earlier quoted context omitted.

No, there's no reason, as it could have been written in Ada and gotten many of the same safety guarantees as Rust provides.

Given Ada's history in safety critical systems (avionics), it's actually somewhat surprising more didn't use Ada. They could have just adopted the military standard (which is fairly stringent, as I understand it). The military is pretty adverse to losing billion dollar pieces of equipment, so they probably take quite a few precautions.

Didn't most of the military-industrial complex drop Ada in favor of C or C++ as soon as the DoD dropped the requirement that critical software must be done in Ada?

AFAIU the JSF software is done in C++, there is (or at least used to be) some JSF coding guidelines document on Bjarne Stroustrups web page. Of course, blaming C++ for the JSF boondoggle is unfair, but still, one wonders whether it was wise of the DoD to allow C/C++...

Re: Why Rust for Low-Level Linux Programming?

#192

Post by bjourne »

Manishearth wrote: post #180
bjourne wrote: post #174

Earlier quoted context omitted.

Since people were so angry I used The Benchmark Game as a source for benchmarks here ( https://github.com/logicchains/LPATHBench/blob/master/writeu... ) is another micro benchmark showing gcc & clang handily beating rustc. Though the timings are 1+1/2 year old. Their relative performances might have changed significantly.

That's pre-1.0. Rust has changed a lot. Also, given how prone microbenchmarks are to depending on hand-optimization over the compiler quality, benchmarks should have been contributed to by the community -- I don't think anyone in rust has heard about this one. Oh also, Rust is as fast as C/C++ there. It's just not faster than C++Cached, _which is a different algorithm_. That's the problem with microbenchmarks, you en…

No. In the first table Rust has 1874 and C++/clang 1722. The latter number is lower. C++ with clang beats Rust.

In the second table all C and C++ versions beats Rust. 618, 749, 755 and 735 vs 877. That is a very big difference.

You can also run the fucking benchmarks yourself and see for yourself. I have linked to lots of benchmarks showing C spanking Rust. None has shown any fair benchmarks were Rust is as fast as C.

Re: Why Rust for Low-Level Linux Programming?

#193

Post by bjourne »

Manishearth wrote: post #175
bjourne wrote: post #122

Earlier quoted context omitted.

I wrote "what can you do" because you are supposed to use some modicum of common sense when reading the numbers on The Benchmark Game. E.g in one of the benchmarks PHP beats both C and Rust, so you need to apply common sense to understand that that result is an outlier. I didn't cherry-pick; in 5/10 benchmarks, C is twice as fast as Rust. > rust code shouldn't have any more overhead. But it appears that it have. > We…

> some modicum of common sense when reading the numbers on The Benchmark Game yes, this involves checking what the benchmarks are actually measuring. In this case, it is how much faster SIMD makes things. Factor that in, or rewrite the programs with SIMD in rust, and it should come out to be the same. > But it appears that it have. Have you not been listening? It doesn't. The speed differences you quote are due to si…

Using the nightly builds of any programming language in production is insane. That's why we call it FutureRust to differentiate it from what is production ready Rust.

That Rust might have SIMD intrinsics in the future matters little to people trying to seriously use Rust today. And in several benchmarks C handily beats Rust even without intrinsics. Such as the fannkuch-redux one where it is about 2x faster.

Re: Why Rust for Low-Level Linux Programming?

#194

Post by steveklabnik »

bogomipz wrote: post #184
steveklabnik wrote: post #162

Earlier quoted context omitted.

The Rust book has this chapter, for example: http://doc.rust-lang.org/stable/book/the-stack-and-the-heap....

Ah neat, I did not know about the book, thanks.

No worries. I'm currently in the process of re-writing it for the second edition...

Re: Why Rust for Low-Level Linux Programming?

#195

Post by crzwdjk »

naasking wrote: post #164
korethr wrote: post #145

Earlier quoted context omitted.

Okay, now you've piqued my curiosity. Is that something to do because it's really smart and clever and fun, or is there a certain problem or class of problems where doing that is unambiguously the best or least-worst solution?

Haskell does it automatically as an optimisation: if an algebraic type has fewer than 2-3 cases, then it inline the tag bits directly into the pointer, thus saving an indirection on pattern match. Some C data structures also make use of low level bit tricks like this to save space and reduce indirections. For instance, the hash-array mapped Trie uses a 32 bit mask to both track which indices of the current node are a…

Rust actually does a bit of this internally in the form of the null pointer optimization. If you have an Option (or Option) value, it's actually stored as a single pointer-sized value, with None being represented by a null pointer on the assumption that null is not a valid pointer.

Re: Why Rust for Low-Level Linux Programming?

#196

Post by ithinkso »

jernfrost wrote: post #95

I love C, but I think we really have to stop building all kinds of shared libraries in C. Important code which needs to be secure and solid can't be built on C anymore, it puts everybody at risk. Just look at the disaster OpenSSL has been. I think Rust would be create for building common crypto infrastructure and things such as crypto currency. It seems risky to me to build something like Bitcoin with C++ where milli…

You are missing one very important point: bindings. You can bind to C from basically every other language, which is quite important for shared libraries.

Re: Why Rust for Low-Level Linux Programming?

#197

Post by bjourne »

tome wrote: post #156
bjourne wrote: post #33

Performance. Rust is still twice as slow as C ( http://benchmarksgame.alioth.debian.org/u64q/performance.php... ) which is still a fair bit slower than if a skilled assembly programmer had taken on the task. Rust aficionados will say that their compiler is getting better, but so is C. clang has gotten faster than gcc on some benchmarks and on some others gcc has catched up and is now faster than clang again. But what…

> Rust is still twice as slow as C which is still a fair bit slower than if a skilled assembly programmer had taken on the task. Really? Are there really people who write (a lot of) assembly in order to get code "a fair bit" faster than C? What on earth are they working on?

VM implementations and garbage collectors.

Re: Why Rust for Low-Level Linux Programming?

#198

Post by DonaldFisk »

RealityVoid wrote: post #188
Matthias247 wrote: post #150

Earlier quoted context omitted.

Totally agree, you can write software thats perfectly MISRA compliant and still contains lots of different bugs.

Truth be told, the question here is: "Is the class of errors that is prevented by Rust natively also prevented by MISRA?" My take is that while there is some overlap, MISRA is unable to guarantee anything, while Rust is able to guarantee certain things that C can't. (that's from my limited understanding of Rust, I haven't futzed with it yet)

I don't think C (or C++) should be used for autonomous vehicles at all, as it is known to be unsafe, but if it is, the MISRA C guidelines or something similar should be used to help prevent certain kinds of bugs.

Almost any other statically typed language, along with similarly strict guidelines, would be preferable to C, but there is no ideal language. Rust still allows dynamic heap memory allocation and recursive functions. It is also new. Ada has been used for decades.

Re: Why Rust for Low-Level Linux Programming?

#199

Post by Manishearth »

bjourne wrote: post #192
Manishearth wrote: post #180

Earlier quoted context omitted.

That's pre-1.0. Rust has changed a lot. Also, given how prone microbenchmarks are to depending on hand-optimization over the compiler quality, benchmarks should have been contributed to by the community -- I don't think anyone in rust has heard about this one. Oh also, Rust is as fast as C/C++ there. It's just not faster than C++Cached, _which is a different algorithm_. That's the problem with microbenchmarks, you en…

No. In the first table Rust has 1874 and C++/clang 1722. The latter number is lower. C++ with clang beats Rust. In the second table all C and C++ versions beats Rust. 618, 749, 755 and 735 vs 877. That is a very big difference. You can also run the fucking benchmarks yourself and see for yourself. I have linked to lots of benchmarks showing C spanking Rust. None has shown any fair benchmarks were Rust is as fast as C…

That's a ... very small difference. And again, probably due to implementation differences. I'm not claiming C doesn't beat Rust, I'm just saying by very little -- Rust is practically just as fast, within the margin of error that microbenchmarks have. You have been belting out claims that Rust is 2x slower -- clearly false. Rust may be 5% slower -- which ... doesn't really matter.

Look at wycats' talk on fast_blank. That's a real world example that's faster than C. Rust used to be faster than c on the regex benchmark at one point, as burntsushi pointed out.

Re: Why Rust for Low-Level Linux Programming?

#200

Post by RealityVoid »

DonaldFisk wrote: post #198
RealityVoid wrote: post #188

Earlier quoted context omitted.

Truth be told, the question here is: "Is the class of errors that is prevented by Rust natively also prevented by MISRA?" My take is that while there is some overlap, MISRA is unable to guarantee anything, while Rust is able to guarantee certain things that C can't. (that's from my limited understanding of Rust, I haven't futzed with it yet)

I don't think C (or C++) should be used for autonomous vehicles at all, as it is known to be unsafe, but if it is, the MISRA C guidelines or something similar should be used to help prevent certain kinds of bugs. Almost any other statically typed language, along with similarly strict guidelines, would be preferable to C, but there is no ideal language. Rust still allows dynamic heap memory allocation and recursive fu…

MISRA is already used extensively in the auto industry. But i guess what I was trying to say is that while it helps, it can easily be tricked while a compiler designed with the safety measures MISRA promotes already baked into it will not let you do certain things.
Post reply on HN