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

Rewrite Everything in Rust

robert.ocallahan.org

Post reply on HN
Print view View original

81–90 of 242 posts

Re: Rewrite Everything in Rust

#81

Post by wspeirs »

d0mine wrote: post #65
wspeirs wrote: post #35

Earlier quoted context omitted.

Do people think companies would pay for a closed-source glibc if it were shown to be 100% compatible with the current glibc, but written in Rust?

The issue with is that if you substitute social norms with money; it is hard to return to social norms later I.e., if you start paying; you have to continue paying. Predictably Irrational http://whistlinginthewind.org/2013/01/15/predictably-irratio...

What's wrong with continuing to pay? All the time companies pay for support for open source software because they want the "insurance" of having someone to call when the $hit hits the fan.

You don't want to pay anymore, go back to glibc...

Re: Rewrite Everything in Rust

#82

Post by dikaiosune »

rubiquity wrote: post #18
pcwalton wrote: post #11

Earlier quoted context omitted.

> A rewrite would clean up the code, sure, but then you're left in the same situation, only with brand new bugs that nobody has time to fix. The entire point is that you're not in the same situation regarding memory safety problems/vulnerabilities.

I think what GP is saying that you'll have problems in logic or other typical programming problems and that it isn't a lack of language features/safety but rather time/money being thrown at these libraries I imagine the top two reasons unsafe memory access happen is: 1) other complicated logic seeped into the memory sensitive area or causes programmer fatigue 2) memory management is hard Rust helps with #2 but let's…

Re: amount of low level code needing unsafe blocks, its worth checking out this series that documents creating a bare metal kernel in rust that has lots of type safety and uses shockingly little assembly or unsafe:

http://os.phil-opp.com/

Re: Rewrite Everything in Rust

#83

Post by ajdlinux »

justinmk wrote: post #27
panic wrote: post #9

I think this misses the real problem. So many pieces of foundational software like glibc and OpenSSL are understaffed, underfunded, and plagued by terrible code. Go read glibc getaddrinfo: it's a mess! Rewriting the software in Rust would not solve these problems any more than rewriting it in C++ would. A rewrite would clean up the code, sure, but then you're left in the same situation, only with brand new bugs that…

This is why I personally think the OSS community should be more encouraging of "salary" style funding. There is a loud, poisonous minority of advocates that seem to think that asking for money is just plain evil. That attitude is a material disservice to OSS in general: it makes OSS weaker and less capable, for the sake of some weird puritan reflex. N.B.: I have never and will never ask for, nor accept any income fro…

There seems to still be too many people who cling to the romantic notion that Free Software must be produced for free, as a pure labour of love.

It's absolute nonsense - so many of the most successful free/open source software projects are those with salaried employees working on it, and this has been the case for many years. The problem today is of course finding a way to fund open source contributors whose projects aren't quite aligned with the needs of a major company.

Re: Rewrite Everything in Rust

#84

Post by ubernostrum »

_b wrote: post #67

C++ is getting compile time checks for type, bounds, and lifetime safety, which steals nearly all of Rust's safety thunder. See Herb Sutter's talk at CppCon: http://herbsutter.com/2015/09/27/my-talk-at-cppcon/ For most applications, moving to modern C++ is going to be a better option than rewriting in Rust.

For most applications, moving to modern C++ is going to be a better option than rewriting in Rust.

I wouldn't bet on that.

Companies which go with a language like C++ don't do it for "safety" or "performance" or reasons like that (at least, most of the time they don't). They go with it because they can get something written once, then run it for the next half-century and only have to spend engineering time on new features and the occasional critical bug. Telling them they need an intrusive rewrite of their entire codebase to use modern practices will simply result in either (A) no action taken (most likely) or (B) the rewrite happening in a language that isn't C++.

This is incidentally what happened with quite a few significant Python codebases in the 2/3 transition -- rather than rewrite their code to Python 3 standards, they said "eh, we're rewriting anyway, let's go to Lua" (most often, though some other languages were the "let's go to" option as well).

Re: Rewrite Everything in Rust

#85

Post by stuaxo »

panic wrote: post #9

I think this misses the real problem. So many pieces of foundational software like glibc and OpenSSL are understaffed, underfunded, and plagued by terrible code. Go read glibc getaddrinfo: it's a mess! Rewriting the software in Rust would not solve these problems any more than rewriting it in C++ would. A rewrite would clean up the code, sure, but then you're left in the same situation, only with brand new bugs that…

Funny, I've just been thinking the same.

Originally I thought it was just joe-randoms-query lib I used in project at work.

But the last year I had time to look at more desktop bound programming and see that it really is the whole stack.

Re: Rewrite Everything in Rust

#86

Post by castratikron »

panic wrote: post #9

I think this misses the real problem. So many pieces of foundational software like glibc and OpenSSL are understaffed, underfunded, and plagued by terrible code. Go read glibc getaddrinfo: it's a mess! Rewriting the software in Rust would not solve these problems any more than rewriting it in C++ would. A rewrite would clean up the code, sure, but then you're left in the same situation, only with brand new bugs that…

>We need to have incentives for maintaining this foundational software.

It's my opinion that contributing to free software is a public good, and so we should have state-funded employees whose full-time job is to work on this software. I think something like this is already done in places like France and Europe, but to my knowledge the majority of paid-for American contributions to FLOSS comes from corporations.

Re: Rewrite Everything in Rust

#87

Post by jeswin »

wangchow wrote: post #73

Just gonna throw this out there: what if instead of working on creating the myriad of "better languages" we focus on actual mastery of simpler languages like C. And with that mastery: what about writing some machine-learning software that detects vulnerabilities as part of the build/release cycle. For instance: http://news.mit.edu/2016/faster-automatic-bug-repair-code-er... To detect vulnerabilities people need to be…

>Just gonna throw this out there: what if instead of working on creating the myriad of "better languages" we focus on actual mastery of simpler languages like C.

Relying on people being careful does not work for security, where one exploit is as good as many. OTOH, simpler languages can work well for performance, features and almost everywhere else; where even if you don't have specific language features to guard against common mistakes, the impact of an oversight is fairly localized or correctable.

Re: Rewrite Everything in Rust

#88

Post by ubernostrum »

wangchow wrote: post #73

Just gonna throw this out there: what if instead of working on creating the myriad of "better languages" we focus on actual mastery of simpler languages like C. And with that mastery: what about writing some machine-learning software that detects vulnerabilities as part of the build/release cycle. For instance: http://news.mit.edu/2016/faster-automatic-bug-repair-code-er... To detect vulnerabilities people need to be…

we focus on actual mastery of simpler languages like C

We've had 44 years for people to master the "simplicity" of C. Turns out, writing C is simple but writing safe, reliable C borders on the impossible even for the most masterful masters who ever mastered their mastery of the language. Better return on investment would be to work on killing C with something that doesn't have C's problems.

Re: Rewrite Everything in Rust

#89

Post by lawpoop »

castratikron wrote: post #86
panic wrote: post #9

I think this misses the real problem. So many pieces of foundational software like glibc and OpenSSL are understaffed, underfunded, and plagued by terrible code. Go read glibc getaddrinfo: it's a mess! Rewriting the software in Rust would not solve these problems any more than rewriting it in C++ would. A rewrite would clean up the code, sure, but then you're left in the same situation, only with brand new bugs that…

>We need to have incentives for maintaining this foundational software. It's my opinion that contributing to free software is a public good, and so we should have state-funded employees whose full-time job is to work on this software. I think something like this is already done in places like France and Europe, but to my knowledge the majority of paid-for American contributions to FLOSS comes from corporations.

How would we decide what specific projects are actually worked on?

Re: Rewrite Everything in Rust

#90

Post by unscaled »

dikaiosune wrote: post #72
_b wrote: post #67

C++ is getting compile time checks for type, bounds, and lifetime safety, which steals nearly all of Rust's safety thunder. See Herb Sutter's talk at CppCon: http://herbsutter.com/2015/09/27/my-talk-at-cppcon/ For most applications, moving to modern C++ is going to be a better option than rewriting in Rust.

But the core guidelines are optional -- which means that you'll still have the entirety of C/C++ footgun hell to watch out for, and decades of outdated teaching and learning materials. And very large codebases which could not be easily ported to a compiler that enforced those guideines. I will be happy if Rust's main impact on history will have been to showcase how to get those safety features into a practical langua…

Looking at the presentation it looks like you can borrow a non-const reference (in rust parlance) several times, so there's no concurrency guarantee.

You would have to break compatibility with too much existing code to get the same level of strictness as Rust, so that's reasonable, but yeah, it's hard to imagine that C++ will be as safe as Rust. I'm glad these features are being pushed through though.

Post reply on HN