[vlovich123]

Rust’s thread safety story is a subset of broader memory safety - it just guarantees that concurrent programs still are memory safe. This also happens to correspond to the most frequent sources of bugs in concurrent programs, but it’s not all there is to thread safety.

It’s talked about all the time but whenever people talk about memory safety, thread safety is implied. Statistical hardware memory safety is more a security feature. But knowing that your code is correct before you even try it is a huge productivity boost and valuable in and of itself for all sorts of reasons.

It’s weird the pushback from c++ people considering that Rust makes high performing code easier to achieve because of rules around aliasing and auto-optimizing struct layouts among other things. This is stuff c++ will never get.

[mk89]

Some days ago I took again a look at Rust.

I don't like the syntax at all, and coming from a Scala background that should say a lot. I will never like it, unless they simplify it.

However, they implemented at compile time all the rules that someone wrote in the CPP guidelines about memory, or in dozens of books about how to write safe code.

Now you can say: so you see, if you are good at c++, you achieve the same as Rust.

True. But I don't buy it. I don't believe that even hardcore c++ developers never make a memory related mistake. I have been in the industry for a while and shit does happen, even to the best of us, unless you have "guardrails" around, and even then, so many things can go wrong...

So a few days ago I asked on HN why not to use hardened allocators, which would basically block entirely the possibility to deploy such mistakes, a bit like OpenBSD allocator.

It seems 1) people who develop low level stuff don't even need the heap, or use anyways a limited subset of things, 2) such allocators slow down the runtime significantly.

So what I hear is:

1) I know what I am doing, I don't need a compiler to tell me that.

2) I anyway need a subset of that, so ... who cares.

3) runtime tooling helps me.

Except for 2 (like writing something for Arduino or by using some very specific subsets of C/C++), everything else sounds pretty much hypocrite to me, and the proof is that even the top of the top of the engineers have to fix double free or things like that.

If C++ broke the ABI and decided tomorrow to adopt memory safety at compile time, you would see that most people would use it. However, this holy war against Rust "because" is really antithetical of our industry which should be driven by educated people that use the right tool for the right job. As I said, ok for very low level/subsets, but why would you start today a CLI tool in C/C++ (if not for some very specific reasons )?

For me this has more with fear of learning/doing something new. It makes no sense otherwise to reject a language that guarantees that a random developer missed the lifetime of that object etc... A language that is only improving, not dying anytime soon, with one of the fastest growing ecosystem, not "one person's weekend project" or things like that.

As I mentioned multiple times, I dislike particularly Rust syntax. I love the C syntax the most, although C++ has deviated from that significantly with templates etc. But if something is better suited, sorry, we need to use it. If the C/C++ committee are the slowest things on the planet, why should my company/software pay for that? Everyone said python would die after the backward incompatible 2->3 upgrade. Sure.

[vlovich123]

I have found Rust syntax a breath of fresh air as compared with C/C++ and I was doing c/C++ for over 15 years before I started with Rust. No arbitrary semicolons, everything is an expression leading to more concise code, no need to worry about the interior layout and excess padding of a struct, function declarations that are trivial to read, magical inference all over the place, variable shadowing that’s actually safe, etc etc. traits that let you duck type behavior in a 0 overhead way elegantly. A proper macro system. No weird language rules about having to know the informal rule of 0/5 or failing to manage resources or code that fails to manage resources in an exceptional safe way.

It’s alien and unfamiliar, but I actually don’t have problems with the syntax itself. Swift has the “everything is an expression” property. Python’s list comprehension felt weird and confusing the first time I encountered it. Typescript (&Go) has traits after a fashion. In fact Go syntax I find particularly ugly even though it’s “simpler”

[winterlights]

Efficiently implementing a doubly linked list in C or C++ is easy. In Rust, less so.[0]

And the prevalence and difficulty of unsafe means both that Rust is not memory safe [1], and that Rust sometimes is less memory safe than C or C++.

[0]: https://rust-unofficial.github.io/too-many-lists/

[1]: For an example of memory unsafety in Rust: https://materialize.com/blog/rust-concurrency-bug-unbounded-...

[steveklabnik]

You can write a linked list in Rust the same was as C or C++ with unsafe, so it as least as easy.

[vlovich123]

While I think it’s a troll account, it is technically true that the rules around unsafe Rust are a little harder to get exactly right to avoid UB because you still have to uphold the much larger surface area of rules in safe Rust without any of the compiler help. C++ by contrast of course has fewer such rules and they’re easier to reason about but of course there’s no compiler warning when you violate them.

On the other hand that line of argument is kind of weak sauce because the vast majority of bugs aren’t in complicated recursive data structures. And you can always implement doubly-linked list in pure safe rust just with slightly more overhead by using Rc/Arc if you wanted guarantees (and you can also verify the unsafe implementation using Miri which is a significantly strong runtime checker than c++ where you only have ASAN/UBSAN)

[ravenical]

Did you actually create this account just to hate on Rust?