ttf-parser VS cv

Or even ttf-parser, which is usually even faster than C alternatives, no unsafe, no explicit SIMD.

Loader -> ttf-parser

Most of the code is in ttf-parser which is ~10KLOC.

Rust can absolutely be used without unsafe to create some of the fastest code out there, but you need to try and use data-oriented design where possible to make things flow smoothly and avoid runtime checks. The hardest thing to use data-oriented design for, in my opinion, is graphs. I find that actor systems can be used instead of graphs, but it is difficult. Generally I end up using slotmap to make multiple arenas and then putting them into one large object with lots of methods to operate on the graph structure. If you want an example of that, this is probably the most complicated code I have made this way: https://github.com/rust-cv/cv/blob/511024feaa077a9af377cca7b654ad3d57d3bd6a/cv-sfm/src/lib.rs. It may not be entirely helpful to understand the whole codebase, but if you are curious to see how I do graphs in Rust with slotmap, this can be a good reference.

This is a nice guide, but ultimately openCV should be rewritten in rust. It would avoid all of these headaches. Please checkout and support https://github.com/rust-cv/cv

It is, more or less, my first larger rust project. It uses the opencv crate, but I only recommend to have a look at rust-cv instead! It uses SQLite/sqlx for storing the matchings, actix-web for serving the webview and a lot of rayon for parallel processing.

You may want to take a look at our project Rust CV https://github.com/rust-cv/cv.