<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 19, 2015 at 6:01 PM, xu xiut <span dir="ltr"><<a href="mailto:xiut.xu@gmail.com" target="_blank">xiut.xu@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">For those who were wondering what type of exchange I'm wanting to build, it's a bitcoin exchange with derivative contracts</blockquote></div><br>The key requirement to ask is: what will be your major worry when writing such an exchange? Different languages will make it either easy or hard to solve certain problems in your domain. So you need to pick a language which will put you in a position where you have the right strength and can ignore the weaknesses due to them not being a factor.<br><br>Erlang is an excellent choice if you value predictable latency and highly robust operation, even in the event of considerable load on the system. Here, your main vehicle for scaling would be to buy more cores. It tends to be a bad choice if you have a small computational kernel which takes all the time. In that event, you need a language where you can tune the tight kernel for speed, while ignoring everything else.</div><div class="gmail_extra"><br></div><div class="gmail_extra">OCaml is an excellent choice if you believe the problem space itself requires complicated abstractions where you are likely to make a mistake at the type-structural level of the program. If you use the type system cleverly, you can arrange such that you cannot make mistakes by accident on how to program the exchange correctly. OCaml is pretty fast to boot, and you can get decent asynchronous behaviour with core.async. Otoh, you won't be able to seamlessly scale in more than a single core and if this proves to be a bottleneck in your system, you have to write code all of a sudden to handle it.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Java + LMAX/Disruptor has its share of problems. Go is excellent when it comes to multi-core scaling and computational processing power. But it severely lacks when it comes to robust behaviour.<br clear="all"><div><br></div><div>My bet would definitely be on either Erlang or OCaml. The former because there is a nice fit with the problem domain. The latter because it is a favorite among high-frequency-trading companies, and its abstraction features are a well-known advantage in that space.</div><div><br></div>-- <br><div class="gmail_signature">J.</div>
</div></div>