3 ms·
Even Torvalds seems open to Rust. I think the whole world is paying attention. There's inertia, and some people don't think Rust is ready, but it seems like m
by eternityforest 4y ago
Even Torvalds seems open to Rust. I think the whole world is paying attention.
There's inertia, and some people don't think Rust is ready, but it seems like more and more people want to see that C++ gets replaced.
Most of the arguments I see for C are ecosystem or legacy related, purely based on a preference for simplicity or an assumption that it's always better, or not technical at all("Real programmers" feeling insulted by languages that try to hold your hand, or preferring the challenge of C).
- ncmncm 4y agoRust has everything Torvalds said he hated about C++. The more he learns about Rust, the less open he will be to it. It is deeply weird that you would pivot to "arguments ... for C". There are no legitimate arguments for C. C++ usage is still growing by leaps and bounds; more people pick up C++ for professional use each week than the total now employed coding Rust. The realistic place for attention to improve security is, first and foremost, displacing C; what you transition to matters much less. It is much easier to transition to C++ than to Rust, and modern C++ eliminates temptation to unsafe coding because unsafe code is just more work for no benefit. You can switch just about any C project to build with a C++ compiler in a day or two. Then you can modernize incrementally, starting with new code, and updating key subsystems according to what yields most benefit for new code. This is not theory: it was done in Gcc and Gdb with imperceptible disruption and massive benefits.
- the_biot 4y ago> There are no legitimate arguments for C. Bullshit. You're not helping your argument by denying the counter-argument's right to exist. > more people pick up C++ for professional use each week than the total now employed coding Rust. Do you have any facts to back up this thing you just pulled out of your ass? > You can switch just about any C project to build with a C++ compiler in a day or two. Then you can modernize incrementally, starting with new code, and updating key subsystems according to what yields most benefit for new code. That's if you want to do that; not everybody wants to switch to C++. I know you won't understand. A wise man once told me, if you tell a group of programmers you're going to do a project in C++, half of them will just quietly acquiesce, and the other half will spontaneously vomit. You cannot underestimate how much C++ is despised.
- ehvatum 4y ago> A wise man once told me Sounds legit.
- ncmncm 4y agoWe all know some are irrationally, rabidly hostile to C++. The most hostile know least about it. But we need not try to accommodate them. Millions of working programmers use C++ successfully every day. Those using modern idioms have no greater trouble with memory safety than in other "memory-safe" languages. The unfortunate subset who treat it as "better C" for fear of learning anything new are nearing retirement. A good example of sensible use of modern C++ in kernel and essential utility code may be seen in the SerenityOS project.
- eternityforest 4y agoI was specifically listing not-quite-rational arguments for C. The main real argument for it I can think of is that... sometimes it is currently the only reasonable choice. But C++ is so much different than C. Not even a strict superset. Either way people will probably be pissed off and it will require work to get the benefits. So why not go for Rust? C++ has no borrow checker. You can hack stuff on, but how much work can you really do before it's just not worth it and you might as well use Rust? Of course scratch rewrites are a pretty horrific thing, but are we really going to just stay with C++ forever?
- ncmncm 4y agoLegitimate questions. Certainly, the overwhelming majority of existing portable-ish software in whatever language will not be rewritten. It won't be as bad as code written in the '60s, running on an emulator on an emulator... five deep, which does exist! But they will be recompiled and carried along until they become irrelevant. Code to operate pagers and fax machines is largely retired already. C coders will always have a job maintaining the legacy stuff, just as people make good money patching COBOL. C++ has no borrow checker. That turns out not to matter so much as some people insist. It mainly just means that people writing libraries need to step up to do, in the library, what the Rust compiler does. But faster. Users of those libraries get the safety Rust advocates claim as all their own. But C++ also enables library writers to do many, many things Rust simply cannot be made to do, resulting in wholly more capable libraries, and much that it will never do. We will not "stay with C++ forever". We will stay with C++17 until we get C++20 support, and with C++20 until we get C++23 support, etc. The language is changing fast to meet needs its users face, with a depth that no other language is even trying to match. Someday a language may arise that can grow to match C++. It once looked like Rust might have developed to be that.
- eternityforest 4y agoRust is Turing complete. There's nothing a Rust library can't do, there are only ways in which rust cannot do things. I think the whole point of rust is to not do things in ways that the computer can't prove are correct. But like any language, it gives you other ways to do those things. It's almost like stack overflow's habit of telling people to do something else instead of what they asked, but enforced by the compiler so your manager can't make you do it the "simple and interesting but unsafe way". There are a lot more libraries in the world than language writers, and there are bugs in libraries. Plus, you often have to malloc and free and all that even if you are using libraries for everything. Mistakes happen, CVEs happen, and the world loses trust in software a little more every time.