I develop professionally in C and C++. No they aren’t. At all. C and C++ are so loaded with footguns it’s a surprise people can get anything done in them without triggering UB.

The way you parrot undefined behavior is a telltale sign you do not work with either C or C++. If you had any cursory first-hand professional experience with either one of those languages, you'd understand what UB is, why writing your code by laying unfounded expectations on UB is actually either a bug or design error on your behalf, you'd know that for a decade or so there are tooling that throws warnings and errors if you inadvertently use it, and above all UB only means frameworks are ultimately responsible to specify the behavior that is left purposely undefined.

I agree. Those who make bold claims like "AI is making programmers worse" neither has any first-hand experience with AI tools nor has any contact with how programmers are using them in their day-to-day business.

Let's think about this for a second: one feature of GitHub Copilot is the /explain command, which is used to put together a synthetic description of what a codebase does. Please someone tell me how a programmer gets worse at their job by having a tool that helps him understand any codebase anywhere.

You’d have had me ignore them all and keep using C for everything.

Please tell me which language other than C is widely adopted to develop firmware.

You're talking about so many up-and-comers during all these decades. Name one language other than C that ever came close to become a standard in firmware and embedded development.

Right.

There’s also alternatives with custom ci jobs within non GitHub/lab within the git universe that may help out with those sorts of operations.

Why would anyone subject themselves to explore nonstandard and improvised solutions to try to fit a usecase that fails to meet your needs to a tool that was not designed to support it?

Do people enjoy creating their own problems just to complain about them?

I use C++ all the time, undefined behavior is not something I encounter ever. I run undefined behavior sanitizer often.

From the looks of some of the posts showing up in this thread, I doubt the bulk of the commenters portraying UB as the root cause of any problem have any experience at all with C or C++. They are clearly resorting to unrealistic strawmen to pretend UB is something that it clearly is not. That just goes to show their technical background and the substance behind their claims. I really don't know how this helps advocating for Rust.

Each implementation that exhibits different behavior doubles the amount of testing needed to ensure cross-platform correctness.

Not really. The whole point of undefined behavior is that the standard intentionally leaves out any definition of behavior, or the program is already fundamentally broken.

If you insist on unwittingly using code that relies on undefined behavior, you're the one mindlessly writing broken code. It's not the standard's fault that you're adding bugs.

The irony is that compiler implementations also leverage undefined behavior to save you from yourself and prevent programs to crash when they stumble upon the mess you've done with the code.

I don’t believe you have to specify the condition at compile time. I think that optimization would fall under dead code elimination.

How do you tell if some code behind a conditional is dead if the predicate that drives the condition is evaluated at runtime?

This is very over-exaggerated. A lot of people started with C or C++ as their first language.

That took place over two decades ago. There were no better alternatives back then. Times have changed.

Both of which are significantly harder than learning Rust.

This is simply not true. It's far simpler and less frustrating to work on either C or C++ for the simple reason that you can shoot yourself in the foot anywhere you'd like. In Rust, newbies have to alternative to endure the compiler enforcing its safety constraints anywhere they'd like. Rust is also a far more complex and extensive language that enforces memory safety rules that can and very often are very frustrating to handle by those who don't have a firm grasp on them.

Also, it’s worth noting that cargo is a fairly good package manager all things considered.

Yes, I'm familiar with Cargo. My point was to point out the absurdity and silliness of OP's remarks on "no bulky management of a virtual environment, no make files, no maven, etc." Once Rust fundamentalista take off their rose-tinted glasses, it's clear that Cargo is just as good (or as bad) as any contemporary integrated build system.

This is a ridiculous definition of “real-time”. To accomplish this you’d need to subvert the kernal’s scheduler (...)

You missed the whole point of the article.

It makes no sense to read the article and arrive at the conclusion that "I need to subvert the Kernel's scheduler". The whole point of the real-time analogy is that handlers have a hard constraint on the time budget allocated to execute each handler. If your handler is within budget them it's perfectly reasonable to run on the UI thread. If your handler exceeds the budget then user experience starts to suffer, and you need to rework your implementation to run stuff async.

Keep in mind that each mouse click/hover/move/sneeze triggers a handler on GUI applications. Clicking on a button can trigger small, instant changes like updating UI, or can trigger expensive operations like running an expensive task. Some handlers start off as doing small UI updates but end up doing more and more stuff that ultimately start to become noticeable.

Maybe I’m dumb because I’m a backend dev, but if we can’t offload these tasks to Async tasks and we need to block the main thread, why can’t we just put up a loading screen?

That's not the problem. These tasks can be offloaded to async. The underlying issue, and the reason why I think this is an outstanding article, is that running code on the UI thread straight from handlers is easy and more often than not it goes perfectly unnoticed. Only when the execution time of those handlers grow do these blocking calls become an issue.

There's a gray area between "obviously we need to make these calls async" and "obviously we can run this on the main thread", and here's where the real-time mental model and techniques pay off.

“Don’t turn off the application we are saving” games have been doing this for a decade and you can’t convince me that your enterprise application is heavier than a AAA game.

You're missing the whole point.

The point is that running handlers in the main thread leads to far simpler code and, depending on the usecases, is adopted in scenarios where the approach works well with 99.9% of the conceivable usecases. But then the software starts to be modified and get features added, and some of these code paths start to do more things and take more time to run. When this happens, the 99.9% starts to shrink and some main thread blockages start to become more and more noticeable.

The article does a very good job in underlying the mental model that needs to be in place to avoid this slippery slope to become a problem.

You could just upvote Java 8 and Java 17