Most (if not all) of your posts here on HN boil down to "C/C++ bad, Rust good". I wonder what you are trying to achieve by this, but I assure you that this does not do Rust any favor other than giving the impression that the Rust community is obnoxious.
I found their comment an interesting contribution to the discussion, pointing to a couple of specific pitfalls in C++. It's not just an empty "C/C++ bad, Rust good", and I don't see why it'd give the impression of an obnoxious community.
I just wrote that as an observation, and I did not mean to offend the parent.
Now, let me explain why I felt that way. First and foremost, the phrase "undefined behavior" only applies to C and C++ because the specifications of those languages define it. The statement that Rust has no UB does not make sense because Rust has no specification, and all behavior is defined by the default implementation.
For example, C/C++ specifications state that using a pointer after calling "free()" on it is UB. But an implementation can make it well-defined by adding a GC and making "free()" a no-op. Hence, memory safety is entirely orthogonal to UB.
Another example: signed overflow being UB is not a memory safety problem unless the value is used for array indexing. Also, it is possible to enable bounds checking in STL containers (like _GLIBCXX_ASSERTIONS).
It seems like that a lot of Rust fans read John Regehr's posts and use "undefined behavior" as a boogeyman to throw shade at C/C++. They repeat the same points ad nauseam. It also helps that the phrase "undefined behavior" evokes strong emotions (eg., "nasal demons"). I see the parent commenter doing this frequently and sometimes[1] even in the C++ subreddit (of all the places!). How is this not obnoxious?
Here[2] is another person doing the same, but in a spicier tone. Linked lists and graphs are safe if you have an isoheap allocator (look at Fil-C).
You can say that it is moral to endlessly reiterate the problems of unsafe languages, because it could lead to more secure software. But see the reply to my other comment by "hyperbrainer"[3] which says that Rust is "completely" memory safe, which is entirely wrong[4]. It is hard not to suspect the motives of those who claim to be concerned about memory safety.
[1] -https://old.reddit.com/r/cpp/comments/1fu0y6n/when_a_backgro...
[2] - https://news.ycombinator.com/item?id=32121622
[3] - I am unable to reply because of the depth.
[4] - Rust requires unsafe to do a lot of things which can be done in safe code in a GC'd language. Thus, unsafe is pretty common in Rust than most GC'd languages. If a segfault can literally kill a person, it is absolutely immoral to choose Rust over Java (it does not matter that Rust "feels" safer than Java).
I really am interested in what Safer C++ proposes for [1], but I never found out.
Your point [4] is very silly because you're assuming that while the unsafe code implementing a safe Rust interface might be flawed the code implementing a safe Java interface such as its garbage collector (which will often be C++) cannot be. As we'd expect, both these components are occasionally defective, having been made by error prone humans, such flaws are neither impossible nor common in either system. There are indeed even safer choices, and I've recommended them - but they're not Garbage Collected.
> First and foremost, the phrase "undefined behavior" only applies to C and C++ because the specifications of those languages define it.
Nope, those words have an ordinary meaning and are indeed used by Rust's own documentation, for example the Rustonomicon says at one point early on, "No matter what, Safe Rust can't cause Undefined Behavior". The purpose there is definitional, it's not a boast about how awesome Rust is, it's a claim that if there is Undefined Behaviour that's not because of the safe Rust, there's a soundness problem somewhere else.
> Another example: signed overflow being UB is not a memory safety problem unless the value is used for array indexing
This is wrong. Because Signed Overflow is UB the C++ compiler is allowed to just assume it will never happen, regardless of the systemic consequences. What that means is that other IR transformations will always be legal even if they wouldn't have been legal for any possible result of the overflow. This can and does destroy memory safety. Actually it would be weird if somehow the IR transformations always preserved memory safety, something they know nothing about, despite changing what the code does.
> The statement that Rust has no UB does not make sense because Rust has no specification
I don't think it was claimed that Rust has no UB in this conversation, only IFNDR.
From what I can tell, Rust does document a set of "behavior considered undefined" like using unsafe to access misaligned pointers. For practical concerns ("could code optimization change these semantics?", "is this guaranteed to work the same on future compiler versions?") it seems reasonable to me to call that undefined behavior, and to say that Rust doesn't have much of it.
> I see the parent commenter doing this frequently and sometimes[1] even in the C++ subreddit (of all the places!). How is this not obnoxious?
Both their comment here and their reddit comment look fine to me. Something like "C++ sucks, switch to Rust!" would be annoying, but specific relevant technical comparisons ("In Rust for comparison the static growable array V isn't dropped when the main thread exits [...]") seem constructive.
> Rust requires unsafe to do a lot of things which can be done in safe code in a GC'd language. Thus, unsafe is pretty common in Rust than most GC'd languages. If a segfault can literally kill a person, it is absolutely immoral to choose Rust over Java (it does not matter that Rust "feels" safer than Java).
Java does technically have the Unsafe class for low-level unsafe operation and JNI to interoperate with C/C++/assembly.
I'd expect that the average Rust program makes more use of unsafe, but largely just because the average Rust program is lower-level (including, increasingly, parts of the Linux and Windows kernels). It's unclear to me whether the same program written in Java or Rust would ultimately prevent more bugs.
> Now, let me explain why I felt that way. First and foremost, the phrase "undefined behavior" only applies to C and C++ because the specifications of those languages define it. The statement that Rust has no UB does not make sense because Rust has no specification, and all behavior is defined by the default implementation.
There are at least three classes of definedness of behavior:
1. The behavior of a program is defined by a spec.
2. The behavior of a program is not formally defined by a spec, either because the language has no spec or because it's imprecise, but it's defined in a sociological sense: that is, if a compiler doesn't follow the apparent meaning of the program, the people who develop the compiler will consider it a bug and you can report it to mailing lists or GitHub and probably get support.
3. The behavior is definitely undefined: a compiler can do anything in response to the program and the developers of the compiler will not consider it a bug.
C++ has a lot of 1, comparatively not a lot of 2, and a lot of 3.
Rust has none of 1, a lot of 2, and a lot of 3. But safe Rust has very little of 3.
> Most (if not all) of your posts here on HN boil down to "C/C++ bad, Rust good".
I haven't measured but it's easy to say categorically that it's not "all" unless somehow my posts about network protocols, aeroplanes, security and psychology among others fall into this vague category.
And yes, like Ignaz Semmelweis I can see an obvious improvement to how my profession does what it does and it's infuriating that the response from many other practitioners is "No, I don't like change, therefore you're crazy for explaining why I should change"
Ignaz Semmelweis died in an asylum. But on the other hand while Ignaz was correct and his proposals would have worked he couldn't explain why because germ theory was only confirmed after he died. Rust isn't in that situation, we know already exactly what the problems are with C++. So that means I can tell you not just that using C++ is a bad idea, but why it's a bad idea.
Most HN users already use languages with GC which are more memory safe than Rust. People still use C++ either because they are maintaining existing code, or they work in domains where memory safety is not really necessary (games, HFT, ML). Apart from these, C++ is rarely used in the real world.
> practitioners is "No, I don't like change, therefore you're crazy for explaining why I should change"
Who exactly are you referring to here? Your co-workers? LLVM maintainers? or the Linux kernel developers? Please be more precise.
Only safe Rust can guarantee this, and only as a consequence of any unsafe Rust being correct.
Most of the popular Garbage Collected languages of course also have a way to escape, in some cases via an "unsafe" keyword or magic unsafe package to a language where the same safety rules do not exist, in this sense the difference in Rust is that it's the same language.
I'd actually say the more memory safe option would be a language like WUFFS where it pays a high price (generality) to deliver categorically better safety and performance. Most software could not be written in WUFFS but also most of the software which could be written in WUFFS isn't.
AI is probably the only field in science where even scientists behind the thing talk like salesmen. Hinton in particular comes off as a dishonest person: he clearly knows what he says is wrong but does it anyway because he wants to hype the technology [1].
Also, the whole "neural networks work like human brains" nonsense is beneficial to large corporations behind AI because it could help them defy copyright laws while the same restrictions continue to apply to the common man.
The thing is, these problems rarely arise for programmers who daily code in C++. People who don't use C++ love to enumerate different C++ gotchas. In reality, most C++ projects define a coding style that dodges most of these problems. For instance, I don't use default arguments at all.
That said, I don't start new projects in C++ mainly because of the header/source split. After writing a lot of code in languages that don't require a header file, I believe that C/C++ not making headers files redundant in 90s itself has been a costly mistake. Think of the time wasted because of constantly having to sync header/source files. One can argue that it does not take much time but it is hard to estimate how many bugs might be introduced because of such busywork breaking mental flow.
Oddly, real problems like these are never brought in these "C++ sucks" discussions.
Oh yeah, the header thing drives me insane as well. People put up with the stupidest shit. I try to structure my code to only ever include actual .c files, so that there's no need for .h files. (Learned to do this writing "raw" php in the past... I guess I put up with that because it was my income). Doesn't scale past a certain point sadly.
Could you explain what Fedora does better than the Debian-family of distros? I find Fedora's overall performance to be worse than other distros (including Ubuntu).
Way less terminal commands. Basically 0, although I was impressed at how easy it was to open the firewall for my kids minecraft server on linux vs Windows.
Things just work out of the box.
I don't mean using a GUI to download stuff. Everything you need is already there.
> "but we don't know how often it happens!"-bollocks
I am not sure why you describe that as bollocks. The most surprising part of the xz backdoor is that it was discovered by sheer luck. Imagine what would've happened if the backdoor hadn't caused a noticeable slowdown. It is not a stretch to imagine that there might be other backdoors in OSS that are not (yet) found.
