If you could reliably write memory safe code in C++, why do devs put memory safety issues intontheir code bases then?
That's a question you can ask to the guys promoting the adoption of languages marketed based on memory safety arguments. I mean, even Rust has a fair share of CVEs whose root cause is unsafe memory management.
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.
Git is no different. But it sure feels like it never took the idea of a polished user experience seriously.
I've seen this sort of opinion surface often,but it never comes with specific examples. This takes away from the credibility of any of these claims.
Can you provide a single example that you feel illustrates the roughest aspect of Git's user experience?
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.
I have experience contributing to a semi successful FLOSS project, one that I’m 100% certain you use daily.
I'm not talking about contributing. A drive-by PR does not make you a maintainer, nor gets you to triage bugs. The problems I mention are the bread and butter of maintainers engaged in community support, which you would know if you had any semblance of experience in the subject.
And the truth of the matter is that your choice to use weasel words as seaways to a rant to go off on a tangent demonstrates your complete lack of insight and experience in the subject.
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.
Where he gives plenty of examples of UB resulting in the compiler optimizing away safety and introducing security vulnerabilities silently.
That's the bit that those who parrot on abot UB get entirely wrong, and yet cling to it if it was something meaningful.
Let's make this absolutely clear: any code you write that triggers UB is a a bug you introduced. Your complains about UB boil down to blaming the language for bugs you created because you didn't knew what you were doing.
As you can configure compilers and static code analysis tools to flag UB as warnings or even errors, the discussion of using UB in your code is a discussion on incompetence. Complaining that a programming language purposely leaves out the specification of the behavior that broken code should have because you don't know what you're doing is the definition of a bad workman blaming his tools.
If you paid attention to the article you're quoting, you'd notice that even the author makes it quite clear that programs with UB only "appear to work". That boils down to the definition of UB, and the reason why every single developer in the world who had any intro to C or C++ experience knows quite well that UB means broken code. Why is it hard for you to understand this?
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.
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.