Safer in what sense? We have no idea whether this hypothetical code is in a userspace application that can exit safely at any time or a hard real time system where panicking could destroy hardware.
A lot of important programs (like the Linux kernel) don't operate strictly on the exact letter of the standard's UB semantics. They do things like add compiler flags to specify certain behaviors, or assume implementation details.
I will never understand how C developers can catastrophize over Rust panics, a language that has a panicless "_try" version of every panic causing function that returns a Result instead, while simultaneously accepting the infinite growth of ever harder to avoid UB in C/C++ and telling people to never have undefined behavior in their code.
If you think dealing with undefined behavior is easy and you assume that people have verified that their software triggers no undefined behavior at runtime is fair game, then you should grant that assumption in favor of Rust developers having done the same with their panics, because avoiding panics is child's play in comparison to avoiding UB.
I don't know what it is about panics that triggers some mania in people. UB does not interrupt the program and therefore allows memory corrupt and complete takeover of a program and the entire system as a consequence. C developers are like "this is fine", while sitting in a house that is burning down.
There used to be a pretty blatant hibernation bug with AMD GPUs on Linux that essentially crashes your desktop session upon turning your computer on from hibernation. I've also had a wifi driver segfault on login that forcibly logged you out so you couldn't login like 9 years ago. C doesn't magically fix these problems by not having an explicit concept of panics. You still need to write software that is correct and doesn't crash before you push an update.
There is no meaningful difference between a correctness bug and a panic triggering condition with the exception that the panic forces you to acknowledge the error during development, meaning it is more likely that the correctness bug gets caught in the first place.
Can we refrain from strawmen? I haven't made any of the points you're harpooning and vehemently disagree with all of them.
What I said was that panics aren't always appropriate and the context to determine this doesn't exist at the language level.
I didn't say managing UB was easy and in fact I've argued diagnosing it is impossible directly with members of both language committees. I didn't say panics are never appropriate. They usually are appropriate. I didn't say I don't use rust because X, Y, Z. I write rust. Etc.
There is no meaningful difference between a correctness bug and a panic triggering condition with the exception that the panic forces you to acknowledge the error during development, meaning it is more likely that the correctness bug gets caught in the first place.
More likely, but not guaranteed. I don't want to engage more with you, but there was a specific incident I was thinking of when I wrote the prior post that involved an assert improperly placed in a real time control loop that burnt out a very expensive motor.
We removed 30% of UB in the core language already for C2y and are in progress of removing more, so there is no "infinite growth of ever hard to avoid UB". For many UB the right way is indeed to panic and in C you can often achieve this with the UB sanitizer (but not for all).
I find with C/++ I have to compile to find warnings and errors, while with Rust I get more information automatically due to the modern type and linking systems. As a result I compile Rust significantly less times which is a massive speed increase.
Rusts tooling is hands down better than C/++ which aids to a more streamlined and efficient development experience
Not the GP, but the biggest one is dependency management. Cargo is just extremely good.
As for the language tooling itself, static and runtime analyzers in C and C++ (and these are table stakes at this point) do not come close to the level of accuracy of the Rust compiler. If you care about writing unsafe code, Miri is orders of magnitude better at detecting UB than any runtime analyzer I've seen for C and C++.
Strictly speaking, Cargo isn't part of the Rust programming language itself. Cargo is a layer on top of Rust, and you can use the Rust compiler completely independently of Cargo. I think bazel, for example, can compile and handle dependencies without Cargo.
Its the mindset of neckbeards who don't realize its not the 1990’s anymore, that the landscape has changed significantly and people cannot protect themselves let alone their children from it.
Implementation obviously matters and it is indeed a delicate situation, but that does not negate the need for solutions.
Love it when you make a statement that porn isnt harmful without referencing any studies, and then demand studies for people to prove it is harmful.
You are the one who made the original claim that its not harmful, the burden of proof is on you.
Their side isn't the one trying to ban things. If you want to ban something you have to prove it's harmful. If you don't want to ban something you just have to call out that the other side has to prove it's harmful before they can ban it. It's like how you don't have to prove your innocence against a criminal conviction, merely provoke reasonable doubt (in theory).
Like with any new wave of technology, the masses try to ride the wave, however they can - either creating a spinoff company that will ultimately go bust, or spamming hn with blog posts about their experiences.
It’s yet another hype cycle, and exhibits very similar traits as the dotcom bubble.
Want funding? Just use a .ai domain.
CEOs are talking about AGI or super-intelligence, but this is all hype driven nonsense to try to convince people that their stock evaluations are justified.
Whats particularly dangerous about this hype cycle is that the technologists try to convince us that humans are now replaceable with said technology, this teaches people to be lazy, promotes brain rot and ultimately leverages the situation even more.
Embedded developer here, I focus on audio hardware and robotics. Although C/++ is still dominate Rust is becoming more and more popular. I now specialise in embedded Rust, with a fallback to C/++. C++ is fine, but I prefer the modern language feats, safety guarantees, toolchains, package management etc of Rust.
Although I am younger than you, I feel somewhat similar. The never ending treadmill of technology seemingly makes things worse rather than better. I’m working in robotics, and I think is this actually the right thing to be doing? - but if I dont, then I wont eat and afford my future.
Really feels like society is burning the candle at both ends.
Maybe if your devs are building React components for ecommerce websites. But if they are building automotive or flight control software - good luck with that!
