Can you explain what you mean, about unsafe friendliness in the standard library?

I believe this is referring to the interop abi that is in planning.

It aims to expose a nicer way to glue rust idioms to similar or equivalent idioms in other languages.

https://github.com/rust-lang/rust/pull/105586

Not the poster of the comment but I'd like to hear from the downvoter why this was downvoted.

As a Rust novice, interpreting the comment GP made (from the perspective of, for example, C++ calling Safe Rust core or stdlib) this seems like a valid response.

Would the downvoter like to comment as to why I too got downvoted?

It's pretty strange. Rust is dismissed because interop with C++ is hard, but then Val is cheered on despite its C++ interop basically being a big "todo" item.

Author admits his own bias and preference at the end.

> I do need to confess: in my spare time, I have started working with the Val team

Indeed, I think this should have been made clear in the first section. I thought when the author said they have a bias it was more in the general sense, not that they are working on one of the languages in question.

Yes, misleading.

Also just saying a language's C++ interop is better simply because it's easier doesn't really pass the smell test for me. If I need to write some interop for a C++ library, I'm going to prefer one that's more reliable than one that's easy but can fail in weird ways. And unless my project is an interoperability library, I'm not sold on "harder = worse" when I'm most likely going to write the interop once, ever, and be done with it. If it takes me a day, but then I can rely on it to function well and fail in predictable ways, I'm still on board. There's nothing wrong with something being difficult if the result removes a ton of mental load.

I'm not a fan of this article's conclusions at all.

Not to mention efficiency. Sure, it's 'easier' to make a copy of all the data when crossing the FFI boundary