If you use simple code, and the STL, C++ is very easy to write correct memory safe code, threadsafe code, portable clean code.

Lock-Free, Concurrent code, doing fork-join parallelism memory safe, trivial in C++.

C++ gets better over time, your C code can become C++, can slowly migrate to later standards by deleting code. This example over the years has seen me discard threads(c++11), wrappers(c++20), smart pointers(C++11) the core of this is unchanged from C++98, but the undifferentiated heavy lifting just keeps leaving my code for the standard library, and I'm very happy with that.

If you use std::array over plain array, from GCC 12+ onwards, you get free SIMD.

Please show me this in rust and tell me where my opportunities for performance, clarity, portability, memory or thread safety are being neglected and how the Rust code improves on this.

https://godbolt.org/z/PsMr1xdfd

Your argument is that a good programmer can write memory-safe code in C++. In theory, you are correct. In practice, there is many years of evidence of memory safety bugs being found in C++ code. And lots of programmers are not good.

So large programs written in C++ are highly likely to have memory safety bugs. For applications where those bugs are security vulnerabilities, that is not acceptable. The other advantages of C++ are irrelevant if it's impossible to write secure code.

Any Rust code that does not use the "unsafe" keyword is memory safe. This is enforced by the language and compiler.

There has been talk of having a memory-safe subset of C++, and making the compiler enforce it. Right now, that does not exist. There is some early development work on how C++ could be extended to allow that. If/when it does exist, then existing libraries will need to be ported to it or wrapped in bindings. It's basically a new language based on C++, with all the work needed to establish a new language - which Rust has already spent years on, so Rust has a big head start.

Rust is not a serious competitor for C++. It will never compete in that space - ever. It will take margin away from Golang and Python then fall-back into single digits of interest.

It's not 1980 - you are a thin front-end to a C++ universe, LLVM is written in C++ - so your advantage has corroded before we hit code generation.

There is nothing that Rust offers over valgrind / asan / ubsan - so essentially you're pretending that a language which lacks any credible examples has an advantage due to checks which are ultimately implemented in a C++ codebase.

LLVM's entire purpose was to allow people to write custom syntax checks for C++ code as it was more difficult to use the GCC tooling - It's not magic, if you can detected it from the AST then you can warn or even fix it automatically.

So Rust is not offering anything new, it does offer a great deal of friction and a lot of security issues - It's a tire fire of dependencies, the code is not readable to many people compared to the community of C and C++ literate people. The Compilers are single source, and the people pushing it are utterly untrustworthy.

So mate, not convinced - C and C++ have known issues, which testing, design, architecture and proficiency render trivial, in return we get clarity, performance, portability, multiple compilers, easy onboarding, continuity of source, an entire global population of developers with decades of experience.

Rust is fairly new. We don't have the many decades of experience & training with Rust that we have with C++.

But that argument is basically "we should never do anything new. We should never try new approaches to fix the issues with our current approach".

When cars came out, we didn't have the centuries of experience with them that we had with horses. There was a big community of people who could use horses but not cars. People understood horses but not cars. The supply chain for the first cars probably included horse drawn wagons. There were a limited number of car suppliers compared to lots of horse breeders and sellers. But ultimately, the advantages of cars meant that, over a period of many years, all that changed.

But there have also been many other attempts at major changes that haven't worked out.

It's too soon to know if Rust will succeed or not. Maybe in 50 years a few enthusiasts will be going "remember Rust, shame that didn't take off". Or maybe people will use Rust and look at C/C++ as legacy languages like Fortran and COBOL.

The argument is that Rust is different in meaningless ways offering nothing new. Reflection in C++26 is new, but functional languages are not new. There is no new idea as yet articulated other than "don't use C++ or C" which is not a new idea.

It's not an advancement to use a different programming language, it's either an aid or an impediement to the task, but to ditch the C++ ecosystem requires you provide something compelling, Rust doesn't offer it.

It offers advocacy absent evidence, it's grounded in idealism not measurable advantage. Find a Unicode conversion library in rust which has a sane API and allow you to determine what proportion of the input was successfully converted - https://thephd.dev/the-c-c++-rust-string-text-encoding-api-landscape

Ultimately ICU written in C++ is the winner. So being in Language X conveys no advantage over experts in the domain doing decent design, which is not new.

> if you can detected it from the AST then you can

But what if you can't detect it from the AST (passing pointers, type casting, mmap a file and type-cast memory to a structure)? How about if Rust prohibits the things that can't be represented from the AST, ensuring that you can detect the things that you can do?

There's been lots of back-and-forth, and potential fixes for C++ to obtain more guaranteed behavior. The rust-cult still exists, and the C++ crowd is still telling us that it *can* be done if we _really want to_ (with standards proposed but not yet, at least, popular). Neither has won the war.

The bottom line is that stuff is useful, which is why people do it. It's like saying you want to take the sharp knives from my kitchen and make me cook with a spork.

Sure it might be "safer" but I'm not convinced it's an actual problem compared to say input validation for sql injection or supply chain poisoning which rust makes much easier.

This is enforced by the language and compiler.

Assuming that there are no bugs in the compiler and underlying runtime system.

Correct. But let's be fair here: that risk is not specific to Rust. Bugs in the C compiler or C standard library can have the same effect. And they have caused security issues in the past.

https://godbolt.org/z/PsMr1xdfd

As a C++ programmer for 30 years and a Rust programmer for 4 years, I find it way more difficult to review for correctness your simple bit of code than the equivalent in Rust. There's the advantage, even if you're one of the very few who can write sound C++ every time .

I'd argue you're incompetent if you can't review that example comfortably in under ten minutes for the most pedantic review possible.

It computes a dot product, it uses the STL.

How on earth are we expected to take your opinion seriously if that level of complexity is considered to difficult to review for a thirty year veteran.

Why not bite the bullet and do a libc6-rs?

I don't see the niche for Rust. I either want higher level so a scripting language with a decent repl like ruby, or I care about the lifetime of my systems and being stuck on a single source llvm-frontend is troubling.

Nobody has answered the matter of "Fully Countering Trusting Trust through Diverse Double-Compiling" https://arxiv.org/abs/1004.5534

It's based on saying C has an issue which is addressed with destructors and scoped resource management, either in extensions or pre-processing, or with language support in C++. Therefore Rust, no linkage is offered, just a conclusion.

I don't see why a functional language with horrid syntax and glacial compilation is offered as some advancement over modern C++ or even modern C with the standard extensions.

It seems that Rust appeals to a more axiom focused developer who feels the grubby business of computation is rather beneath them, and would rather something else handle it.

C and C++ are for software that has to last, and be upgraded for a decent length of time, perhaps longer than one's internship rewriting decades old tooling might afford.

"It seems that Rust appeals to a more axiom focused developer who feels the grubby business of computation is rather beneath them, and would rather something else handle it."

Rust might appeal to companies who think they can shorten or even skip some bits of the software development process because Rust will take care of stuff they used to have to manage with reviews, testing and, you know, good SW engineers. I can imagine some of the people I've worked for coming back from a conference jolly all fired up with "this new language that's going to take 20% off our development costs because you can't write bad code with it" speeches.

I agree, there is a literal quote from the last time this came up,

Because Rust guarantees that you'll do it without introducing undefined behavior, even if you don't fully understand it, which carries a side effect of making it much easier to learn. The compiler also tells you exactly why what you're doing is wrong and even suggests how you might fix it. This may be hard for you to believe, but you literally can not screw this up if you're using Rust. Really. The language honestly delivers on what it promises.

But it compiled how can it be buggy as fuck.

> "this new language that's going to take 20% off our development costs because [it] [will take care of stuff they used to have to manage with reviews, testing and, you know, good SW engineers.]"

Wasn't this basically the argument for all the scripted, and even type-free languages? Python? Ruby on Rails? PHP? at least / to start with. Even, "Semantic Code."

Then maintaining and using them becomes nightmare-ish, unless you're a True Believer. They're relegated to small projects, because they're not suited for large applications. See also, Microsoft designing Typescript; Python's developer acknowledging that type-free languages are great for getting things done -- but not so great in large applications where you need to interact with other people's creations (in the same language).

'sudo' is a symlink to sudo-rs, so the former sudo with said vulnerabilities is not used - not even by accident or on purpose.

Why complicate matters with a symlink? Just call the sudo-rs executable "sudo".

This is how the situation is dealt with everywhere else . . .

Not sure the blinkered focus on 'memory safety' is worth the rest of the compromises of this current obsession with Rust.

Your inability to design, implement and test adequately to produce robust code to eliminate a subset of non-inherent issues is not a solid justification, any more than your inability to ride a bike would be reason to force training wheels on everyone.

And I especially hate it when people try to mandate their current favorite solution as the One True Answer rather than properly defining the problem and leaving it open how to reduce it.

It's not like Rust is exactly perfectly robust (or even viable) in all scenarios either.

and that this will destroy the GNU-GPL-Linux concept, please be aware that the GNU crowd crowd are FREE (as in FREEDOM) to fork and re-license this code as GPL whenever they want.

Meanwhile, one is NOT FREE to fork GPL code and re-license as something else.

Therefore, if the GNU crowd is worried about rs-sudo, or toybox, or uutils being in certain linux distros, better get forking, re-licensing and mantaining...

My toughts, licenses are just tools, there are right tools for the right job. The only ones who have a say on the license of a project are the people/entities who start said projects. If you do not like the license either fork and re-license (if possible) or re-implement.

The best example is Toybox. Busybox was created as GPL. One of the original implementers of Busybox tought a BSD type license woud be more amenable for the main use case of busybox (embeded systems) so they re-implemented from scratch with a permissive licence. No language change, no nothing.

BASIC, COBOL*, RPG-II, PASCAL and C** (not bad for an electronics engineer)

Got decent enoogh in C to become a teacher's assistant.

Languages are tools, there is not a "true tool". One should do an excersice:

If Mr. Torvads were starting the Linux Kernel today ¿would he use rust? ¿Zig? ¿C? ¿Erlang?

IMHO, rustifying the Kernel Loadable Modules (drivers) and userland is not that bad.

* The big advantage of COBOL in that era was that, if you showed your program to a non-techie (say, an accountant or a lawyer), the language was verbose and close to natural english enough, that the person could understand it enough to validate that the business processes/logic/rules and legal issues were correctly represented. They could not write it themselves from scratch, they could not maintain it, the could not detect sublte errors, but understand enough to give you the A-OK that the relevant lawer/accounting things were done correctly.

** ¿Does AWK and shell scripting count as languages?

Now there's a command you want to experiment with.

"Sudo is a command-line utility on Unix-like systems that allows authorized users to run commands with elevated privileges, typically as root" without the safeguard of an additional password. It fails Saltzer and Schroeder's separation of privilege criterion: https://en.wikipedia.org/wiki/Saltzer_and_Schroeder's_design_principles