Java (RTS) and C#

Discussion in 'Programming' started by jtrader33, Sep 29, 2011.

  1. I should preface this whole post by saying that I have little idea what I'm talking about:

    I've been using VBA for a long time and have had some limited exposure to other languages via trading platforms/automating windows tasks/etc. I'd like to take a step up in a programming language for trading applications but am not quite sure what the best path to follow is at this point in time. I know there's a whole bunch of these threads in the archives and I've read everything I could find (here and elsewhere)....however, I want to make sure that I'm making the decision with current information.

    Based on what I've read, I don't think I'll be considering C++ (complexity, development time, ability to shoot yourself in the foot)...pretty much narrowed it down to C# and Java. My understanding is that C# likely holds a slight performance edge, but does that remain true if one uses the RTSJ with Java? I've watched some video on youtube from one of the authors of the book linked below and it seems as if it would make a big difference in performance, but strangely there's little written about it on the web (and almost nothing here at ET) it unpopular for a reason, or just new? Essentially, I'm wondering whether one of these languages will likely outperform the other 2-3 years down the road?

    Ultimately, I'll be looking to building something that can work with data vendor's APIs, work with a large local database, and execute orders via a broker's API. Would appreciate anyone's recommendation on which to go with (and any learning resources)...I keep going around in circles...seems like there's a slight preference for C#, but at the same time Java seems to have broader applicability and larger support community.
  2. rosy2


    either. you dont need RTSJ. 2-3 years down the road they will both have comparable performance. Keep in mind that you probably will not be writing anything performant so you could use any language under the sun.
  3. Thanks for the reply (and the dose of reality...ha). I do want to keep the possibility open though that at some point I may want to screw around with some strats where latency is a consideration. Not that I would ever get involved in the co-location/hft sandbox, but say I wanted to run something on 1000 symbols which is event driven and has a roudtrip of 'tick on exchange -> model calcs -> my order arriving at exchange' less than 2 seconds. Would your answer still be either?...or neither (go with c++)...or RTSJ?

    I understand the critical components when worrying about speed are network, broker risk checks, etc...however, I can easily get a dedicated line, switch to DMA (at least i think that's possible via prop)...but what is difficult to undo is the year or two I spend learning the ins and outs of one language only to find out it will become the bottleneck with the correct infrastructure in place.

    Hopefully that made sense. If they remain equal, I guess I'd go with whichever one is more versatile (and secondarily, easier to learn). Also, just out of curiosity, assuming RTSJ wouldn't be the answer, has it gained in popularity? Who typically uses it?
  4. mickmak


    For broker API integration, Java or C++ would be my choice as C# api is not as prevelant.

    The one thing to consider is vba integration with C#/.Net framework. If you migrate to Java, you will more work.

    I don't know if you should consider 2-3 years down the line as any algo you produce probably will need to be revamped. C++ may be the way to go ultimately if you need the speed - although java can be programmed to perform just as fast.

    If you are not a programmer by trade, I would search for one or two brokers that you want to use. Then see if they are Java/C++/or C#. Most likely they will have something for Java/C++.

    At the end of the day, you can always outsource your work to someone and have it written up.

  5. rosy2


    same answer, either. RTSJ or anything hard realtime (guarantees) is more for embedded devices like controls on a plane or brakes on a car. realtime in the trading world just means reacting to a stream of data.
  6. Thanks, this is helpful. While looking around at various datafeed/broker API offerings, I did notice that just about everyone had Java/C++...but not always C#. My current set up works fine on the suite of models I have running, so I don't plan to migrate anything...just would like to have the ability to look at some ideas which are too complex/cumbersome right now. Also, some part of me just enjoys programming, so picking up the additional language may get me interested in some stuff outside of trading...who knows.

    Anyway, I think I'm going to go with Java and if I need better performance at some point, I will either look to C++ or, even better, be able to incorporate real-time java without incurring too much brain damage.

    Here's another article by that same guy on real-time Java vs. C++ if anyone is interested:
  7. Okay, gotcha. I need to crawl before I can walk anyway...if Java ever becomes my problem, I can survey the options at that time...doesn't sound too likely from what you're saying though.

    Any opinions on using NetBeans vs. Eclipse for trading purposes? Also, I'm guessing the best place to get started is by going through the lessons/tutorials offered on sun's website...if there are other good resources, I'd appreciate any recommendations.
  8. Mr_You


    Your description of what you want to do is kinda broad.

    First off, C# and Java are similar in style and syntax. C#'s LINQ is interesting. I'm also interested in R and F# or Ocaml. Bottom line is any direction you decide would work, but querying a database will be a bottleneck vs a data stream/feed.

    If you're looking to build a trading platform then I would first ask why you want to reinvent the wheel? Why not use NinjaTrader (C#) or AlgoTrader (Java) or something else? Or atleast use them in addition to some custom code? If tool A couldn't provide the performance you need, then I would prototype in tool A then deploy in tool B.