The problem is that you need some support from the language to make it easy to deal with.

Nonsense.

if (result.isSuccess()) {
    do_something(result.value);
}
else {
   handle_error(result error);
}

The maintainer is a human that needs to eat every day, and not just whenever their services are needed.

That's perfectly fine.

But the maintainer is indeed explicitly making his work available to the public for free and without any expectation of retribution of any kind, isn't it?

And this isn't exactly something new or recent or novel, right? That's been going on for many years.

What changed? Did anything changed at all, even?

It’s not that they made a big report. It’s that they, a multi-billion dollar company,

Why do you think this is even relevant? Again, does your attitude towards a run of the mill ticket change if you change who filed it? Why are you outraged because some random grunt from company A or B filed an issue instead of random joe X? Would you be commenting here if the very same person who filed the issue had done so with a personal account without identifying or disclosing their employer?

It’s that they do nothing for the project but expect the world from it.

I'm sorry, where does ffmpeg demand contributions or retributions from anyone who downloads or distributes their project? Aren't they explicitly distributing their work without asking anyone to do or give anything in return? I mean, isn't that the whole point of FLOSS?

More surprisingly, we see guides on how to contribute to FLOSS projects which state in no uncertain terms that filing bug reports and even run exploratory tests to give feedback to maintainers counts as contributing to the project, but somehow you've flipped over even the core principles to make it sound like a cash grab.

It sounds like you’ve never had to do real work in a language kind C++ where the compiler is always trying to play gotcha with undefined behavior.

I have over a decade of professional experience working with C++, and it's likely you already used software I worked on.

Throughout those years, the total number of times where undefined behavior posed a problem in any of the projects I worked on was zero.

Please enlighten me about the insurmountable challenges posed by undefined behavior.

How do you succinctly call a language that has all behavior defined or equivalently no undefined behavior (aside from designated regions)?

I don't understand this fixation with undefined behavior. Its origins are in the design decision of leaving the door open for implementations to employ whatever optimization techniques they see fit without the specification get in the way. This is hardly a problem.

In practical terms, developers are mindful to not rely on those traits because as far as specifications go they have unpredictable implications, but even so they are never a problem. I mean, even in C and C++ it's trivial to tweak the compiler to flag undefined behavior as warnings/errors.

Sometimes it sounds like detractors just parrot undefined behavior as some kind of gotcha in ways I'm not even sure they fully understand.

What problem do you think that undefined behavior poses?

Should have still used them. It was harder to read this way.

The blog author is literally using de-facto standard for placeholder names.

• https://en.wikipedia.org/wiki/Foobar
• https://www.techopedia.com/definition/27996/frobnicate

The var names used by the author are perfectly fine. They don't cause any issue, nor do they make things hard to read.