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

101–110 of 231 posts

Re: Why Rust for Low-Level Linux Programming?

#101

Post by pcwalton »

M2Ys4U wrote: post #89
pcwalton wrote: post #70

Earlier quoted context omitted.

> What, if anything, is being done to try to inform these people that the situation has changed, to encourage them to try Rust again? What's being done to restore Rust's reputation? A lot? For example, "Stability as a Deliverable", which was here on HN: http://blog.rust-lang.org/2014/10/30/Stability.html I'm not sorry for opening up the language during its early development. The alternatives would have been to produc…

There are still plenty of crates that say "you need to be using nightly!". That put me off starting to develop something in Rust right now, unfortunately, because I'm a huge fan of the way Rust was developed and its core ideals.

We can't force people to use the stable version of Rust. But it does exist. And we're working on bringing the most popular nightly features to stable as soon as possible.

In any case, even if you're using nightly your code won't break nearly as much as it did pre-1.0. We use nightly in Servo and we've been through dozens of Rust upgrades that sailed through without a hitch--and we have 150+ dependencies.

Re: Why Rust for Low-Level Linux Programming?

#102

Post by ArkyBeagle »

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.

You got me as to why this is. Dude, I tried back in the day - Ada, MODULA, all those.

Maybe the "badass 'C' hax0r" meme was stronger than I realized. But I think a lot of it was just switching cost.

Re: Why Rust for Low-Level Linux Programming?

#103

Post by pcwalton »

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 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.) :)

Re: Why Rust for Low-Level Linux Programming?

#104

Post by gue5t »

mfukar wrote: post #57
gue5t wrote: post #9

Earlier quoted context omitted.

Designing memory-safe programs in C requires a programmer to reason about the same domains as doing so in Rust, but C doesn't double-check you to make sure you get everything right. With no guard rails, C is a lot more stressful. Re: reducing mental state for a programmer, algebraic datatypes in general decrease the size of the state space of your program by making many illegal states unrepresentable. Without advance…

Why are we throwing away all the work done on static & dynamic analysis tools for C programs in this kind of discussions? Programmers are crippled just for picking C? Come on..

The benefits of advanced static and dynamic analysis tools for C shine through on questions of semantic correctness (look at Coverity, Frama-C and PVS Studio), not memory safety (though they do reason about memory safety). You can achieve perfect memory safety (no false negatives and arbitrarily few false positives if you write appropriate abstractions around unsafe) with comparatively simple static analysis built into your compiler... but only if your language is designed to permit it.

In C, perfect static analysis for memory safety is impractical, and dynamic analysis is time-consuming and cannot preclude false negatives. We should work on porting tools which heuristically warn about semantic correctness concerns from operating on C to checking Rust programs, and this is probably necessary in order for some C or C++ programmers/projects to switch, but it doesn't pertain to the question of how much mental overhead there is to writing memory-safe code in either language.

Re: Why Rust for Low-Level Linux Programming?

#105

Post by martin1975 »

ktamura wrote: 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…

Thanks for pointing out the community aspect - they're welcoming, pragmatic and don't foeget, the documentation and examples are rather good.

Rust is what it took C++ 20 years to become, except anew and reimagined.

It's ready and usable, today.

Re: Why Rust for Low-Level Linux Programming?

#106

Post by Shorel »

ktamura wrote: 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…

This is something that should be done as well by the guys doing D.

Even if they can succeed by going after the C++ gurus as well.

Re: Why Rust for Low-Level Linux Programming?

#107

Post by bogomipz »

gue5t wrote: post #19
ktamura wrote: 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…

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?

Re: Why Rust for Low-Level Linux Programming?

#108

Post by ArkyBeagle »

jernfrost wrote: post #99
ArkyBeagle wrote: post #94

Earlier quoted context omitted.

But presumably some sort of bug would have. Broken is broken. If Rust correctly deduces the intent leading to the bad dereference, then it's REALLY GOOD! :) ( no snark; I hope you get my point ) Ironically, reliability is actually a value of merit with 'C'/C++ - in cases. It's just that the ways of doing that seem rather inaccessible these days, or the flow of people past seeing them is not working out. I don't think…

As a C++ developer for 13 years I got to say that language just makes screwing up so much easier. The last year I've been coding Swift and man it is so much easier to avoid so many pitfalls in C++. I could write page upon page about all the problems with C++ and how those problems don't exist in modern languages like Swift and Rust. Programming languages isn't just fashion, we invent them because we thing we can solv…

You'll get no argument from me. That RAII exists at all is the best evidence ever ( even though I've used a variation on RAII in assembly in the past ).

The interesting question is - are there actually fewer defects, objectively, or are they simply rendered .. something like latent?

One I fixed in... April - if the file system on an SD card was scrogged, writing to the file system crashes the box. So I moved the write of a configuration file from the event of a switch change ( because if the switch was never put in that position, then there was no reason to ever do that ) to the top of the program so it'd crash when you powered up.

It helps me personally to think that defects are just something I've chosen to do despite my best effort. Keeps me on my toes. I certainly understand people being fatigued by that.

Re: Why Rust for Low-Level Linux Programming?

#109

Post by Cshelton »

epoch1970 wrote: post #52
steveklabnik wrote: post #40

Earlier quoted context omitted.

I will certainly concede the second, but we put a _lot_ of effort into ensuring that Rust is stable. Things have changed a lot since the pre-1.0 days.

> Things have changed a lot since the pre-1.0 days. The instability of the pre-1.0 days left a very bad impression on many people who tried Rust then. They came to know Rust as a compile-today-but-not-tomorrow kind of language. What, if anything, is being done to try to inform these people that the situation has changed, to encourage them to try Rust again? What's being done to restore Rust's reputation?

If somebody uses a piece of software or language that is pre-1.0 with "Beta" and "unstable" written all over it and then they get mad when it changes, that is purely their fault.

The programming community of people who actually write real things and create production software, I highly doubt any of those people are the people you are referring to and thus Rust should be doing nothing to restore its reputation with those people, as they are ignorant and/or highly incompetent, and I hope they never write a piece of code that makes it into production.

Re: Why Rust for Low-Level Linux Programming?

#110

Post by bjourne »

valarauca1 wrote: post #43
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…

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. On non-SIMD tasks Rust/C are neck and neck https://benchmarksgame.alioth.debian.org/u64q/rust.html You're just cherry picking benchmarks. In the cases you care about raw number crunching power you'll likely be using a GPU not SIMD instructions as CPU's are roughly 3-4 orde…

> 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 clang 3.6.2/gcc 5.2.1 vs Rust 1.9.0 since language performance is very implementation dependent.

> On non-SIMD tasks Rust/C are neck and neck https://benchmarksgame.alioth.debian.org/u64q/rust.html

In 5 of 10 benchmarks, C is twice as fast as Rust. In one of the benchmarks where it is neck and neck, like pidigits (https://benchmarksgame.alioth.debian.org/u64q/performance.ph...) it appears to be so because both the C and the Rust variant are wrapping libgmp. GMP is written in C.

Post reply on HN