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).

> 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.

https://news.ycombinator.com/item?id=32117148

https://news.ycombinator.com/item?id=39641552

These threads are absolutely painful to read. The Rust community/leadership would not do anything about it because Rust thrives on such "devotion".

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.

[1] - some more Hinton's "wisdom": https://www.reddit.com/r/singularity/comments/1c2vauy/geoffr...

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.

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.

Fil-C uses fat pointers to retain bounds and type information to make existing C code safe (typical C is filled with pointer arithmetic and casts).

Languages like C++/Zig/D have bounds checked slices and containers (or at least have facilities to create them). So fat pointers are not necessary. Slice types can also fit into 128-bit (start+end pointers), so they can be atomic.

I wonder what a modern language would look like if it had manual memory management exclusively through isoheaps. Fil-C[1] attempts to retrofit isoheaps to C.

Now one can argue that isoheaps still allow access to wrong value and that this can potentially cause security issues. But the same also happens with indices or object pools in GCd languages. And if we go by this logic then Rust is less safe than Java (even without unsafe) because Rust requires indices to express what can be expressed with just references in Java.

Increasingly, I find it hard to justify systems like the borrow checker that force the programmers to contort their programs in a certain way. Unfortunately, a lot of newer languages (eg., Hylo, Austral, Circle) are experimenting with something similar to the borrow checker. Take Hylo for instance. The language has no reference type at all. So one has to use indices everywhere. Why not just embrace isoheaps instead?

[1] - https://github.com/pizlonator/llvm-project-deluge/blob/delug...

[1] - https://github.com/pizlonator/llvm-project-deluge/blob/delug...