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

141–150 of 231 posts

Re: Why Rust for Low-Level Linux Programming?

#141

Post by kbenson »

korethr wrote: post #135
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…

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…

> But lv2 and JACK are C APIs, so that's incentive for me to learn C, not Rust.

Maybe, but it might be an incentive to learn just enough C that you can wrap the C interface in Rust. The point of having an API is to have well defined behavior at a particular boundary, which can reduce quite a bit (but not eliminate) a lot of the reasons to use the language it was implemented in on the caller side.

I suspect learning rust will probably make you familiar enough with the basics of C that you won't have to do much specific C learning to use most libraries.

Re: Why Rust for Low-Level Linux Programming?

#142

Post by dbaupp »

Bromskloss wrote: post #92
dpc_pw wrote: post #59

Earlier quoted context omitted.

Rust can, somewhat is already and ultimately will beat C on performance, due to way better guarantees on pointer non-aliasing. See eg. http://stackoverflow.com/questions/146159/is-fortran-faster-... Other than that Rust has way better zero-cost abstractions, so in practice allows writing faster code, as in C there are sanity limits after which you give up and write slower, but easier to manage code, as macro processo…

What are we looking for in the qsort example? Is there a Rust equivalent we should compare to?

The C code is forced to use a function pointer and hence do dynamic virtual calls for each comparison, while Rust and C++ can use generics/templates to get static dispatch (and hence inlining, constant folding etc.). You can see C vs. C++ in http://www.martin-ueding.de/en/programming/qsort/index.html , and Rust is likely to be similar to C++.

Re: Why Rust for Low-Level Linux Programming?

#143

Post by crypto5 »

ArkyBeagle wrote: post #111
DonaldFisk wrote: post #84

Earlier quoted context omitted.

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.

Wiki says it is proprietary..

Re: Why Rust for Low-Level Linux Programming?

#144

Post by CUViper »

Animats wrote: post #118

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…

Redox may be exactly what you're looking for: http://www.redox-os.org/

And there are others: http://wiki.osdev.org/Rust

Re: Why Rust for Low-Level Linux Programming?

#145

Post by korethr »

kazinator wrote: post #133
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…

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?

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?

Re: Why Rust for Low-Level Linux Programming?

#146

Post by tbirdz »

valarauca1 wrote: post #65
quickben wrote: post #55

Earlier quoted context omitted.

GPUs aren't panacea. Such generalizations are wrong and will have you rearchitecture approaches after GPU io bottlenecks.

>GPUs aren't panacea. Such generalizations are wrong This is true. But if you are doing hard number crunching you are using a GPU once you exhaust what a CPU can do. And most the time before you even touch SIMD as it's only a 4-8x speed up, while a GPU is 1000-10,000x. >will have you rearchitecture approaches after GPU io bottlenecks. 90% of these are caused by bad software. Either using legacy API's. Or by writing c…

It's not the bandwidth that's the problem, it's the latency. Many problems need more control flow and branching, and that is better done on the CPU. If you need to make decisions and take the previous iterations output as an input, then the overhead of transferring the data back and forth from cpu to gpu outweighs the benefit of the gpu speed.

GPUs are good if you have an independent data parallel algorithm you are using to transform large blocks of floating point data. For other uses, CPU is better.

Re: Why Rust for Low-Level Linux Programming?

#147

Post by to3m »

korethr wrote: post #145
kazinator wrote: post #133

Earlier quoted context omitted.

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?

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?

You might do it if you were writing an implementation of a language such as Scheme.

Re: Why Rust for Low-Level Linux Programming?

#148

Post by steveklabnik »

shepmaster wrote: post #139
steveklabnik wrote: post #16

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…

> 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

Ah nice! I was unsure if the first had gotten through bors yet or not, and I was pretty sure the second one hadn't.

Re: Why Rust for Low-Level Linux Programming?

#149

Post by digi_owl »

gue5t wrote: post #117
bogomipz wrote: post #107

Earlier quoted context omitted.

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 ba…

Or how about we avoid the whole thing and allow multiple versions of a lib to exist, and then prune the branches as they are no longer needed? Something akin to Nix/guix, Gobolinux, or even GNU Stow.

Re: Why Rust for Low-Level Linux Programming?

#150

Post by Matthias247 »

RealityVoid wrote: post #98
DonaldFisk wrote: post #84

Earlier quoted context omitted.

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?

While a decent guideline, MISRA does not guarantee correctitude. There are many ways you can twist code that MISRA will not complain but the code will be wholly broken. I do not know what kind of unsafe memory access happened in their systems, but you can do all sorts of memory opperations and as long as the explicit typecasts are a-ok misra won't flinch.

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