This is a snatching-victory-from-the-jaws-of-defeat story.
I've been very skeptical of Rust as a vehicle for general application development and have said so here. The language exacts a cost, in terms of the slope of its learning curve and because it asks the user to be a lot more involved in memory management/safety than GC-based languages. Is it worth it for applications where a brief gc pause wouldn't matter, given the GC-based alternatives?
Another concern I’ve had about Rust is that the documentation was not good enough. But the situation is improving. I think the combination of the two "Books" is a whole that is greater than the sum of its parts and Jim Blandy's book is very well done. The document situation still is not up to the standards set by C (in K&R and Harbison and Steele), Haskell (the Report and the late, much lamented Paul Hudak's "Gentle" introduction), Tcl (Ousterhout’s book), Scheme (RnRs and the documentation for an extremely good implementation, Chez Scheme), and by the Go project (the languages are roughly similar in age, but Go is a much simpler language than Rust and thus easier to document).
I have reached the point of throwing in the towel with Rust multiple times, just utterly frustrated when I've gotten myself into lifetime hell or other situations with hard-to-decipher compiler complaints to which my reaction was “why am I doing this to myself?”. The reasons I didn't move on were that I liked the rigorous nature of the language and I was helped by smart, knowledgeable people like Vitaly and HadrienG, who taught me things about Rust that I just couldn't tease from the documentation or compiler error messages. The result was that I finally have a subset of the language that works for me and that I've used to successfully re-write a suite of (gtk3- and sqlite-based) personal financial management tools that I wrote in C 6 years ago. I've now written almost 7400 lines of working Rust, the Rust code being more concise and far more readable than the C. The make/build/install setup is also much cleaner, with many fewer moving parts.
While the C version, after years of use and bug-fixing (and Valgrinding) is quite stable, I have the luxury of knowing (modulo bugs in the Rust system) that the Rust version is correct by construction, at least with respect to memory- and thread-safety. Performance is comparable to the C version (Sqlite has always been the bottleneck in the parts of the system that exhibit long-ish runtimes and the re-write in Rust has not changed that).
Could I have used Go for this? Absolutely. I'd almost certainly have gotten it done sooner, and it wouldn’t have aged me nearly as much 
But Go is so uninteresting.
Haskell, of which I've written a lot, is a fine language, was an influence on Rust, and is supported by a great compiler. But Cabal is absolutely awful and now an attempt to undo a bad decision from the past regarding library loading in the interpreter has created such a mess that Haskell is basically unusable with Arch, the Linux distribution I use. This brings up another important consideration when choosing a language (beyond the language’s capabilities, its learning curve, its documentation and the performance of the generated code): the quality of the tools. This is an area where I think Rust is outstanding.
I won’t discuss the other possibilities (e.g., Nim, Scheme, OCaml), all of which were rejected for various reasons.
My main point, then, is this: if Rust is a suitable language for what you are doing but you are having difficulty learning it
a, Join the crowd
b, After doing as much of your homework as you can, talk to this community. There are people here who are fully capable of helping you and they are willing to do so.
If you resist the temptation to quit (as I almost didn’t) and reach the steady-state where you have made peace with the Rust compiler (all errors and warnings repaired), you will be rewarded by excellent performance, clean code, correct memory management, thread-safety, no include file hell, good build/install tools, good libraries, and more efficient development than C, because errors that are common in C can't happen in Rust, and other errors that can cause run-time trouble in C will be caught at compile time. You will do relatively little run-time debugging and that will be to untangle algorithmic or logical errors.