Ask HN: Rust or Go for building an order execution engine in crypto?
2 comments
I have built lots of super performant systems in C & C++ but not for crypto specifically. Almost every time I ran tests to see if we could use something more productive, I absolutely love C/C++ but I recognize there are safer and more productive (subjective) languages and tooling for a team as a whole many times.
So I'd actually side with your productivity thought on this, but would want to validate it some. If the difference in performance is a few ms 95% of the time and that is good enough given volume then I'd go with the most productive tooling. Another point, if your team knows Go and not Rust, I'd immediately just use Go first, you can always optimize if really needed later. When you try to learn a language while trying to build a detailed product that has a lot of performance requirements it is super hard to do it correctly the first time in.
That said, if the difference is a few ms but you are running millions of transactions a day then those ms do matter in terms of infrastructure costs, so you'll have to balance that thought. Most likely if this is the first time you guys are building the order executor you'll likely have need to touch it (from an architecture point) again in the next 6-12 months so I'd just use the most productive tooling first and learn what you need to and then implement it differently the next time (if needed).
So I'd actually side with your productivity thought on this, but would want to validate it some. If the difference in performance is a few ms 95% of the time and that is good enough given volume then I'd go with the most productive tooling. Another point, if your team knows Go and not Rust, I'd immediately just use Go first, you can always optimize if really needed later. When you try to learn a language while trying to build a detailed product that has a lot of performance requirements it is super hard to do it correctly the first time in.
That said, if the difference is a few ms but you are running millions of transactions a day then those ms do matter in terms of infrastructure costs, so you'll have to balance that thought. Most likely if this is the first time you guys are building the order executor you'll likely have need to touch it (from an architecture point) again in the next 6-12 months so I'd just use the most productive tooling first and learn what you need to and then implement it differently the next time (if needed).
I’m not a cryptocurrency enthusiast, so take this with a grain of salt, but there’s a lot of Rust in it. Like, some of the earliest non-Mozilla jobs were in cryptocurrency. Various companies sponsored our conferences. And of course, there’s Libra.
I know that Rust is slightly faster, but I assume that over the course of the next 5 years, the nano second will not matter while I also think that one is more productive in Go. What do you guys think?