Live data from Hacker News

Why Rust for Low-Level Linux Programming?

groveronline.com

131–140 of 231 posts

Re: Why Rust for Low-Level Linux Programming?

#131

Earlier quoted context omitted.

> This difference on this test is caused by Rust not having stabilized SIMD support. Also Rust support hand rolled assembly (on nightly) that C has. Cool. Let's call that language with SIMD and inline assembly support FutureRust(tm) to differentiate it from the currently released and available Rust. We can have a discussion about how fast FutureRust will be vs C, but this discussion is about Rust vs C. Or rather clan…

>In 5 of 10 benchmarks, C is twice as fast as Rust fannkuch-redux why? SIMD fasta-redux why? SIMD spectral-norm why? SIMD reverse-complement why? SIMD N-Body why? Oh you guessed it SIMD Seriously read the source code. Remember on HN where a lot of people constantly say the benchmark game is really crappy. This is why. All 5 of these tests boil down to raw FLOPS. Which C/C++ having access to SIMD instructions wins at.…

Rust is also slower in binarytrees, regexdna and fasta. SSE is not one "barely used corner case" because huge amounts of performance critical code takes advantage of it.

Edit: To explain why I don't believe you when you say that "Post compilation they are functionally identical [in performance]" is because if it were so, you would just transliterate the C solutions to the Rust equivalents and it would run as fast as C. Since that hasn't been done and is trivial to do, my conclusion is that it doesn't lead to the same performance.

Re: Why Rust for Low-Level Linux Programming?

#132

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 don't have to chose between productivity and safety so much anymore. Exactly. If I had to sum up Rust's philosophy in one sentence, this would basically be it. (Add "and performance" after "safety" too.) :)

Safe. Productive. Fast.

Choose any three.

(Taking a hint from SQLite.)

Re: Why Rust for Low-Level Linux Programming?

#133
post #4

As a long-time developer marketing person, I must say Rust is kicking ass, not just as a language but as a community. They are deeply strategic. 1. Clear audience target: They aren't going after C++ gurus or C magicians but people who are new to systems programming. From Klabnik to Katz to literally everyone in the community, they are consistent with this messaging. 2. As part of 1, they have invested a lot in teachi…

C gets out of the way and lets you do useful things that are "undefined behavior". How convenient is it it Rust, to, say, use the unused bits in a pointer (due to alignment) and put a type tag in them?

Re: Why Rust for Low-Level Linux Programming?

#134

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…

> I didn't cherry-pick; in 5/10 benchmarks, C is twice as fast as Rust. Making the claim that C is twice as fast as Rust because of 5/10 benchmarks in the "benchmark game" shows an incredible lack of common sense to me. In 5/10 benchmarks, the benchmark games claims Go has equal if not better performance than Rust. Am I supposed to believe now, that a managed, garbage collected, 6-year-old compiler, language is as fa…

> Making the claim that C is twice as fast as Rust because of 5/10 benchmarks in the "benchmark game" shows an incredible lack of common sense to me.

Actually, 2x is likely the lower bound of how much faster well-written C is over Rust. Rust developers have an interest in promoting their language so they will make sure their test programs runs as fast as possible. C doesn't need that kind of marketing.

For example, the Rust solutions were all updated in 2015 while the C solutions hasn't been touched since 2013.

> In 5/10 benchmarks, the benchmark games claims Go has equal if not better performance than Rust. Am I supposed to believe now, that a managed, garbage collected, 6-year-old compiler, language is as fast as as language without a runtime running on LLVM?

It doesn't run on LLVM. It takes advantage of LLVM to compile ELF executables. I said that common sense should be used.

Re: Why Rust for Low-Level Linux Programming?

#135
post #4

As a long-time developer marketing person, I must say Rust is kicking ass, not just as a language but as a community. They are deeply strategic. 1. Clear audience target: They aren't going after C++ gurus or C magicians but people who are new to systems programming. From Klabnik to Katz to literally everyone in the community, they are consistent with this messaging. 2. As part of 1, they have invested a lot in teachi…

I suppose I'm in their target audience, then. I've not done any systems programming, but do have a curiosity about it, and Rust has caught my eye.

But my main problem is a lack of a project -- a ThingIWantToDo that would be well suited to a systems programming language like Rust. And I don't even know what kinds of problems or projects are well suited to systems programming -- so far, when I've had an itch to scratch and gone to scratch it, I've found Python able to do what I want.

Now I realize that Python is in no way appropriate for all classes of problems, and that there problems for which it is not fast enough. But thus far, the only project I'd like to tackle that I know Python will be too slow for is doing real-time audio processing on Linux with lv2 plugins and JACK. But lv2 and JACK are C APIs, so that's incentive for me to learn C, not Rust.

Understand, this isn't a knock against Rust. As I said, it's caught my eye. I just haven't found a compelling reason to actually get involved yet. I am hoping I eventually will.

Re: Why Rust for Low-Level Linux Programming?

#136
post #68

Earlier quoted context omitted.

> The only reason you would is ease of updating dependencies Or if Rust doesn't support your OS yet. I am working on porting LLVM and writing a MIR to C++ translator in parallel. We'll see which one I get further on. Because I'd love nothing more than to use Rust.

Is the problem the OS, or the architecture/ABI? I wouldn't expect porting to a new OS to be terribly difficult, though it is a time sink since there's a fair bit of API surface to cover to get Rust's libstd ported, and you'd want to work with upstream so they know your platform matters. If your OS doesn't look at all like UNIX, then you'll have to give up on libstd (which talks about "file"s and "processes" and such…

It's a platform with a file format and linker sections that are currently unsupported by LLVM, among other issues.

Re: Why Rust for Low-Level Linux Programming?

#137
post #114

Earlier quoted context omitted.

Yes, Rust is younger. There is less code out there running to root out undefined behavior. Except Rust allows for less undefined behavior. I wouldn't be surprised if it improved at a faster rate then C. Or C++ ( ) ( ) Please don't say C/C++. They are different beasts.

Even the name tells you that C++ was originally designed to be C with extra features. It can still be used that way and frequently is. These days, there are contexts in which the differences are very significant, and there are many others where any statement about either applies to both, and in those latter contexts "C/C++" is completely valid.

And C++ was originally just a C pre-processor. It's not anymore. So what it was originally is not that relevant nowadays. And that's the whole point. They have diverged too much.

These contexts you speak of are rare enough that the "no-C/C++" heuristic is useful.

Re: Why Rust for Low-Level Linux Programming?

#138

Earlier quoted context omitted.

I'll just say - I've generated A Great Deal of 'C' code. It's not hard to avoid UB at all. You only use a very concise subset of the language. YMMV. This sounds more like generating 'C' is a distraction rather than a goal.

It is certainly not impossible. I think it's just presented as a bit more trivial than it is. You can generate C, but is it easy to generate good C? That's what I was trying to get at with the LLVM comments. Rust relies a lot on a good optimizer; a straightforward transformation might be significantly slower.

Agreed. I did not mean to minimize the effort involved.

Re: Why Rust for Low-Level Linux Programming?

#139

Is there any reason why embedded software for autonomous vehicles is still being written in C/C++? This last week I was talking to a friend at a company that makes a small autonomous vehicle. During testing their prototype suddenly went off in a straight line. They had to pull a safety to halt the vehicle or it would have gone straight forever into the Pacific Ocean. Turns out there was an unsafe access to a variable…

There's two reasons Rust might not be ready here yet. First, while LLVM supports a wide number of platforms, some embedded devices literally only support the exact version of the C compiler they ship to you, sometimes, it's even got its own custom patches. Second, we sort of assume 32 bits at the lowest, though we have a patch in the queue that starts some work on 8/16 bit support. This means some tiny micros are out…

> we have a patch in the queue

If you mean this one[1], it's merged. Still lots of work to do, and even more corners where things will shake out[2], but there's definitely progress.

[1]: https://github.com/rust-lang/rust/pull/33460 [2]: https://github.com/rust-lang/rust/pull/34174

Re: Why Rust for Low-Level Linux Programming?

#140
post #19

Earlier quoted context omitted.

As a C magician, I haven't written a new C project since the Rust 0.8 era. The only reason you would is ease of updating dependencies through distro package managers (because Rust has no stable ABI and performs extensive cross-library inlining). There's no need to market to C people because those who understand the language well will immediately get why Rust is better. For C++ people, Rust's generics remain less powe…

Can someone explain why Rust doesn't have an ABI? I understand that its a still a newish language but hasn't it been around long enough to want to define one? Is the idea that it won't have one just like C doesn't have one and you will have a few like how C has stdcall, cdecl and fastcall?

Don't prematurely publish your interface.
Post reply on HN