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

91–100 of 231 posts

Re: Why Rust for Low-Level Linux Programming?

#91

Post by RealityVoid »

valarauca1 wrote: post #56
pjmlp wrote: post #25

Earlier quoted context omitted.

Industry standards, certified compilers and cargo cult are usually the main reasons.

This is the main reason. Also legacy. I work on a lot of embedded code for $AUTO_MANUFACTOR some of our code bases go back to the 90's. The code base is so modified by macros/typedefs its hardly even C anymore. Not to mention the LLVM has to support the embedded device you are targeting. And Rust's support of legacy CPU's (8008, 8080, 80386, 68000) are lacking.

Oh, god the macros! I also work in the auto industry and the macros are frigging everywhere and makes navigating the source a nightmare.

Re: Why Rust for Low-Level Linux Programming?

#92

Post by Bromskloss »

dpc_pw wrote: post #59
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…

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?

Re: Why Rust for Low-Level Linux Programming?

#93

Post by valarauca1 »

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

> I just don't understand lack of the life and no improvements in C for ages. Well, MSVC still hasn't even fully implemented C99. One of the big draws of C, as I see it, is its wide support on many operating systems and architectures. If you're going to abandon that by using new C features, you might as well use a language with less cruft.

>Well, MSVC still hasn't even fully implemented C99

Neither does GCC. Both don't fully implement C11 either.

Most these features are either things C-Compilers don't need to support themselves. Namely: special integer types can be placed in libraries instead of compilers.

Also bounds checking interfaces are a performance loss and not included in C compilers despite them being part of the C11 standard. (Well they're optional)

Re: Why Rust for Low-Level Linux Programming?

#94

Post by ArkyBeagle »

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…

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 there will ever be a way around developing proper test vectors. It's quite interesting work but it tends to go unrewarded.

Re: Why Rust for Low-Level Linux Programming?

#95

Post by jernfrost »

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 millions can easily be at stake if the system doesn't work.

I am an application programmer so I might not be the primary target, but I started programming with Swift and although it isn't the same as Rust it has some similarities. A lot stricter language than C++, C, Lua, Python and Objective-C which have have used most in the past. So many bugs are caught at compile time. I used to be skeptical towards static typing, primarily because languages like C++ and Java made types so awful to work with. But with the newer OOP languages with more functional inspiration, it is getting easier to deal with strict typing.

You don't have to chose between productivity and safety so much anymore.

Re: Why Rust for Low-Level Linux Programming?

#96

Post by gue5t »

steveklabnik wrote: post #73
gue5t wrote: post #68

Earlier quoted context omitted.

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…

Windows isn't like UNIX, yet still supports libstd fully. That said, yes, if your OS is so different that it doesn't support files or processes or something, you'd have to stick with libcore. The standard library not so much UNIX-centric as it is "common OS features"-centric. We even went so far as to not pick the UNIX names for common functionality, which can often happen with languages that start on a UNIX and move…

Similarity isn't a clear-cut yes/no question, but the NT kernel is so similar to UNIX that it was able to adopt a second syscall ABI compatible with Linux. Present operating systems are basically a monoculture in terms of high-level design decisions; Rob Pike complained eloquently about this in 2000, and outside of possibly unikernel development (which still usually has a libc/unix-like layer implementing at least a filesystem) little has changed since: http://herpolhode.com/rob/utah2000.pdf

Re: Why Rust for Low-Level Linux Programming?

#97

Post by ArkyBeagle »

pcwalton wrote: post #74
epoch1970 wrote: post #23

Earlier quoted context omitted.

> They aren't going after C++ gurus or C magicians but people who are new to systems programming. If this actually is their strategy, is it being done voluntarily or out of necessity? I ask, because I've witnessed enough scepticism about Rust from C and C++ programmers. Rightly or wrongly, there are enough of them who don't appear to be receptive to Rust, and likely never will be. So the Rust community may never be a…

> I ask, because I've witnessed enough scepticism about Rust from C and C++ programmers. I don't think there's a single language on the planet that hasn't had skeptics, especially at the beginning. Remember how skeptical everyone was of Python at first due to its significant whitespace? Programmers are very tribal about their tools.

Python has come a long way, but for domain reasons, the significant whitespace isn't my primary beef. Packaging is, because I haven't captured all the gnosis yet.

Re: Why Rust for Low-Level Linux Programming?

#98

Post by RealityVoid »

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?

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.

Re: Why Rust for Low-Level Linux Programming?

#99

Post by jernfrost »

ArkyBeagle wrote: post #94
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…

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 solve old problems in better ways.

Most of my co-workes doing C++ never even wanted to look at the alternatives. Being the only thing they have ever done, they don't even realize how bad it is. They have just internalized it.

Re: Why Rust for Low-Level Linux Programming?

#100

Post by steveklabnik »

gue5t wrote: post #96
steveklabnik wrote: post #73

Earlier quoted context omitted.

Windows isn't like UNIX, yet still supports libstd fully. That said, yes, if your OS is so different that it doesn't support files or processes or something, you'd have to stick with libcore. The standard library not so much UNIX-centric as it is "common OS features"-centric. We even went so far as to not pick the UNIX names for common functionality, which can often happen with languages that start on a UNIX and move…

Similarity isn't a clear-cut yes/no question, but the NT kernel is so similar to UNIX that it was able to adopt a second syscall ABI compatible with Linux. Present operating systems are basically a monoculture in terms of high-level design decisions; Rob Pike complained eloquently about this in 2000, and outside of possibly unikernel development (which still usually has a libc/unix-like layer implementing at least a…

Yeah, I'm very intrigued by unikernels myself; as far as I know, I'm the first person to have gotten an Iron web app running on Rumprun. I figured I'm the first because I had to send patches to make it work :)

I guess my point is that even if vague designs are relatively a monoculture, that still means that anything that fits inside that box is going to be reasonable to port over. And I'm glad that it's so easy to not use the standard library for other cases; my little kernel doesn't yet have processes or files, and Rust works for it just fine. Well, it doesn't have them yet, anyway... hopefully soon.

Post reply on HN