You’ve never met an average ASP.NET developer?

OP is right. For web development with JavaScript frameworks (React, Angular, etc) with Node and even Typescript, you either use vscode or you haven't discovered vscode yet.

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 feel like this will have zero protection against

Zero protections against what? Against the programmer telling the program to do something it shouldn't? Not programming language does that. If you resort to this sort of convoluted reasoning, the same hypothetical programmer can also swallow all exceptions.

The main problem you're creating for yourself is that you've been given an open-ended problem but instead prefer to not look for solutions.

That’s not even the issue. Nobody cares that MS is using ffmpeg.

You surely haven't been paying attention to this thread.

It’s just rude to have as much money as MS does (...)

Seriously? Is this the argument you're going with?

Unbelievable.

special treatment for free

They filed a bug report, with a reproducible bug.

Some guides on how to contribute to FLOSS projects even go as far as listing this as one of the main ways to contribute to projects.

But here you are, describing a run-of-the-mill bug report, filed among hundreds of bug reports, in a ticketing system explicitly opened to the public so that everyone and anyone in the world could file bug reports, as a request for "special treatment for free".

Do you think every single person filing a bug report is asking to be given special treatment for free? Everyone's bug is very important to them too. What makes you think this case is special or even any different?

See, you’re not claiming that processes are important, you’re claiming that your process is important and

No, I'm claiming that processes are important.

It's important that stumbling upon a tangentially related bug or even linting issue does not block your work, forces you to fork your work, nor forces you to work around it. It's important that you can just post a small commit, continue with your work, and only handle that in the very end.

It's also important that you can work on your feature branch as you please, iterate on tests and fixes as you see fit, and leave cleanup commits to the very end so that your PR contributes a clean commit history instead of reflecting your iterations.

It's important that you can do any work you feel is important without having to constrain yourself to adapt your work to what you absolutely have to push your changes in a squraky clean state without iterations.

It's important that you can work on tasks as well as cleanup commits, and not be forced to push them all in a single PR because you are incapable of editing your local commit history.

It's not about my workflow. It's about the happy path of a very mundane experience as a professional software developer, specially in a team which relies on a repository's commit history to audit changes and pinpoint regressions.

This is stuff anyone who works in professional teams can tell you right away. Yet, you talk about this if it was a completely alien concept to you. Why is that? Is everyone around you wrong and your limited superficial experience dictates the norm?

Yet you talk about autism.

Dangling pointers, double frees and the like, mostly.

Those are bugs you wrote in. UB is not the problem. Your code is the problem.

Tell me you haven’t run into those and I’ll laugh in your face and call you a liar.

I ran into bugs. Do you understand that UB is not the problem if you're pushing broken code? It's not the C++ standard that's messing up if you're writing in use-after-free bugs.

The irony of your comment is that some implementations take advantage of UB to prevent programs from crashing and actually continue to work in some scenarios such as use-after-free and even dereferencing null pointers. But that's not caused by UB, is it? Those problems are caused by developers like you and me who didn't knew what they were doing and even failed to either pay attention to the errors flagged by compiler and static code analysis tools, or even failed to onboard one.

I mean, think about it for a second. Let's say we have a magic wand that can update any C and C++ standard version of your choosing, and we specify that each and every single instance where behavior is left undefined is updated to specify that the program should automatically crash. Awesome, no more UB. What does this mean for your code? Is it now bug-free? Is it now working well after crashing all the time due to the code you added? What role did UB played in this mess?

Do you understand this?

I repeat: detractors just parrot undefined behavior as some kind of gotcha in ways I’m not even sure they fully understand.

I think you're succumbing to the belief that if a solution isn't perfect then it doesn't work. That's not how things work. You can have incremental improvements that replace a big problem with a smaller problem, and a smaller problem is easier to solve.

Also, StackOverflow already suffers from old and stale replies for years, and that's not hurting the site. Oddly enough, that's a problem that's mitigated with the way that data is queried,and that's handled quite well with large language models.

If it’s not constant at you may get the loop invariant movement. But only if the compiler can tell that it’s invariant.

The point is that if the predicate is evaluated at runtime then the compiler plays no role because there is no compile-time constant and all code paths are deemed possible.

I suppose what I should have said is more like “in many cases you won’t see any performance difference because the compiler will do that for you anyway.”

I understand that you're trying to say that compilers can leverage compile-time constants to infer if code paths are dead code or not.

That's just a corner case though. Your compiler has no say on what code paths are dead if you're evaluating a predicate from, say, the response of a HTTP request. It doesn't make sense to expect this hypothetical scenario to be realistic when you have no info on where a predicate is coming from.

I have two accounts,

The last post to !opensource@programming.dev was 6 days ago.

During the past week, the community received two posts. Only two.

In the past two weeks, it received 8 posts.

Again, if you care about content, all you need to do is post content. Please don't ruin everyone's experience by deploying spambots that add no value at all. Be smart about where to invest some effort.

You’re not making the strong case that you think you are. Quite the opposite. The ease of “shooting yourself in the foot” is precisely what makes it so difficult to learn. Segmentation faults and random memory corruption make it incredibly hard to get started with programming.

That's not the case, though. Some C and C++ compilers are already resilient and flexible enough to not get C and C++ to blow up in your face when you're doing unmentionable things to memory access. Some memory safety issues are only noticeable when running profilers and memory safety tools.

Keep in mind you are talking about someone taking their first steps in writing software. They are struggling to get stuff to work, and throwing curve balls at them is not going to help them get on their feet.

Also, I did not advocated for C or C++ as better options. My point is that Rust is an awful suggestion as a first language, which even the Rust community states. It also speaks volumes to Rust's unsuitability as a beginner programming language if the best attempt to refute that fact is to try to come up with worst alternatives that in the end aren't even worse at all.

Rust’s constraints are very clear and concise in comparison (...)

Irrelevant. The point is that Rust enforces constraints that other programming languages don't. If anyone is taking their first steps, not having to deal with them leads to a far more productive and enjoyable experience. It's absurd to talk about memory-safety and performance when the target audience doesn't even understand what memory is.

The article is not talking about async processing. It’s talking about the process scheduler and thread blocking.

No, not really.

The article doesn't even cover process scheduling at all. The whole point of the article, which is immediately obvious to anyone who ever worked on a GUI, is what code runs on event handlers and how doing too much in them has a noticeable detrimental impact on user experience (i.e., blocks the main thread).

It's also obvious to anyone who ever worked on a GUI that you free the main thread of these problems by refactoring the application to run some or all code in a problematic handler asynchronously.