(...) rust, since js is much higher level. you should be comparing it with c, c++, zig, maybe nim, etc
Obvious troll.
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 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.
it’s about deploying multiple versions of software to development and production environments.
What do you think a package is used for? I mean, what do you think "delivery" in "continuous delivery" means, and what's it's relationship with the deployment stage?
Again, a cursory search for the topic would stop you from wasting time trying to reinvent the wheel.
https://wiki.debian.org/DebianAlternatives
Deviam packages support pre and post install scripts. You can also bundle a systemd service with your Deb packages. You can install multiple alternatives of the same package and have Debian switch between them seemlessly. All this is already available by default for over a decade.
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.
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.