[TinkersW]

I think memory safety is fine, but I plan to do it in C++ not Rust-- nothing in this article is remotely new either, just repeating the same tired stuff.

It seems pretty clear statistical hardware level memory safety is coming(Apple has it, Intel/AMD have a document saying they are planning to add it), the safety zealots can turn that on, or you can use FilC if you need absolute memory safety, but really C++ with various hardening features turned on is already fairly solid.

Also I think that memory safety is generally less important than thread safety(because memory safety is rather easy to achieve and detect violations), which almost all those languages recommended by this article blow chunks at. Rust could actual make a solid argument here, instead of wasting time yammering about memory safety.

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