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

111–120 of 231 posts

Re: Why Rust for Low-Level Linux Programming?

#111

Post by ArkyBeagle »

DonaldFisk wrote: post #84
TheMagicHorsey wrote: post #11

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 are standards (MISRA C) which are supposed to stop things like that happening. Perhaps they weren't being followed? There are other safe languages they could have used which have a longer track record than Rust, e.g. Ada. It's used in avionics. Why shouldn't it being used here?

MISRA is okay. It's not a panacea.

Re: Why Rust for Low-Level Linux Programming?

#112

Post by Cshelton »

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.

That's more about encouraging crate developers to make their package work on stable. There are crates that are made to take advantage of nightly features, but I believe many of those label them as "beta", "unstable", "only works in nightly".

Re: Why Rust for Low-Level Linux Programming?

#113

Post by ArkyBeagle »

xvilka wrote: post #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.

It's harder than it looks. If you improve things willy-nilly, then you split the language - some will use the more modern version, some will stay behind.

IMO, a better evolution is to do what the Rust folks have done - define a new language. This way it has a new name and you don't have to qualify which version of 'C' you mean.

Re: Why Rust for Low-Level Linux Programming?

#114

Post by SiVal »

outworlder wrote: post #46
Thaxll wrote: post #35

Earlier quoted context omitted.

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

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.

Re: Why Rust for Low-Level Linux Programming?

#115

Post by ArkyBeagle »

steveklabnik wrote: post #31
dv_dt wrote: post #29

Earlier quoted context omitted.

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'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.

Re: Why Rust for Low-Level Linux Programming?

#116

Post by ArkyBeagle »

gue5t wrote: post #9
Scarbutt wrote: post #2

Rust reduces the amount of state I need to keep track of in my brain. I doubt it, the mental overhead of doing "safe memory programming" in Rust is very high. Edit: all good replies, want to clarify and forgot to mention that I was comparing to languages with a GC, since I'm seeing Rust being used for lots of stuff, in a general purpose programming language sense (like creating web frameworks for example). Also, for…

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…

So what actually happens is that you develop habits to enforce invariants that lead to correct operation. This isn't nothing, but it's also good practice in other languages and the more you do it, the better you get at it and the less stressful it is.

Re: Why Rust for Low-Level Linux Programming?

#117

Post by gue5t »

bogomipz wrote: post #107
gue5t wrote: 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?

C does have a standard ABI on each platform (where "platform" is slightly vague, ranging from "a place where people agree to use the SYSV ABI" to "Windows+MSVC"), so you can generally call into C libraries from the same "ecosystem" and not have to notice if they get recompiled between runs; library maintainers can put in some work and make promises about ABI stability.

The reason Rust doesn't have a defined ABI is basically that it wouldn't buy the same benefits it does in C. Specifying an ABI requires a lot of per-platform work (which the C community has already done), and, because of the importance of cross-crate inlining (all generic functions get inlined into call-sites by default), would not be sufficient to provide the benefit of in-place library updates. If you rewrite generic code in libfoo, and libbar depends on it, you can't get around recompiling libbar.

This is basically because Rust is a higher-level language where you use iterators, iterator adaptors, and higher-order functions in the course of writing libraries and applications. In C, you would manually inline things like iteration, writing for loops and populating intermediate data structures yourself. In Rust, this is something that can be factored out into libraries, but that means your code's meaning depends more deeply on the meaning of library code. To optimize away these abstractions and provide good performance, the compiler needs to inspect and make decisions based on library source code when compiling code that calls it. To permit efficiency, Rust basically has to be compiled from leaf dependencies upward.

In general, this is probably worth it, but it means we do need to rethink the C/UNIX style of packaging, which doesn't work very well when a libstd update implies every other package must also update. Some form of compiler middle/backend in the package manager (think Android's ART compiler), or a specialized form of binary or IR diffs (like Chrome uses) would probably go a long way. If we want to solve UNIX's problems, there will be a need for some cascading changes across the OS ecosystem.

Re: Why Rust for Low-Level Linux Programming?

#118

Post by Animats »

Rather than writing for Linux in Rust, we need a new kernel written in Rust. I'd like to see a replacement for the QNX microkernel written in Rust. It's about 60K bytes of code, yet you can run POSIX programs on it. (You need file system and networking, which are user processes.) The QNX kernel is stable - it changes very little from year to year. There's hope of catching all the bugs. This offers a way out of "patch and release" OS development.

Yes, you take a 20% or so performance hit for using a microkernel. Big deal.

At one time, you could download the QNX kernel sources and look at them.[1] This would be helpful in getting the microkernel architecture right. It's very hard to get that right. See Mach or Hurd.

[1] http://community.qnx.com/sf/sfmain/do/downloadAttachment/pro...

Re: Why Rust for Low-Level Linux Programming?

#119

Post by steveklabnik »

ArkyBeagle wrote: post #115
steveklabnik wrote: post #31

Earlier quoted context omitted.

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'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.

Re: Why Rust for Low-Level Linux Programming?

#120

Post by FraaJad »

xyience wrote: post #60
Scarbutt wrote: post #2

Rust reduces the amount of state I need to keep track of in my brain. I doubt it, the mental overhead of doing "safe memory programming" in Rust is very high. Edit: all good replies, want to clarify and forgot to mention that I was comparing to languages with a GC, since I'm seeing Rust being used for lots of stuff, in a general purpose programming language sense (like creating web frameworks for example). Also, for…

This is basically why I ditched Rust as soon as I found out about Nim. No mental gymnastics making me feel like I should be part of a group mind, super fast, super small binaries, optional GC, and memory unsafe stuff allowed with standard pointers and alloc/free available with or without the GC on elsewhere. I suspect Rust would be better for avionics and other high-value systems though, replacing Ada...

I like nim for the same reason (and use for for small programs), though I'm using D at $work because D is more "mainstream" and established at this time.
Post reply on HN