Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why you should, actually, rewrite some of it in Rust

unhandledexpression.com

Post reply on HN
Print view View original

131–140 of 300 posts

Re: Why you should, actually, rewrite some of it in Rust

#131

Post by marcosdumay »

antientropic wrote: post #22
aeorgnoieang wrote: post #9

Earlier quoted context omitted.

Call Haskell from C (not C++) seems pretty easy: - [Calling Haskell from C - HaskellWiki]( https://wiki.haskell.org/Calling_Haskell_from_C ) And the FAQ on the Haskell wiki directly addresses this too: - https://wiki.haskell.org/Introduction#I_already_have_a_large... . So apparently it is doable!

It pulls in a huge runtime system, though (including stuff like garbage collection). This makes it much heavier than calling some Rust code.

True, where "huge" means something around 10MB.

For many projects that is a showstopper.

Re: Why you should, actually, rewrite some of it in Rust

#132

Post by biokoda »

bboozzoo wrote: post #130
biokoda wrote: post #92

Earlier quoted context omitted.

The relatively low portability of rust programs is definitely one of its largest shortcomings.

Can you elaborate? Although haven't tried it myself, I was under the impression that it's quite possible to write low level code for at least for x86 and ARM (and AVR?).

You can write low level code. Tier 1 platform list is very short however.

https://forge.rust-lang.org/platform-support.html

Re: Why you should, actually, rewrite some of it in Rust

#133

Post by Ar-Curunir »

falcolas wrote: post #19

Sigh. This again. Not all security vulnerabilities are due to pointer arithmetic or out of bounds execution or pick-your-rust-is-better-idiom. Heartbleed is a great example. It wasn't caused by an error with how C handles memory or strings or anything else. It was caused by failing to validate untrusted input. Rust isn't going to help you with that. Could the affected parts be re-written in a way where the boundary c…

Actually, Rust would just have panicked in the Heartbleed case: you wouldn't have been able to perform an out of bounds memory access without causing a runtime panic.

Re: Why you should, actually, rewrite some of it in Rust

#134

Post by pcwalton »

atemerev wrote: post #64
falcolas wrote: post #19

Sigh. This again. Not all security vulnerabilities are due to pointer arithmetic or out of bounds execution or pick-your-rust-is-better-idiom. Heartbleed is a great example. It wasn't caused by an error with how C handles memory or strings or anything else. It was caused by failing to validate untrusted input. Rust isn't going to help you with that. Could the affected parts be re-written in a way where the boundary c…

> It was caused by failing to validate untrusted input. Rust isn't going to help you with that. Really? Validation and sanitization are the last, not the first line of defense. It is not about erecting barriers, it is about failure modes. All your software components, from core to border, should fail fast, safe and in a predictable way -- the exact opposite of what happens in C. In any sane programming language (e.g.…

> Lack of bounds checking, not pointer arithmetic or allocation lifecycle, is the major source of security issues with existing software.

No, this is not true. Use after free is more pernicious nowadays.

Re: Why you should, actually, rewrite some of it in Rust

#135

Post by pcwalton »

dikaiosune wrote: post #90
snakeanus wrote: post #54

Earlier quoted context omitted.

How about Ada/SPARK then?

Please correct me if I'm wrong, but don't Ada/SPARK's memory safety guarantees only hold when all memory is pre-allocated? My memory is that dynamic allocations aren't visible to the proof system (this may be in plain Ada without SPARK, now that I think of it).

That is correct. Ada and SPARK do not provide memory safety in the case of dynamic memory allocation without garbage collection.

Re: Why you should, actually, rewrite some of it in Rust

#136

Post by [deleted] »

hsivonen wrote: post #114
yjftsjthsd-h wrote: post #45

Earlier quoted context omitted.

> Close to half a billion fuzz runs found 5 runtime panics, all of which were detected by Rust before they could compromise security. If I'd written this code in C, several of those errors would have been exploitable. Wouldn't the apples-apples comparison be fuzzing a C program? If AFL would catch the same bugs, Rust isn't better than C in this case.

With Rust, a panic occurs right away when the fuzzer develops input that performs e.g. out of bounds access. With C, it's possible to go wrong a little but not enough to segfault or to go wrong enough that by accident the access looks valid (for an unintended valid memory address) to a sanitizer. In that sense, fuzzing Rust is more certain to make the bad things actually be caught than with C where there's a chance t…

[deleted]

Re: Why you should, actually, rewrite some of it in Rust

#137

Post by pcwalton »

blub wrote: post #108
akavel wrote: post #18

Earlier quoted context omitted.

Oh no, no, no! Some people may reasonably, with some extreme care and diligence, maybe try to claim they can write safe and UB-free C code. If stars align properly. (See maybe SQLite. Seen as one of the pinnacles of crazy pedantism in C. Also, see the article about errors found recently in SQLite with fuzzing!) But with C++, it's just impossible for a human. It's too big, too quirky, too big, too wide, too deep, too…

I struggle to imagine how you could be more wrong. C offers minimal if any possibilities for writing safe code, while C++ offers many. Anybody who has the faintest clue about both languages should know that.

I actually feel that C++ memory management is less safe than that of C, because smart pointers provide the same opportunity for use-after-free while being much more opaque about when the destruction occurs. The rules about when destructors of temporaries are called in the evaluation of expressions are subtle.

Re: Why you should, actually, rewrite some of it in Rust

#138

Post by fuwafuwa »

faragon wrote: post #115
ndr wrote: post #67

Earlier quoted context omitted.

such as?

E.g. ABI compatibility, multi-platform support, tools, open source code base, community, etc.

ABI compatibility: Not really solved in C++ - see MSVC versus Mingw. If you're coming from the standpoint of using a Linux distro or BSD you enjoy a sanitized environment from the start.

Multi-platform support: Pray that your project's build system makes it straightforward to get all the dependencies going on every platform. Pray that your dependencies are easy to access and of the correct version. Pray that the manufacturer's fork of an ancient gcc isn't too buggy to use. C made it possible, not easy.

Tools: Both languages are too impoverished to have tooling as comprehensive as the stuff available in, for example, Java, although VS pushes very hard on this front. rustc already gives better error messages than any C++ compiler.

Code base: See the build system problem. Maintaining open source projects in C and C++ is an exercise in endurance. Single header file libraries have come into vogue as a result - and they're a hack. There is a lot of decent code in both languages not being used because it's hard to get running.

Community: Rust is in a better position here in part because it's smaller. If I encounter a C++ hacker in an online space it's just as likely to be an aggro kid as a seasoned pro.

Re: Why you should, actually, rewrite some of it in Rust

#139

Post by _dcwr »

As someone who really likes C and C++ I feel like the biggest reason for me not even thinking of Rust as a viable language right now is the community attitude. It seems so damn hostile to C and C++. Anyone who thinks C and C++ is viable is a misguided idiot, bad programmer, writing unsafe software, etc. to these people.

Some badass below even just said that "writing C++ code longer than a few lines without UB is humanly impossible". Apparently all these FUBAR C/C++ systems (Linux and Windows kernels, all? web browsers, LLVM that the dear rust uses, device drivers, web servers, router software, VMs of Lua, Python, C#, Java, ..., etc.) work well enough to transfer that kind of garbage to me.

It's a bit like the decades old vim vs. emacs, C vs. C++, C++ vs. C# vs. Java, etc. feuds.

Re: Why you should, actually, rewrite some of it in Rust

#140

Post by mhh__ »

Shriken wrote: post #34
snakeanus wrote: post #15

Why Rust? Why not Idris? Why not Haskell? Or you know, why rewrite it at all? You could instead try and use a safe C implementation (such as gcc/clang with the sanitisers or something like https://staff.aist.go.jp/y.oiwa/FailSafeC/index-en.html ), but to be frank if I was to rewrite my programs I would use a truly modern language like the ones that I mentioned above.

All of your questions are addressed in the article. > Why Rust? Why not Idris? Why not Haskell? it can easily call C code it can easily be called by C code (it can export C compatible functions and structures) it does not need a garbage collector if you want, it does not even need to handle allocations the Rust compiler can produce static and dynamic libraries, and even object files the Rust compiler avoids most of t…

These parts are true of D, and C++.

IMO Rust's only true advantage over it's direct "competitors" is it's safety guarantees.

Post reply on HN