I mean, yeah, if your language does not support error values, do not use them.
Nonsense. If adopting info of the many libraries already available is not for you, it's trivial to roll your own result type.
Even if that was somehow unexplainably not an option, even the laziest of developers can write a function to return a std::tuple or a std::pair and use structured binding.
Yeah, because the new tools are never actually better, right?
Well, yes. How many fads have come and went? How many next best things already died off? How many times have we seen the next best thing being replaced by the next best thing?
And yet, most of the world still runs on the same five languages: C, Java, C++, C#, JavaScript.
How do you explain that, with so many new tools being so much better than everything?
Might it be because fanboys tend to inflate their own definition of "actually better", while turning a blind eye to all the tradeoffs they need to pretend aren't there?
I think you're trying too hard to confuse yourself.
The report of the bug is not the problem.
People in this thread are arguing otherwise.
The prioritization, (...)
Users filing tickets do not prioritize jack shit. That's not how it works. At best they mention an issue is important to them. Not even in big corporations dealing with internal tickets things work like that. The responsibility of prioritizing work lies on the project owners, exclusively.
and demand that it be fixed quickly (...
Literally what each and every single user affected by a problem asks in their bug reports.
Again, why do you feel this is something that warrants your outrage?
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.
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.
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.
WET is not what you think it is, or at least not originally. It’s not some alternative to DRY. It didn’t stand for Write Everything Twice. It stands for Write Every Time. It’s supposed to be a negative way to describe code that isn’t DRY. It’s also abbreviated as “Waste Everyone’s Time”.
I think you're confusing things. Write Everything Twice (WET) has no resemblance with the concept you mentioned, which makes no sense to be a standalone concept or even rule of thumb.
WET is a clear guideline to avoid usual code quality problems caused by premature specialization and tight coupling which result from DRY fundamentalisms. WET puts on hold the propencity to waste time with code churn. It's importance is clear to anyone who maintains software.
The misunderstanding since DRY’s coining is probably because, like natural language, we change meanings we with our environment.
Not really. Your comment sounds like a weak attempt at revisionism. Some reference books like Bob Martin's Clean Code explicitly cover DRY and the importance of refactoring away any duplicate code.
WET springs from this fundamentalist mindset. There is no two ways about it.
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.