This really reads like someone who's never touched Rust outside of a 15-minute intro or something. The aversion to `unsafe` doesn't really make a whole lot of sense if your main focus is raw performance... that's why there's a big suite of unsafe operations that skip the safety checking steps.
> Although integer underflows and overflows are only checked in debug mode, memory accesses in arrays are constantly checked for bounds unless you’re in unsafe mode, which defeats the purpose.
Which purpose? The idea is that the majority of code that people write is in safe-land, and the bits of unsafe you use are up to you to verify that you've used it correctly. Using `unsafe` doesn't "defeat the purpose" of Rust, it tells Rust to trust that you've done something correctly.
> Well, yes, if you are going to list the “safety” of Rust compared to C++ as a pro...
"Pro" =/= "never makes mistakes". Memory safety is hard. Mistakes happen. C++ will happily crash at runtime while Rust will catch roughly 100% of mistakes in safe code at compile-time. Writing unsafe code yourself is certainly hard, but chances are that the Rust community has already done the hard part for you and made a crate featuring the data structure you're looking for. At that point, there's very few memory-related foot-guns primed for you to shoot yourself with.
> Again, pundits will state that you could have called one of the arithmetic wrapping functions, which will force the compiler to do this optimization. Well you can do many things but here we are measuring the effect of the compiler over two similar blocks of code.
"If you ignore the thing that lets the Rust code do the thing that you want it to, then the Rust code doesn't do the specific thing you want it to."
> C... was created with the use case of it being a low level language... C++ inherit that, which makes it arguably the easiest language to code memory-intensive algorithms and data structures like hash maps, btrees, vectors and lists.
nit: "C++ inherit_s_ that". Also, this just speaks as someone who hasn't been a junior in a very long time. The number of ways you can subtly fuck up memory access in C++ is astounding, so much so that people have spent hundreds of thousands of man-hours designing memory safe languages like... Rust...
> This means that a good developer who knows how to take advantage of cache/locality, will have a good time implementing such algorithms and data structure with C++ and will very likely struggle with Rust for the same task.
Define a "good developer" more specifically. A good Rust developer certainly knows how to handle unsafe code without shaking in their boots.
> Rust mandates the use of its own compiler - rustc - which is a top driver of the LLVM stack, pretty much as clang is for C++. C++ on the other hand, has dozens of good quality compilers available in many platforms.
C++ is a 38 year old language designed in a time when you'd be happy that you had a compiler at all, let alone one that worked properly. Having multiple compilers for a language isn't a necessarily good trait, it just means that more work was spent duplicating functionality. And despite that previous statement, Rust doesn't "mandate" you use any particular compiler; there are multiple projects actively targeting other backends like GCC and cranelift.
> Although the scenario is changing rapidly, the pool of engineers with C++ background is much larger than the pool of Rust developers
See "C++ is a 38 year old language"...
> But safety against what? In many years of coding C++, very rarely I experienced a stack overflow or segmentation fault. It is literally not an issue in every codebase I have worked with.
Are you... sure you're using C++ then? This statement comes across as both a humble-brag and also just patently false if you've done anything even remotely lower-level. Does the author mean to say that he's never before experienced memory mismanagement?
> Are we talking about safety against hackers?
No...? You can just read the second sentence on the Rust websi-
> Or are we talking about protection against crashes?
No seriously it's righ-
> a heavily protected, garbage collected language as C#
Garbage collection doesn't mean your code is sa-
> However segfaults can be caught with a signal trap and handled cleanly like any Java/C# exceptions
Whew, that's probably the worst claim yet. The author legitimately links to an article that mangles the call stack by performing arbitrary code execution during a SIGSEGV handler. And has the audacity to call that being "handled cleanly". Wow.