FWIW, those four links are already purple for me.

The reason it's difficult is that it simultaneously introduces the concepts of optionals, unwrapping, string processing, variable assignment, and lifetime management. It's not like it's impossible to figure out. I was only saying the workload was similar to "baby's first vi session".

That's understandable, but isn't it premature to judge Rust based on such a session?

That would be like criticizing vi based on "baby's first vi session", because "couldn't even exit the editor!".

I... am not sure. On one hand, it's instructive for language designers to know what turns out to be a barrier to entry. They're often unexpected things. And what's worse, users usually run into them and then quietly disappear; you almost never get the chance to see what trips newbies up in practice. It wasn't meant as a solid criticism, but more of a cathartic "yes, this language can be really counterintuitive at times." (Rust is in good company. It's the same reason Lisp is unpopular.)

On the other hand, you're absolutely right: the hypothesis is, given two equally-experienced programmers, one of them a Rust aficionado and the other a LuaJIT maniac, the LuaJIT dev will deliver reliable and maintainable software with an order of magnitude less effort. So you're right, that remains to be seen (to put it mildly).

Looking forward to seeing how close I can get to XSV's performance. It's a great benchmark.