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

91–100 of 300 posts

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

#91

Post by steveklabnik »

ZoFreX wrote: post #72

Is it really the time, yet, to start advocating for rewrites in Rust? Worth considering for new projects, definitely. Using to write new components of existing projects, maybe. But rewriting existing work? I'm concerned if we start pushing that too much too early, the initial friction will burn people. You only get one first impression. For anyone who thinks "yes, now is the time" I have questions for you: Have you r…

> As far as I can tell there's no major package manager accepting or even ready to accept programs written in Rust yet. Am I misinformed?

At least Debian, Fedora, Arch, and Gentoo have rustc and cargo in their repositories. Oh and Alpine, recently. FreeBSD (IIRC) has it in ports.

In the not-too-distant future, there's a pretty important package that will require Rust: Firefox. HEAD already does today.

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

#93

Post by dikaiosune »

youdontknowtho wrote: post #87

"Rewrite it in Rust" is the new "Stallman was right" thread. Its an echo chamber of fandom. Over time I've come to despise "evangelism" or any kind. I'm sure Rust is great. I just don't think it's news every time a Rust fan says that its great. YouTube lectures of people actually using it? That would be interesting. Interviews of people actively porting a large C project to Rust. That would be interesting. Rehashing…

The author is actually using it, to actually rewrite portions of C projects in it, and writing about their experience doing this in practice. For example, the linked paper is about using Rust at the I/O boundary in an existing, complex system.

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

#95

Post by erentz »

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…

Isn't this just the nirvana fallacy? You're basically arguing that because Rust can't solve all security problems, it's not worth using it to solve some security problems, and the better option is the status quo of using languages that expose all problems.

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

#96

Post by dikaiosune »

bandook_raja wrote: post #89
anp wrote: post #81

Earlier quoted context omitted.

Can you be specific about which languages you include in the category of "fast and SAFE"?

D? GC is optional so don't even :D

How much of the standard library works without GC enabled? How many community libraries do?

D has a lot of great things (I am incredibly jealous of their metaprogramming facilities sometimes), but it doesn't seem like many people are successfully using it in the "fast and SAFE" sense as GP defined it.

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

#97

Post by concede_pluto »

mrkgnao wrote: post #17
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!

HN supports a funky subset of Markdown. :(

Only paragraphs, code literals, italics, and URLs.

https://news.ycombinator.com/formatdoc

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

#98

Post by abiox »

rurban wrote: post #74
ekidd wrote: post #26

The author focuses on rewriting low-level media decoders in Rust. I have bit of experience in this area. I've been slowly working on an MPEG2 binary subtitle decoder in Rust: https://github.com/emk/subtitles-rs A while back, I ran my subtitle decoder through "cargo fuzz", and I was pleasantly surprised at the results: Close to half a billion fuzz runs found 5 runtime panics, all of which were detected by Rust before…

I don't agree with the underlying thesis: In 15 years, I'll be heartbroken if we're still facing an endless stream of security updates and remote root compromises when all these projects were rewritten in a popular but unsafe language: Rust. There do exist fast and SAFE language out there. With guaranteed memory safety, null pointer safety, concurrency safety, dead-lock freedom, race freedom, and even with normal syn…

> with normal syntax

what does this mean?

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

#99

Post by cesarb »

fpgaminer wrote: post #75
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…

Sigh. This again. The Rust language is more than just memory safety. Memory safety is certainly the most prominent and unique feature of Rust, but the language also includes a lot of features that make writing good, bug-free code easier. For example: `Result`, when returned, forces all callees to check for errors. It's all too easy to throw away error codes in C/C++. This is probably one of the most important feature…

> `OsRng` in the rand crate (go ahead, try to write a function that safely reads urandom in C).

Nowadays, you should just call getentropy (http://man7.org/linux/man-pages/man3/getentropy.3.html) instead of trying to read from /dev/urandom, unless you have special requirements.

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

#100

Post by ZoFreX »

steveklabnik wrote: post #91
ZoFreX wrote: post #72

Is it really the time, yet, to start advocating for rewrites in Rust? Worth considering for new projects, definitely. Using to write new components of existing projects, maybe. But rewriting existing work? I'm concerned if we start pushing that too much too early, the initial friction will burn people. You only get one first impression. For anyone who thinks "yes, now is the time" I have questions for you: Have you r…

> As far as I can tell there's no major package manager accepting or even ready to accept programs written in Rust yet. Am I misinformed? At least Debian, Fedora, Arch, and Gentoo have rustc and cargo in their repositories. Oh and Alpine, recently. FreeBSD (IIRC) has it in ports. In the not-too-distant future, there's a pretty important package that will require Rust: Firefox. HEAD already does today.

For Debian at least, cargo isn't even in stable yet AFAIK.

And even then, having the compiler and package manager available is a step along the way, but insufficient. Anything non-trivial depends on libraries, which with C programs are typically also packages... which for my project means I need to create 73 Debian packages to distribute my software. That's a big hurdle.

Post reply on HN