Electronic trading, also known as automated trading, algo/algorithmic trading is, quite simply, a process of automatic buying and selling of financial instruments. It can be fully or partially automated. In recent years electronic trading of various flavours became extremely popular. Large banks, hedge funds and other investment institutions are on one end of scale of users, while small day traders and other part time and amateur players can be found on the other. Almost any kind of instrument is available on one electronic platform or another. Traditional shares, options, futures, Forex, bonds, although for the latter the automated markets are not mature enough yet. Lately we also observe the explosive entrance of cryptocurrencies into this field.

For historic and practical reasons, many participants of these markets develop their own software. While there are some off the shelf solutions, almost always they are not good fit to their end users' requirements. Making the necessary adjustments and modifications, as well as integrating these IT packages into the existing systems often requires so much effort, that it is easier and cheaper to develop a bespoke solution. Controlling the trading platform in full is also a very important consideration for the bigger players. The end result of in-house development can then in turn be sold as a service to other, less demanding users.

There are many legacy projects in the area of electronic trading. New, so called greenfield ones also pop up from time to time. Their designers must ask themselves the question - which technologies should we use to develop this new product? I will attempt to highlight some of the options available today, and indicate most obvious pros and cons.

First, it makes sense to summarise the attributes, both technical and administrative, which we can use to evaluate each candidate. The most important are:

• Performance. Languages and frameworks are not born equal when it comes to resource consumption, and if an electronic trading project is very latency sensitive, the final selection must favour the faster technology
• Ease of development. Some languages tend to be very tedious when it comes to writing even simple things. Ask any COBOL programmer. The less time we spend on coding, the faster we deliver the product, and less money is spent. A win for everyone
• Safety. There is more than one way to evaluate language's safety. In the end it boils down to this question - how easy would it be for a coding error to cause harm and how bad could it potentially be? For an electronic trading application this is a very important consideration. Often such systems are responsible for large amounts of money, so a software error can end up costing quite a lot
• Tools and libraries. Modern software development heavily relies on existing libraries, proving common and standard functionality. From file management to database connectivity to chart drawing, one usually tries to utilise an existing piece of software, rather than to write a new one. DRY, or don't repeat yourself, is a fundamental software development principle, ingrained into any decent programmer's subconsciousness. A good set of libraries might provide the developer with 80% of the functionality she needs, so she has to implement only the remaining 20%.
  Tools, such as editors, debuggers, code analysers, build systems are essential for any practical coding. A decent IDE and a high quality interactive debugger will make coders much more productive. End result - again, faster delivery times, smaller budgets, fewer future problems
• Popularity. Some languages and frameworks are great... on paper. Sadly, no one seems to be using them outside of academia and a small circle of enthusiasts. Designers of a new product should tread carefully with such a candidate. It might be very hard to find developers of any decent level of experience with the technology. There might be serious gaps in the tools and libraries section, as mentioned above. The community, to which one might turn for help, will be small, fragmented and not very helpful. Online and printed resources will be few and far between

Who is the fairest of them all?

There is no way I can point a finger at one technology and claim that it is the best. This simply makes no sense, since different frameworks have both pros and cons, and different projects have varying requirements and available resources. For example, HFT, or high frequency trading software is extremely sensitive to latency. Those guys really love their code to be fast. On the other hand, they usually have lots of money and are not afraid of investing it into their infrastructure, because this is how they make more of it. The life is brutal and competitive for the HFT traders of the world. Correspondingly, small scale amateur investors don't have the cash and neither do they have the need to be extremely fast. For them the important thing is to have something working quickly and cheaply. There are any number of intermediate stages in between. So, in each case the right answer will be different.

With that in mind, let's look at some of the candidates.

C++ - the good old and slightly crippled friend

C++ has been around for a long time. It is fast, versatile and widely available. There many libraries and tools for the language. Plenty of programmers have some experience in it. Recently the language has been going through a sort of renaissance - new standards appeared and improved the quality of it. There is a qualification to each one of these statements, however, so let's try and apply our criteria systematically:

• Performance - C++ shines here. One can write very fast code, which will be able to squeeze almost every single cycle out of the CPU (or GPU!) and every available byte out of RAM and caches. Only by switching to assembly can we do better than C++. The price that it charges is in higher expectations from the developer. She will have to manage many resources manually. This demands higher discipline and is error prone. End result - longer development times and higher number of software defects, or bugs
• Ease of development - as mentioned above, it is harder to develop in C++ than in other languages in this comparison. It takes more time for an average developer to become proficient
• Safety - we must be honest and admit, that C++ might not be the safest language around. As they say, with great power comes great responsibility, so when the language gives the coder full control over the resources, this creates opportunities for spectacular failures. The most damaging and infamous software exploits are usually found in C++ code and that written in its historical granddaddy, C. Modern C++ has tools and techniques meant to mitigate some of the risks and increase safety, but the potential is there
• Tools and libraries - here we have quite positive news. Since C++ has been around for a long time, and it is in the centre of many large and important projects, there are plenty of robust tools and libraries. However, given the complex nature of the language itself, the learning curve for those is also often non-trivial
• Popularity - once again, the language, its tools and libraries are still very popular. It is easy to find constructive information online and in the bookshops. There are lively communities, discussing C++ development. There are plenty of software engineers familiar with it. There is a wrinkle however - these tend to be somewhat older, since C++ is less popular with the new generations of hackers. Millennials and their followers often find it too complicated. Since there are plenty alternatives today, they simply don't bother studying it in depth, or at all. The older programmers, therefore, end up being both more scarce and more expensive

Java

Java is also a well established language. Similar to C++, it has been very popular around the world. Lots of tools, libraries and lively community. Looking at individual characteristics I can say this:

• Performance - Java is, in general, not as fast as C++, despite repeated claims to the contrary. The language and its runtime take some load off developer's shoulders, making her life easier, but at a price of, well, higher load on the hardware. The so called GC, garbage collection is an important aspect of this, and it can and will affect latency and throughput. It is in fact possible to write Java code that avoids using GC, actually achieving performance on par with C++. However, once you go down this route you end up with Java that looks surprisingly similar to C++, at which point you might wonder why to go to all this trouble in the first place
• Ease of development - thanks to simpler design and built in resource management, writing in Java is on average faster, than in C++
• Safety - Java does better here than C++, because JVM takes responsibility for the resource allocation, and prevents some classes of potential misuse and abuse. It also has additional practical security features on top
• Tools and libraries - Java is blessed with plenty of both. There are all sorts of libraries and state of the art tools for almost any task imaginable. Great news for any potential user of the technology
• Popularity - it must be clear by now, that Java is very popular. Online/offline resource are a plenty. Lots of experienced developers will be happy to take part in an interesting project

Scala

Scala is a kind of a relative of Java. Java itself is a language that compiles into so called Java bytecode, which then runs in JVM, Java virtual machine. There are in fact other languages that can be compiled into the same bytecode and executed inside JVM. Scala is one of them. As such, it benefits with almost full interoperability with Java. This basically means it can use most of its libraries and some of its tools "for free". On the other hand it brings many new technical features in terms of coding. In brief:

• Performance - similar to Java, for the same reasons
• Ease of development - this is where Scala scores quite well. Usually it is possible to write faster in Scala than in Java, due to its many advanced features
• Safety - Scala benefits from all the features of Java/JVM in this area, and brings a few more to the table, thanks to its functional-oriented paradigm
• Tools and libraries - thanks to interoperability with Java and to its own popularity, there are plenty of tools and libraries for Scala
• Popularity - Scala is reasonably popular, but not as much as Java or C++. There are fewer experienced developers and the available resources are not as plentiful

C#

C# is Microsoft's answer to Oracle's Java. There are many fundamental similarities between the two. Both are compiled into a bytecode and then run on top of a virtual machine. The framework is called .NET in C#'s case. Both .NET and JVM use GC. Both enjoy wide adoption and a thriving community. I personally like C# a bit more. In recent years Microsoft has been very active in developing new features for the language, while Java's evolution seems to be more slow. However, both are potentially excellent choices, given the right circumstances. Let's take a deeper dive into C#'s score vs our criteria:

• Performance - very similar to Java overall, for the same reasons
• Ease of development - quite good, on par or better than Java
• Safety - very similar to Java, since .NET provides many similar traits. The framework also has an additional and interesting security layer on top of it
• Tools and libraries - great many are available. Microsoft invests heavily into its own set of tools, both commercial and open source. Lots of third party offerings are available as well. When compared to Java, however, there might be slightly fewer options for C#
• Popularity - the language is very popular. The online community is very large, there is a substantial pool of software developers to choose from

F#

If C# is Microsoft's reply to Java, then F# is, in a way, their take on Scala. Don't take it literally, the language has quite old roots, deriving from OCaml, a dialect of ML. It is a functional language, like Scala, but it's design would appeal to many as cleaner, especially in its type system. It compiles into .NET's bytecode and also benefits with interoperability with other libraries and tools for the platform. Looking at its attributes:

• Performance - on par with C# and Java
• Ease of development - this is probably F#'s strongest point. It is surprisingly concise and compact, so one often writes noticeably fewer lines of code in order to implement the same thing as in C#
• Safety - very good, compared to many alternatives. It benefits from all the features of .NET, but also makes its own substantial contribution. By default, all values in F# are read-only, which enforces correct behaviour on the developer and helps to eliminate whole new classes of potential bugs
• Tools and libraries - thanks to .NET integration, lots of libraries and tools are available
• Popularity - F# is a great technology, but it is not as popular as some of the other alternatives mentioned here. It does seem to be spreading in recent years, so things should improve in some not so distant future

Rust

Rust is a new kid on the block, and it has been making some noise recently. It is admittedly the least mature of all the mentioned technologies. Nevertheless, it has some unique features that might be of interest to algo trading developers. In essence, Rust aims to be as fast and efficient as C++, while eliminating the risks, associated with the language. How does it manage to pull of this exceptional feat? In short, Rust allows either multiple readers or a single writer for any value at any given time. This is enforced at compile time, not during run time. This way the execution is still very fast, but the safety is uncompromised. Whole classes of potential bugs are eliminated, including the notoriously hard to detect and prevent race conditions in multi-threaded processes.

There are two main downsides to Rust today. First, it is quite challenging to master even for relatively experienced developers. The language is still evolving, so this might improve in the future, however I believe that it will be always somewhat harder than your average Python. Second, there are still not that many libraries and tools, even though the situation is improving. That said, let's take a closer look:

• Performance - Rust is supposed to be on par with C++, which is is great
• Ease of development - might not be Rust's strongest point. The language has its own, quite opinionated approach to to doing things, partially caused by its stated goals of speed and security at the same time. This will look very unfamiliar even to some experienced developers. On the other hand, these considerations apply mainly to the beginners, so more seasoned Rust programmers will probably be as efficient as, say, C# coders. The safety features of the language will prevent many bugs during compilation time, thus reducing the overall development effort
• Safety - as already mentioned, this is one of Rust's strongest points. In fact, if you want a language as fast as C++, while also actively preventing bugs at compile time, Rust is pretty much the only available option with any serious chances of successful application in the real world
• Tools and libraries - Rust is getting there. It is a new technology, but it has been embraced with enthusiasm by many developers. As a result, lots of libraries and tools are already available or are in development. There are still noticeable gaps, when compared to more mature candidates. And there aren't too many experienced (or even somewhat proficient) Rust developers around

Conclusion

I listed a number of technologies, which can be good candidates for a sizeable algo trading project. There are other technologies out there, that can be of interest, so don't be upset if your favourite language is not no the list.

The final decision will have to factor in many points, not all of them technical. Budgets, timeframes and availability of talent will have a very serious impact. And let's not forget, that most organisations won't be developing a new product in vacuum. Almost always they already have existing systems in place, which will need to interact with the new trading platform. Integration will often strongly affect the final decision. This is a story for some other time, however.