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.
Rust is not a good C replacement
31–40 of 213 posts
Re: Rust is not a good C replacement
#32Most 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?
Re: Rust is not a good C replacement
#33I agree with the overall conclusion. Zig is aiming at being a C replacement. Rust is very much more in the C++ space. But a lot of the individual points seem off the mark.
> Concurrency is generally a bad thing. A program which uses poll effectively is going to be simpler, reasonably performant, and have orders of magnitude fewer bugs.
One of the benefits of Rust is that provides a lot of checks on concurrent code to prevent you doing stupid things, so you get the benefits without these costs. It's not perfect, but I've personally had zero issues with concurrent code in Rust. This is actually a benefit Rust provides even over other memory safe languages like Java.
> C has a spec.
Yes, C has a spec. But a ridiculous number of things (in a modern context) are left as undefined behaviour in that spec, meaning that it is very easy to accidentally violate the spec. Rust doesn't have a spec yet, but it has far more safeguards which make it much easier to avoid weird unexpected behaviours in practice. A full spec will come eventually.
Re: Rust is not a good C replacement
#34I'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 rustup.
The implementation was critiqued in a very civil way. The author fixed the issues. Everything was ready to merge and... in walk some busybodies who under the pretense of caring about security (having no clue about the issue or modern Windows workplaces, and despite clear refutations of their concerns) have seemingly been able to kill this patch: https://github.com/rust-lang/rustup.rs/pull/1624/
"We need to discuss this with experts". I don't know where, I briefly searched for any such discussion. I guess there was none.
So a drive-by shooting killed a very useful feature. The saboteurs can revel in the knowledge that they drove away a new contributor (I haben't seen any more activity on that GitHub issue). And users suffer.
Thanks a lot! Sabotaging corporate users must feel very good.
Re: Rust is not a good C replacement
#35OK 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.
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).
Re: Rust is not a good C replacement
#36If OP thinks Firefox is one of the largest C++ codebases in the world then OP has a very limited worldview.
That's true though, as far as the open source projects go.
Only bigger C++ open source codebase I can think of is LLVM. What else did you have in mind?
Re: Rust is not a good C replacement
#37This just reads like the author was told to rewrite his code in rust one too many times, and he felt compelled to justify his own choices by bashing rust. Just say you like the simplicity and subtle bugs of C more than having to deal with the upfront complexity of low-level code at all times
Re: Rust is not a good C replacement
#38> 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…
Look at the languages made by ex C programmers. Zig is a good candidate.
Re: Rust is not a good C replacement
#39> 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.
Re: Rust is not a good C replacement
#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 worth
Binding to "editions" is a reasonable way to get stability, IMO. It's a shame that this wasn't adopted earlier.
> Concurrency is generally a bad thing.
So don't leverage it. Don't use fork() or clone() either and we'll all agree to ignore this point.
> 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.
Here underlies the crux, you should have led with this. This is a sizable portion of rust's value proposition. If you don't value it then it's likely not to measure up well.
> Rust will eventually fail to the “jack of all trades, master of none” problem that C++ has.
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.