Live data from Hacker News

Why Rust for Low-Level Linux Programming?

groveronline.com

31–40 of 231 posts

Re: Why Rust for Low-Level Linux Programming?

#31
post #29

Earlier quoted context omitted.

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…

A rust -> C compiler would be really nice for those custom/slow updating environments, but I can understand if that just too much of a distraction.

Since I got two replies with basically the same thing at the same time, I'll pick one at random and it'll serve as a reply to both. You won the coin flip :)

This is feasible in a sense, but C is a fairly tricky target to compile to: you have to make sure that you don't accidentally include UB in the code you generate. I know pcwalton has lots of feels here...

The easiest way to do it would be if LLVM had a C backend; I know that it did, but it was removed a few years back, and I haven't heard anything about it coming back into tree yet. MIR might also in theory enable new backends, but then you'd have to re-implement all of the optimizations that we currently rely on LLVM supplying.

Re: Why Rust for Low-Level Linux Programming?

#32
Well, Rust is awesome, but there is a place for C too. I just don't understand lack of the life and no improvements in C for ages. Better typing system (for example _Generic doesn't know uint8_t, etc types - they are just typedefs), 'pure' keyword for functions without side effects, tuples support, deprecate a lot of the things and so on.

Re: Why Rust for Low-Level Linux Programming?

#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 if you don't need optimal performance? Then you can use Rust. But then you can also use Go, Python, SBCL, Haskell, Java, C#...

Re: Why Rust for Low-Level Linux Programming?

#34
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…

> developer marketing person What is that? > They aren't going after C++ gurus or C magicians Don't they have anything to gain from using Rust?

> Don't they have anything to gain from using Rust?

Sure they do, but they're not throwing away a decade of hard-won experience in their specialties just to tinker; at least not with production code bases. The barrier of entry for beginner systems programmers is lower.

Re: Why Rust for Low-Level Linux Programming?

#35

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…

Rust is not stable. The language is not battle tested like C/C++.

Re: Why Rust for Low-Level Linux Programming?

#36
post #14

Earlier quoted context omitted.

Not my experience, fwiw. Rust does a great job of handling the mental overhead (am I allowed to mutate this? who owns this? what is the contract for that?) for me.

Exactly. Compiler-enforced ownership and lifetimes _dramatically_ reduces the mental overhead of memory management compared to C. It also saves time from having to run things under Valgrind and ASAN just to make sure I didn't mess up. The extra time spent getting Rust code to compile is considerably shorter than the time required to debug something Valgrind found.

I feel the same way about C++ smart pointers, which are remarkably simple to use and understand.

Re: Why Rust for Low-Level Linux Programming?

#37
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…

Or it is faster than C (http://benchmarksgame.alioth.debian.org/u64q/performance.php...). Depends which link you click on.

Re: Why Rust for Low-Level Linux Programming?

#38
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…

I'm not sure thats the best source you can use. C is listed 5 times on there, the slowest taking 15 seconds. Likewise C #3 times similarly to Rust. So is the case that C is actually faster, or did the guy who wrote C #5 optimize the code and neglected to give the same optimizations to Rust.

Re: Why Rust for Low-Level Linux Programming?

#39

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…

A bunch, including:

1. Most of those platforms don't have compilers for any languages other than C(++). If the platform has a lot of history behind it, maybe you could write it in Ada, but that's pretty much it.

2. Development tools (debuggers, static analyzers, standards compliance verification tools and so on) for C and C++ are very hard to match, both in strength and in sheer availability. In the meantime, Rust still relatively recently got decent GDB support.

3. A lot of Rust's features simply aren't needed when writing this kind of software (e.g. the breadth of features related to memory management is largely unneeded because everything is statically allocated).

4. For better or for worse, C is well-understood (C++ is... well, not that I haven't seen good safety-critical code written in C++, but in my experience, C++ code is a lot easier to get wrong, both by humans and compilers). Rust isn't, not yet in any case. There's no Rust equivalent for e.g. MISRA, and not because Rust doesn't need one.

5. To, uh, put it bluntly -- C and C++ are very well known in the far corners of the world where a lot of this software is outsourced. Rust -- not so much, because outsourcing companies don't really encourage their employees to learn this kind of stuff.

6. There's a lot of commercial risk involved. I'm not sure about autonomous vehicles, this is probably a more volatile field, but many safety-critical systems have to be maintained for a very long time (10 years is fairly common, and 15-20 isn't unheard of). Rust may well be dead and burried ten years from now, whereas language enthusiasts have been singing requiems to C (on roughly the same tune as Rust, no less) for almost thirty years now.

Rust is a great development in this field and I can't wait for the day when we'll finally put C (and especially frickin C++, Jesus, who writes that!) to sleep, but it's at least five years away from the point where I'd even half-heartedly consider it for a project with critical safety requirements.

> If their code was written in Rust, that sort of bug could not have occurred.

I don't know the specifics of the bugs you mentioned, so I can't really comment on this, but in my experience, most of the similar claims that float around the Interwebs are somewhat exaggerated when put in their proper context. E.g. Heartbleed, which wasn't because C something something PDP-11, but because someone decided to be smart about it and implement their own (buggy) memory management system so as to make the damn thing run decently on twenty year-old operating systems.

I've seen people write that kind of code, for similar reasons, in Java and Go -- and, at least once, with Heartbleed-like results. The ways in which a language can be misused rarely reveal themselves before that language breaks out of its devoted community.

To be clear on it though -- I think Rust is a step in the right direction, and one that we should have taken a long, long time ago. If it can make it through its infancy, and if it can get enough commercial support, it will be a great alternative to C and C++.

Re: Why Rust for Low-Level Linux Programming?

#40
post #35

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…

Rust is not stable. The language is not battle tested like C/C++.

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.
Post reply on HN