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

91–100 of 213 posts

Re: Rust is not a good C replacement

#91

Post by timw4mail »

ddevault wrote: post #64
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.

A few niches? Every major GUI application and video game is niche?

Re: Rust is not a good C replacement

#92

Post by sseagull »

jabl wrote: post #39
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…

> 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 happen), this would be applied to the metric shit ton of existing code, making it better. Not perfect, but better.

Of course that work is dirty and necessarily political, and making a new language is sexy...

Re: Rust is not a good C replacement

#93

Post by adamnemecek »

sseagull wrote: post #84
adamnemecek wrote: post #35

Earlier quoted context omitted.

Also their development process is too slow. Like it would be impossible for me to pitch a new feature to cpp. I can imagine adding a new feature to rust (not that I would but I like that there’s the option).

But isn't this how you end up with a 'bloated' language? Everyone has their own corner case, own little way the language can be improved. Over time, these will inevitability burden a language. Adding features becomes necessarily bureaucratic as languages mature. You can't just add/change stuff without seeing how it interacts with everyone else, which gets difficult as languages grow and become popular.

That depends on how these features are added.

https://github.com/rust-lang/rust/blob/master/RELEASES.md

I would argue that cpp, despite being much older, is still adding features that are kinda backbreaking e.g. ranges.

Re: Rust is not a good C replacement

#94

Post by bluejekyll »

steveklabnik wrote: post #80
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…

Yes, there's a ton of ways that you can do this. Most successful integrations thus far have done exactly that: you have a target for your Rust code, it calls out to Cargo and does its thing, and then links it in. I believe that you're right that the Meson folks want to use rustc like they use cc, and use Meson for all of the stuff that's not "compile this, please." This can work well as long as you're writing all of…

Well, then the comment they made about essentially rewriting Cargo is probably accurate.

Doesn’t seem like it’s a valuable contribution to their end goal though.

I do want to point out (for others, you know this) that Cargo has a lot of environment variables that can be used to improve its usage inside other build systems, e.g. using a shared target directory for reusing compilation of dependencies: https://doc.rust-lang.org/cargo/reference/environment-variab...

Re: Rust is not a good C replacement

#95

Post by rhn_mk1 »

StreamBright wrote: post #31

Totally agree with his observations but I disagree with the conclusion. C is a ok programming language. The first language that realises that simplicity above all is the most important feature of any language and uses the same safety measures like Rust is going to win over a huge user base.

Low level programming in a safe way is a complicated endaevor. The assembly language with a few instructions can be the ultimately simple language, but it doesn't offer the same features that Rust does.

While I am all for simplicity, I just don't think it's all that obvious that a language could possibly be simple, fast, and safe at the same time.

Re: Rust is not a good C replacement

#96

Post by Datenstrom »

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…

Absolutely, and some people _really_ care about these things. Especially in my domain where things are safety critical like avionics/robotics we absolutely do not want to segfault and fall out of the sky or have degraded capabilities. I have found a lot of interest in using Rust in this domain exactly because of the safety. Especially with the awesome work that RustBelt[1] has done.

Further a compiler that verifies memory safety for you can save an incredible amount of money when otherwise you would need to manually prove memory safety.

[1]: http://plv.mpi-sws.org/rustbelt/

Re: Rust is not a good C replacement

#98

Post by bhaak »

Sir_Cmpwn wrote: post #68
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 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 you dismiss this outright, you could have written a much shorter article or at least written a much more interesting article by starting with this admission and from that working your way through Rust's feature and explaining how this doesn't alleviate the warts of Rust.

> But now you know why we are still writing C

I wonder who this "we" is?

I'm also still writing C but for quite different reasons. Mostly because of legacy code and to some degree even just to be able to claim that I'm working on 35 year old code.

Re: Rust is not a good C replacement

#99

Post by calibas »

>Rust will eventually fail to the “jack of all trades, master of none” problem that C++ has.

He's talking about C++ like it's some kind of failure and not one of the most widely used languages in the world. Sounds like the author just doesn't like C++, so it's no surprise he doesn't like Rust either.

>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 don't really care" isn't a good reason for ignoring one of Rust's strongest points. If you're not an expert in C like the author, then this would be one of the biggest reasons for choosing Rust over C.

That being said, I agree than Rust isn't a good C replacement, mainly because it's more similar to C++.

Re: Rust is not a good C replacement

#100

Post by adrianN »

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…

There is already a metric shitton of work being poured into making C safer. Everybody realizes that most existing C code will be used for a long time. That's why we have a bunch of different sanitizers, fuzzers, static analyzers and so on. The problem is that these tools only find a fraction of the possible memory corruption bugs you have and many people don't even bother to use them. You can still find bugs in many open source projects with a simple fuzzer. Sanitizers are only as good as your testsuite, but except for SQLite, which project has extensive coverage?
Post reply on HN