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