The API is based on C with structs including function pointers are getting sent to each plugin so targeting Rust should hopefully be fairly straightforward. Once that is done I plan to implement the Amiga UAE backend using Rust as a test to see how everything works out.
This is also the next step for me to write some larger code in Rust.
And if that turns out well I will likely start rewriting the whole thing in Rust (currently mostly C++)
Nothing too impressive, but just made and am working out the kinks in a binding crate to espeak's library.
Very usable, except I'm having trouble getting TextToPhonemes in particular to work, I guess something to do with the double pointers.
I hope someday to make a safe, high-level crate upon it to help Rust users painlessly integrate text-to-speech into their programs.
Preparing for (and should be recording) New Rustacean e003. I plan to tackle enums and the basics of pattern matching, and then to use that as a way to talk about returning from functions which might fail or have non-data results (so: Option and Result). Should be out either over the weekend or early on Monday.
Pumpkin! It's a prime number generator library intended to be used in other cryptographic programs where large primes are needed (such as RSA). It's not quite done yet, but I should be pushing something up to crates.io tonight or tomorrow.
Awesome to see another scener taking the leap I've been working on porting all of my emulator stuff to Rust, as well as the SNES tracker I've been talking about for ages. Would love to hear more about your experience as well!
I've definitely had the same experience. I still do when it comes to arrays/slices etc and ofc general lack of familiarity with the standard lib, but the rest of the language has definitely started to click for me. I think it's probably harder for C/C++ guys to learn because we have to understand what everything does before we trust the system actually is safe. "Unlearning fear" is a term I heard in a talk the other day, and I think it's super true
You could let the user make some kind of template where they can specify things that belongs in the readme, but not in the docs. Something like this:
{{title}}
Badge1, badge2, etc.
{{description}}
# Contributing
This is how you can contribute to this project.
It's not really that relevant to the API, so it's
not necessarily something you would include it in
the docs, unless you want to.
This would allow the user to exclude irrelevant things from the docs.