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

61–70 of 213 posts

Re: Rust is not a good C replacement

#61

Post by Sharlin »

JoeAltmaier wrote: post #32
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…

Its not unreasonable to expect Rust to have looked at history, and improved upon it. To start out less than C means what? We don't want to wait 50 years for another language to 'mature'. Why can't it start out as good as, or even a step ahead of what came before? That may be the source of the disappointment surrounding deployment of Rust - why is it behind and not ahead of other tools?

That doesn't make any sense. What do you mean "less than C"? Rust definitely looked at history and improved upon it, that's the whole point of the language! The author's gripe was that they feel Rust is evolving quickly much beyond C (like C++), not that it's trying to catch up on C. And do you really expect a language to just appear one day, fully grown, like Venus from a seashell?

Re: Rust is not a good C replacement

#62

Post by mjw1007 »

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 does for all I know).

Re: Rust is not a good C replacement

#63

Post by steveklabnik »

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.

Re: Rust is not a good C replacement

#64

Post by ddevault »

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…

>This is a function of popularity and time.

Correct, both of which you have to take into account when picking a programming language today.

>We have to take the good with the bad in everything, right? If Rust's future is "spectacular failure like C++" then it's probably going to be a wild success.

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.

Re: Rust is not a good C replacement

#66

Post by z3phyr »

bitwize wrote: post #43

Of course C programmers are going to think Rust is a poor C replacement. Rust wasn't made for C programmers -- it was made for their replacements.

Zig is a better replacement for C and Rust. C programmers no this, but Rust programmers can't comprehend simplicity. They won't know

Re: Rust is not a good C replacement

#67

Post by skybrian »

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.

Re: Rust is not a good C replacement

#68

Post by Sir_Cmpwn »

bhaak wrote: post #30

The main fallacy of this blog post is that he wants it to be one single programming language that replaces C. C has actually been already replaced mostly. C++, Java, C#, Python, Ruby, Go, Rust, etc. have been chipping away for more than 20 years now at C's market share. What kind of project can you seriously start today in C because there are no better options available? My guess is embedded programming and kernel pr…

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 supplanting C for many problems. It does this by specializing on certain classes of programs and addressing them with the simplest solution possible. It hasn’t completely replaced C, but it has made a substantial dent in its problem space - more than I can really say for Rust (which has made similar strides for C++, but definitely not for C).

Re: Rust is not a good C replacement

#69

Post by solarkraft »

bhaak wrote: post #30

The main fallacy of this blog post is that he wants it to be one single programming language that replaces C. C has actually been already replaced mostly. C++, Java, C#, Python, Ruby, Go, Rust, etc. have been chipping away for more than 20 years now at C's market share. What kind of project can you seriously start today in C because there are no better options available? My guess is embedded programming and kernel pr…

> But nowadays it already feels outdated on arrival

Why? What do you prefer?

Re: Rust is not a good C replacement

#70

Post by joshdover »

JoeAltmaier wrote: post #32
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…

Its not unreasonable to expect Rust to have looked at history, and improved upon it. To start out less than C means what? We don't want to wait 50 years for another language to 'mature'. Why can't it start out as good as, or even a step ahead of what came before? That may be the source of the disappointment surrounding deployment of Rust - why is it behind and not ahead of other tools?

The author's opinion of Rust being less is that, an opinion. It does have large advantages over C: memory safety, an incredibly powerful type system, a compiler that supports detailed error messages, a powerful build tool (Cargo), an expressive macro system, etc.

Others who have built applications with Rust seem to be coming away with a much different impression that the author. He does mention some gaps (lack of a spec, unstable ABI) but these are not hardstops for all usecases. The main thread of complaints appear to be from lack of choice of tooling and compilers.

I'd wager that the advantages outweigh the drawbacks for many projects, though not all.

Post reply on HN