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

151–160 of 213 posts

Re: Rust is not a good C replacement

#151

Post by mjw1007 »

chessturk wrote: post #128
mjw1007 wrote: post #62

I think there is a gap in the market for small language which is just a "better C", but developing a new language is a great deal of work, and it would be hard to compete against the alternative of using a small subset of {Ada, Rust, whatever}. Maybe the large languages should look at defining official subsets, to make life simpler both for programmers and validation. Ada used to have something of the sort (and still…

I'm curious if you consider Nim or Golang to be a small language that is a "better C". If not, why?

I don't think they count as a "better C" for this purpose. I'm thinking of something aiming at the niche that C currently fills.

Having a garbage collector doesn't fit that, and Nim doesn't look small (anything with both destructors and exceptions is getting into complications rather beyond C).

Re: Rust is not a good C replacement

#152

Post by burntsushi »

_nalply wrote: post #149

It seems that the Rust community is already slowing down with new features. Have a look at "This Week in Rust" updates: the section "Approved RFCs" has the text "No RFCs were approved this week" almost every week now. There also was a discussion of designing 2019 as the fallow year and going more slow than before.

That's true, and personally, I hope it continues. However, there are some significant new features that have already been approved that are being worked on right now. e.g., Specialization, const generics and generic associated types. Each of these is somewhat significant in that they might alter how one might write some kinds of code today. But generally, they open new doors by adding more expressiveness to the type system.

Re: Rust is not a good C replacement

#153

Post by phaazon_ »

I read through the article and I recognized the pattern of an old C cave bear that refuses to learn new things and understand why safety and type theory matters. Lots of arguments made in that post are either unfair (i.e. the Cargo team stuff) or completely wrong.

Also, if you think Go is a replacement of C, I think you are not a real systems programmer. Go has a GC, in the first place: how can you seriously state it’s a replacement of C? Also, you didn’t mention it (voluntary I guess), but Rust does have a community-based mechanism to make the language evolve (RFCs).

About the number of features, those are mostly non-breaking changes additions. Rust has editions now. Just… do your homework?

C++ is mostly used as a OOPL. Rust has no concept of OOP.

> 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.

Sorry For Your Loss.

Re: Rust is not a good C replacement

#154

Post by Thaxll »

wyldfire wrote: post #114
Thaxll wrote: post #103

Earlier quoted context omitted.

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 th…

> 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

Re: Rust is not a good C replacement

#155

Post by wglb »

fxfan wrote: post #21

If OP thinks Firefox is one of the largest C++ codebases in the world then OP has a very limited worldview.

The telephone switching system ESS 5 has 100 million lines of code.

Many enterprises, particularly software-focused ones, are likely to have 30 million lines of code or more.

Re: Rust is not a good C replacement

#156

Post by mjw1007 »

skybrian wrote: post #67
joshdover wrote: post #17

Most of the author's points here derive from the fact that C has been around for nearly 50 years and Rust a mere 8. This post should really be titled "Rust is not a good C replacement _right now_". Yes, Rust still has a long way to go to be the right tool for all the things you can do with C today, but that doesn't make it less. It clearly has benefits when writing concurrent and safe code. You pay for this with a le…

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.

The Rust team adopted a rule in December 2016 saying that all new language features must be documented in the language reference before landing on the stable release branch:

https://github.com/rust-lang/rfcs/blob/master/text/1636-docu...

As far as I can tell after adopting the rule they didn't proceed to enforce it.

Re: Rust is not a good C replacement

#157

Post by steveklabnik »

mjw1007 wrote: post #156
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.

The Rust team adopted a rule in December 2016 saying that all new language features must be documented in the language reference before landing on the stable release branch: https://github.com/rust-lang/rfcs/blob/master/text/1636-docu... As far as I can tell after adopting the rule they didn't proceed to enforce it.

It's more complex than that. From a development standpoint, doing it this way was a real pain. This is due to the reference being in a different repo than the change itself.

We decided to relax this rule last year, and so instead, issues need to be filed. They then get filled in after. This has its own set of drawbacks.

Re: Rust is not a good C replacement

#158

Post by chessturk »

mjw1007 wrote: post #151
chessturk wrote: post #128

Earlier quoted context omitted.

I'm curious if you consider Nim or Golang to be a small language that is a "better C". If not, why?

I don't think they count as a "better C" for this purpose. I'm thinking of something aiming at the niche that C currently fills. Having a garbage collector doesn't fit that, and Nim doesn't look small (anything with both destructors and exceptions is getting into complications rather beyond C).

Makes sense to me, thanks for answering.

Re: Rust is not a good C replacement

#159

Post by perennialmind »

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…

I don't know why back-to-back SSL proxies were never afforded an officially sanctioned mechanism for explicitly delegating trust. The alternative is this "I know you're lying, but I love you too much to leave you" mentality.

If you're asking package managers to facilitate such a morally compromised relationship, your best bet is to make user intent explicit and circumscribed. One way to signal that intent might be to adopt a trust-on-first-use approach:

  > rustup --detect-mitm
  MITM thumbprint: 567d3e4c...
  > rustup --permit-mitm=567d3e4c...
Not that that would be easy to do, mind you.

Re: Rust is not a good C replacement

#160

Post by detaro »

Sir_Cmpwn wrote: post #28
steveklabnik wrote: post #13

Earlier quoted context omitted.

I would suggest not taking comments on random github threads as the position of a completely different project.

I'm offering you an olive branch here. You can pile on the snark, or you can take my offer to issue a correction to my article. Edit: found the hostility. Fine, I won't issue a correction. I didn't find Steve's arguments entirely correct and I was willing to add a note to the page letting him share his perspective so the reader could make up their mind. Now I'm less open to that.

> Edit: found the hostility

Share for those following along at home?

Post reply on HN