I wouldn't 100% bet on this, but I wonder if Reddit will be the needle that pierces the AI/ML/LLM hype bubble. It could become a perfect demonstration that fundamentally the results produced by these models can only be as good as the data they were trained on. Garbage in, garbage out, but more realistically if you feed them large volumes of mediocre data unsupervised then you'll get a mediocre answerbot in return. See also all the coding bots that can generate plausible code from a prompt: if you review that code the same way you would review code written by a human, it's often full of problems that juniors might have but seniors probably wouldn't.

People who are writing or drawing or coding just by mixing and matching material copied from online sources and phoning it in probably should be worried, because they probably are about to be automated out of a job. However I doubt people with the knowledge, skill and creativity to be significantly better than average will have much to fear from this kind of ML "competitor" for a long time. And that makes all these sky high valuations for companies that are driven by the current AI hype look very bubbly.

Rust will help to make your own code safer and more predictable. It obviously can't help with code someone else wrote in a different language. The benefit to using Rust is the former and it's still there regardless of the latter. I don't know how much clearer I can say this, and to be honest, I've been replying in good faith but at this point I think you're just trolling so I'll be leaving the discussion now.

Yes, you are. Obviously if you depend on code written by other people then you are trusting that their code is good and if it isn't then you might have a problem. This doesn't seem a particularly novel or interesting argument if we're discussing how to make sure your code is as good as possible and avoid your mistakes becoming serious problems in production.

That is far too general a statement. In some situations, C++ may be slightly faster if Rust is performing extra checks at runtime. In other situations, Rust may be slightly faster because its model means it doesn't need to allow for complications that C++ does.

Either way, the difference is unlikely to be significant in practice. Rust and C++ are in the same performance class and both will be significantly faster than many other popular languages that have relatively high overheads for their runtime engines and dynamic behaviours.

Exactly. Also, this isn't a zero sum game where someone or something has to "lose" so someone or something else can "win". Realistically, C++ is going to be around for a very long time and it still has compelling advantages for some types of work, so we might as well invest our efforts in promoting a modern, safer style of C++ for those use cases. There's no need to pretend it's a perfect language with no historical baggage and there's no need to put down other languages that might be better choices now for other types of work. There's also no need to defend or preserve C++ indefinitely. If and when the other choices become strictly better options, it's perfectly OK to let C++ retire to the big legacy code repo in the sky after its many years of valuable service to our industry.

Rust is stricter about certain potentially dangerous behaviours than C++. If you have to make great contortions to do something in Rust, that is often a sign that what you wanted to do wasn't really safe and probably you should design your system some other way instead. As with many other automated checks, there is a problem that sometimes you might want to do something you're sure really is safe but the checker doesn't know enough to verify that and rejects it, and that's annoying. But as with many other automated checks, overall it's a clear win.

Rust has several different ways to interoperate with Qt if that's what you need to do. Just look at the language bindings Wiki page.

I think you're having your own conversation over there, my friend. Everyone else is talking about language features that are safer by design. You seem to be talking about people failing to understand elementary programming ideas.

The point isn't that anyone would deliberately construct a loop that iterates out of bounds. The point is that our industry has a very long and ignominious history of people writing loops with off-by-one errors and sometimes those errors have turned into serious failures of the systems that code belonged to. It is a fact that sometimes programmers do make those mistakes. It follows that alternative ways to express the intended behaviour that aren't vulnerable to those types of mistakes will be safer in this respect and will avoid some bugs that would otherwise have happened.

Also, the performance argument is shaky at best. For one thing, some of the better abstractions have essentially zero cost. They don't need extra runtime bounds checks or similar overheads because they are already correct by construction. For another thing, even in formulations that do behave as if there are runtime bounds checks before every iteration, modern code analysis techniques will recognise some patterns where the bounds can't be violated, so often compilers can elide those checks in the code they actually generate anyway.

The irony of this debate is that the people who think everyone should write perfect code and only bad developers make mistakes very often turn out to be the developers with the worst track records of making mistakes. Hubris is a dangerous thing.

Meanwhile the good developers are over there, getting their code reviewed by their peers and writing test suites and adopting languages with safer designs, so that when they do make the mistake, as they know they inevitably will sooner or later, it will probably get caught by one of the safety nets and not end up as a problem in production.

Everyone makes mistakes, no matter how good they are. Adopting defensive practices and tools that have designed out certain failure modes produces better outcomes, in software development as in many other fields. The evidence for this is overwhelming and arguing that we shouldn't need to compensate for human failings because developers should be perfect and not make mistakes in the first place is not a credible position.

But in this case it looks like the senior government people are on the right side of the debate. It's the "engineers" defending demonstrably risky languages like C++ who are trying to promote their own preferences as being safe enough despite all evidence to the contrary.

Professionals in fields like flying recognise that no-one is perfect and operate defensively to mitigate the risk. That's why we have checklists and copilots and why everyone in the cockpit shuts up at certain critical times except for very specific commentary. It's also why a lot of time and money is spent on designing very clear, very efficient controls and displays for cockpits.

It's bizarre that anyone would still argue even the best C++ programmer in the world won't pick the wrong type of smart pointer and end up with an ownership bug some time. Plenty of good programmers used to have null pointer dereferencing bugs, too, but for some reason we don't get so many of those in languages that don't have null pointers.

There is an important difference between a language where you can write safe code and a language where you can't write dangerous code. Some people in the C++ community seem to be wilfully ignorant of this distinction.

There is also an important difference between a practical language with escape hatches where the use of those escape hatches can be easily audited and one where it can't. If you can audit your entire codebase for potentially unsafe code and ensure any such code is carefully reviewed when it can't be avoided then that is very much better than having millions of lines of code where something unsafe could just be lurking anywhere. Again some in the C++ community seem to deliberately ignore this distinction.

Some people stay at good places for a few years each. That's great for gaining valuable experience and developing good judgement, but it's lousy for building a large professional network. And all of those pros and cons are amplified for roles at smaller companies.

Ah, yes. The 25-year-old cofounders, fresh from their PhDs, with some seed funding but no real industry experience. I've met a few of those over the years, too. Their ideas about how to run a successful business are often... different... aren't they?