Hey guys!
Yesterday night/today I finished my first larger project in Rust which has been on the top of my 'to-do-stack if I have a quiet minute after work' for quite a while now - now that I have my Christmas vacation, I was able to finish it in a sprint
It is an asset exchange based on tokio-0.1. I had this idea already almost two years ago when I started getting into the language a bit deeper and I got quite some help on the Gitter channel on design patterns. Since async/await is now stable I can port this code to the new code base but, you know, gotta finish something portable first.
I would love to get some feedback on the structure and design decisions I had to make at a few points. Due to not understanding error handling in tokio at all at the beginning, I restarted that projects two or three times I think. I'm fully aware of some compromises I had to take here and there but I think overall the performance should be quite good. As I can't spend nearly as much time with this language as I would love to it took me quite some time to move forward to but that also implies that I think I switch design patterns here and there a bit. If you see something or have some comments, I would very much like to hear them!
I also have a few more concrete questions with regards to design. While src/exchange.rs is that one large piece of 'infrastructure glue' that I should port to async/await first (which will resolve some 'non-niceties' by itself then), I would like to hear some opinions on src/orderbook.rs and src/order.rs. I chose an enum rather than a trait to work with several types of orders (as the absolute number of implementations will be small (5-10 at max? There are only so many order types that are interesting) and I primarily need access to the fields rather than general functionality. But that leads to more verbose code and more repetition of code. I initially had one generic oder structure that carried a 'marker enum' which would carry potentially additional infos such as the stop price (trigger_price now as the term 'stop price' is not generic enough) and I would evaluate that type in one large heap. That makes the PartialOrd implementation at one point even for simple orders quite complex and slow. The earlier commits still had that structure, not functioning correctly as I wanted to solve the exchange routing first.
But maybe I'm a bit wrong with the choice that I did and, independent of the concrete project, someone else had a similar structure to work with and can share some experiences?
