Rust is not a good C replacement • Hacker News Board

Re: Rust is not a good C replacement

#171

Post by xiphias2 » Mon, Mar 25, 2019, 10:19 PM UTC

xiphias2 wrote: post #25

adamnemecek wrote: post #9

OK looking Just at the number of features seems disingenuous. Cpp features tend to idk, increase the level of complexity as there tends to be quite a bit of friction between them. Rust features definitely “work together”. This post seems to have started with a conclusion and worked backwards. Rust is such a breath of fresh air. Cargo is nuts. The community is nuts. I’ve been writing rust full time for a couple of mon…

The main problem with C++ are not the new features, but the old obsolate ones. It's too late to fix the language.

I'm not sure why I'm being downvoted...I'd love to have an explanation from that person of how much diamond inheritance benefits our lives and makes it so much simpler to write maintainable code.

Re: Rust is not a good C replacement

#172

Post by erk__ » Mon, Mar 25, 2019, 10:39 PM UTC

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…

A study backed by microsoft recently released a version of C that can be statically checked https://github.com/Microsoft/checkedc

Re: Rust is not a good C replacement

#173

Post by erk__ » Mon, Mar 25, 2019, 10:45 PM UTC

wyldfire wrote: post #40

> C is the most portable programming language. This is a function of popularity and time. > C has a spec. No spec means there’s nothing keeping rustc honest. Agreed, language specification is critical. The language reference [1] is very detailed, though. I'm not sure what it would take to promote this to a "specification." > That really cool feature $other_language has? Not interested. It’ll be more trouble than it’s…

> > C has a spec. No spec means there’s nothing keeping rustc honest.

>Agreed, language specification is critical. The language reference [1] is very detailed, though. I'm not sure what it would take to promote this to a "specification."

But even the C specifications is mostly informal, there are some parts of C that has formal specification but to my knowledge not everything is. Where as something like SML has a full formal specification. Which mean that you do not have any undefined behaviour.

http://sml-family.org/sml97-defn.pdf

Re: Rust is not a good C replacement

#174

Post by steveklabnik » Mon, Mar 25, 2019, 10:47 PM UTC

erk__ wrote: post #172

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…

A study backed by microsoft recently released a version of C that can be statically checked https://github.com/Microsoft/checkedc

That some stuff can be, of course:

> Static checking enforces the integrity of the bounds information and allows the eliding of some dynamic checking. Dynamic checking enforces the integrity of memory accesses at runtime when static checking cannot.

Re: Rust is not a good C replacement

#175

Post by kbenson » Tue, Mar 26, 2019, 1:16 AM UTC

7e wrote: post #127

Should the HN rules be amended to discourage self-authored submissions? They seem to circumvent the natural filter that comes with peer-nomination, and suggests they were written with promotion in mind.

He's had some very high quality submissions of his own posts in the past, and contributes here regularly and to the benefit of most, I believe.

I don't necessarily agree with his conclusions, nor the way in which he defended some of them here, but it's pretty clear this whole comment section went to hell pretty early, and I don't think he deserves most the blame for that. I don't think most the Rust contributors or well known advocates do either. There was a huge amount of drive-by commenting where people seemed to sense the way the wind was blowing and thought it would be a good idea to pile on. That didn't help anyone.

Re: Rust is not a good C replacement

#176

Post by jolhoeft » Tue, Mar 26, 2019, 1:31 AM UTC

steveklabnik wrote: post #63

Tomte wrote: post #34

I've been waiting so much for a way to use rustup (and Cargo, but that's beyond the pull request a bit further down) behind a MITM proxy. And since Rust has always been Windows-friendly, I had high hopes when someone actually started to implement this support (basically pass "-k" to curl). Because I had fought with all kinds of git and curl configuration files, until I realized that those don't mean anything to rustu…

Part of the issue here is that rustup has not had a dedicated maintainer in a while; we’re working on it.

Is there a link to the maintainer discussion?

Re: Rust is not a good C replacement

#177

Post by bb88 » Tue, Mar 26, 2019, 1:54 AM UTC

bhaak wrote: post #98

Sir_Cmpwn wrote: post #68

Earlier quoted context omitted.

Author here. >The main fallacy of this blog post is that he wants it to be one single programming language that replaces C. That's not at all what I'm suggesting. In fact I thought this part of the article makes it clear that I feel the opposite way: >C is far from the perfect language - it has many flaws. However, its replacement will be simpler - not more complex. Consider Go, which has had a lot of success in supp…

> It hasn’t completely replaced C The keyword here is completely . Rust doesn't need to completely replace C, it only needs to cover those usecases other languages haven't already covered. Or maybe just some and a completely different language takes what is left. You don't care that Rust is much more safe than C due to all the features it has that are unlike C. But the safety aspect is Rust's main raison d'être. If y…

> You don't care that Rust is much more safe than C due to all the features it has that are unlike C. But the safety aspect is Rust's main raison d'être.

Rust is still young. I think it's a bit naive to proclaim the language of the future is here. Why?

That was also the point of Ada until people realized that unhandled Constraint Errors could still crash missiles.

https://itsfoss.com/a-floating-point-error-that-caused-a-dam...

That was the point of Java until people realized that JRE's were full of security holes.

https://www.cvedetails.com/vulnerability-list/vendor_id-93/p...

So, what's the point of Rust again? To protect us from all these security holes? Wasn't that also the goal of other languages?

> I wonder who this "we" is?

TIOBE says C is second most popular language after Java even with all the security holes. So there's a lot of "we" (though I don't code in C).

https://www.tiobe.com/tiobe-index/

Re: Rust is not a good C replacement

#178

Post by mmstick » Tue, Mar 26, 2019, 3:59 AM UTC

bibyte wrote: post #136

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…

Yeah that's what stands out to me as well. I wish the author had put that sentence at the top. The biggest feature of Rust is it's safety. If you don't care for the biggest feature of a language then it shouldn't be a surprise that you don't like the language.

Having written Rust code for 4 years, I'd say it's not the biggest feature of Rust. It's just one of many good points. Among my favorite are the explicit & rich APIs, high level concepts (ADTs, pattern-matching, trait-based generics), and Cargo. The safety does play a big role in shaping some of the features though, and enabling some powerful APIs and optimizations.

Re: Rust is not a good C replacement

#179

Post by mmstick » Tue, Mar 26, 2019, 4:09 AM UTC

Thaxll wrote: post #154

wyldfire wrote: post #114

Earlier quoted context omitted.

> you're going to use unsafe anyway ... you don't use unsafe / low level things for higher part of the OS It seems as if you contradict yourself here. Or are you trying to suggest that Microsoft's bugs were confined to the "lower part of the OS"? > so ... So, what, exactly? Your point is not clear. Redox used Rust and held a challenge to find bugs in Redox -- which was succesful at uncovering bugs in Redox. Ergo, wha…

My point: - Redox is built in Rust and had serious memory bugs triggered by userspace applications, people claim that we should build OS in Rust because it's "memory" safe, in reality it's much more complex than that

It did not have serious memory bugs. All of the unsafe code in Redox, of which only a small fraction is unsafe, is neatly compartmentalized so that it's easy to audit.

Re: Rust is not a good C replacement

#180

Post by bluejekyll » Tue, Mar 26, 2019, 4:22 AM UTC

rhn_mk1 wrote: post #169

bluejekyll wrote: post #46

Earlier quoted context omitted.

I didn’t read the entire thread, but if I understood the gist of it, it seems like an anti-pattern is being asked for, and it would be an anti-pattern when mixing any languages. What it seems they want is the ability to mix Rust and C in the same build chain, not treat each as a separate build artifact and link at the end. I’ve never had a problem modeling things with Makefiles, having the Rust artifact target be bui…

There's a blog post diving more into the details of language cooperation from Meson's perspective here: http://nibblestew.blogspot.com/2019/02/why-is-cross-language...

Thanks for posting that. I understand what they’re getting at, but they didn’t quite convince me in the opening that this isn’t a build structure problem vs. a build tool issue. There’s a lot of work to do what they’re trying to achieve, and at best you’ll possibly get a faster build? Maybe it’s easier to configure? Though that also wasn’t obvious to me that there would be a large gain there.