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

Rust is not a good C replacement

drewdevault.com

Post reply on HN
Print view View original

101–110 of 213 posts

Re: Rust is not a good C replacement

#101

Post by [deleted] »

sseagull wrote: post #92
jabl wrote: post #39

Earlier quoted context omitted.

> What's the roadmap for reducing the number of security flaws in C software? Thoughts and prayers.

A little controversial, but I would have liked the larger programming community to address this rather than write completely new languages. Think of all the effort that has gone into rust. Compilers, package managers, libraries, etc. What would have happened if that same effort went into better analyzers, linters, compilers, etc, for C/C++? Rather than rewriting everything to be made "perfect" (which will never happe…

[deleted]

Re: Rust is not a good C replacement

#102

Post by steveklabnik »

sseagull wrote: post #92
jabl wrote: post #39

Earlier quoted context omitted.

> What's the roadmap for reducing the number of security flaws in C software? Thoughts and prayers.

A little controversial, but I would have liked the larger programming community to address this rather than write completely new languages. Think of all the effort that has gone into rust. Compilers, package managers, libraries, etc. What would have happened if that same effort went into better analyzers, linters, compilers, etc, for C/C++? Rather than rewriting everything to be made "perfect" (which will never happe…

The reason that this wasn't done is that we believed (and it still seems to be true) that you cannot make C or C++ be memory safe at compile time. Or rather, you cannot do it without introducing backwards incompatibility, which means you're effectively making a new language anyway, and something that's a non-starter for those languages. (as it should be, IMHO.)

It had nothing to do with "sexy" and everything to do with engineering goals. I assure you, a lot of work in Rust is dirty, political, and not sexy too :)

Re: Rust is not a good C replacement

#103

Post by Thaxll »

clouddrover wrote: post #8

> But now you know why we are still writing C, and hopefully you’ll stop bloody bothering us about it. I don't think anyone will stop bothering them about it until C software security improves. Microsoft found that 70% of security bugs in their software were memory safety issues: https://www.zdnet.com/article/microsoft-70-percent-of-all-se... Languages like Rust are making an effort to address these issues. What's th…

This is an OS problem, Rust won't save you there because you're going to use unsafe anyway, in Rust you would create wrappers for the unsafe part, they probably do the same in C/C++ for OS, you don't use unsafe / low level things for higher part of the OS.

Redox is an OS written in Rust and had kernel panic with bad arguments passed to a user space program so ... ( it was a community challenge from 2 years ago )

I think Rust has a good vision for security but it's clearly not bullet proof as people seem to think, especially not on the low level fields like OS.

Re: Rust is not a good C replacement

#104

Post by wyldfire »

Meta: feel free to flag or downvote this post.

Please do not downvote Sir_Cmpwn just because you disagree with what they've written. Instead, please try to formulate a rebuttal comment here or your own blog post.

Re: Rust is not a good C replacement

#105

Post by jhasse »

ddevault wrote: post #86
jhasse wrote: post #81

Earlier quoted context omitted.

> I wouldn't call C++ a wild success. It's failed to supplant C for its entire life, and thrives only in a few niches. Aren't web browsers one of the most used consumer software today? I wouldn't call them niche.

I was measuring by number of projects. Consider that most web browsers also depend on a dozen or more C libraries.

> I was measuring by number of projects.

I think even going by that metric C++ does pretty good.

Not exactly "number of projects", but here are some numbers:

GitHub statistic: https://octoverse.github.com/projects.html C++: 5th place C: 9th place

StackOverflow survey: https://insights.stackoverflow.com/survey/2018/ C++: 10th place C: 11th place

> Consider that most web browsers also depend on a dozen or more C libraries.

That just shows that C is a wild success, too ;)

Re: Rust is not a good C replacement

#106

Post by rhn_mk1 »

sseagull wrote: post #92
jabl wrote: post #39

Earlier quoted context omitted.

> What's the roadmap for reducing the number of security flaws in C software? Thoughts and prayers.

A little controversial, but I would have liked the larger programming community to address this rather than write completely new languages. Think of all the effort that has gone into rust. Compilers, package managers, libraries, etc. What would have happened if that same effort went into better analyzers, linters, compilers, etc, for C/C++? Rather than rewriting everything to be made "perfect" (which will never happe…

To me, it's quite clear: the target language would have forked from its base, creating of necessity an incompatible ecosystem (no one wants an improvement after which you still can still make the same old mistakes, and some mistakes are emedded in the C/C++ syntax), and we'd end up with something slightly worse than Rust, using somewhat more familiar tools.

Re: Rust is not a good C replacement

#107

Post by reacweb »

jonathanstrange wrote: post #6

Lack of a formal specification and/or an international standard is the real bummer. That's the biggest disadvantage in comparison to languages like Ada and C.

The standard may have been beneficial to Ada, but for C, this has introduced all the undefined behaviors that have been abused by optimizer.

Re: Rust is not a good C replacement

#108

Post by BubRoss »

beders wrote: post #11

> Safety. Yes, Rust is more safe. I don’t really care. In light of all of these problems, I’ll take my segfaults and buffer overflows. I especially refuse to “rewrite it in Rust” - because no matter what, rewriting an entire program from scratch is always going to introduce more bugs than maintaining the C program ever would. And that is why we can't have nice things. "I don't really care" if someone overflows my buf…

I'm not sure why a programmer who is making something for others would even say 'I don't care'. Someone wrote a post saying that python was slow and they don't care.

Users do care. They care if something is fast, they care if it bloated and takes forever to load, or if it crashes or if it is insecure.

Re: Rust is not a good C replacement

#109

Post by notacoward »

> A program which uses poll effectively is going to be simpler, reasonably performant,

Only for newbie values of "performant". I work on data-storage servers. It has been quite a few years since I've worked on one that didn't absolutely need to take advantage of multiple cores to get competitive performance, and I'm very far from being alone in this need. Splitting one server into many separate processes is not a solution in these cases, as it just moves complexity from the in-process domain to the between-process domain where it's even harder to maintain good performance (or even validate correctness). As soon as I read "concurrency is generally a bad thing" the author lost all credibility.

Re: Rust is not a good C replacement

#110

Post by skybrian »

steveklabnik wrote: post #83
skybrian wrote: post #67

Earlier quoted context omitted.

On the other hand, Go has a very readable specification that was written early and is maintained to always be up to date. Why couldn't the Rust team maintain a spec and keep it up to date by changing it in the same pull request that changes a language feature in the compiler? This seems like mostly a matter of discipline.

> Why couldn't the Rust team maintain a spec and keep it up to date by changing it in the same pull request that changes a language feature in the compiler? This seems like mostly a matter of discipline. It's not that, it's that we take the idea of a spec very seriously. We want to have a spec that's extremely solid, and so there's a lot of foundational work that needs to be done first. That work has been ongoing. No…

Okay, but this seems like letting the perfect get in the way of the good? A maintained, readable, informal spec should be quite useful as a starting point for writing a more formal spec later.

It need not be definitive. It would be quite reasonable to point out areas that aren't nailed down yet - this is also useful for the reader.

Post reply on HN