4 ms·
Jane Street is not the only HFT firm out there, though you'd think so from reading the comments here. Most use C++ and Java. C++ is everywhere, from embedded t
by cgh 12y ago
Jane Street is not the only HFT firm out there, though you'd think so from reading the comments here. Most use C++ and Java.
C++ is everywhere, from embedded to application software to games to the server side (Google has a gigantic C++ codebase).
I worked on a camera that had its logic written in C++ and it wasn't some unusual thing.
- loup-vaillant 12y agoMy point was, HFT is possible to do with something other than C++. Jane Street does OCaml, and you have just cited Java (garbage collection and virtual machine!). Since C++ is such a Chtuloid horror, the mere fact that it is possible to use other language, let alone garbage collected languages, is extremely strong evidence that C++ simply isn't the best choice. You haven't refuted my point, you have supported it. (Of course, I don't take legacy code nor talent availability into account. They are crucial in any real-world decision, but they don't influence the virtues of the language itself.)
- vinkelhake 12y ago> Since C++ is such a Chtuloid horror, the mere fact that it is possible to use other language, let alone garbage collected languages, is extremely strong evidence that C++ simply isn't the best choice. Yeah, well, that's just, like, your opinion, man. Seriously though, don't mistake your personal opinion for some objective truth. There are plenty of programmers out there who enjoy C++ and don't see it as a Chtuloid horror. What you have isn't strong evidence of anything, really. > (Of course, I don't take legacy code nor talent availability into account. They are crucial in any real-world decision, but they don't influence the virtues of the language itself.) And there are even more "external" factors to consider, but if you allow yourself to cherry-pick criteria then you can make any language be the optimal choice. Languages don't exist in a void.
- loup-vaillant 12y agoIt's not just my opinion. Do I have to resort to the nuclear option? http://www.yosefk.com/c++fqa/ http://www.yosefk.com/c++fqa/ Well, there you have it. C++11 and 14 made some things better, but they also have their problems. My opinions have different strengths. This one has accumulated enough evidence that I no longer consider the possibility of its falsehood. C++ sucks, and that's the end of it. I know of the gazillion eminently reasonable reasons why C++ is what it is, but it still sucks. I know that if Stroustrup made cleaner choices for the language, it wouldn't be so popular, but it still sucks. I know that a better language that nobody use is… well… useless, but C++ still sucks. In my opinion, C++ is one of our greatest shame as a community. > If you allow yourself to cherry-pick criteria then you can make any language be the optimal choice. I don't cherry pick. I'm just comparing languages. Not external tools. Not backward compatibility. Not programmer availability. Just languages. The other criteria are short term considerations, and greatly increase status-quo bias. They're only interesting when I must do a small project now, with whoever happen to work with me at the moment. For bigger projects however, the language is increasingly important. The bigger the project, the more reasonable it is to switch to use a better language, instead of a better known language.
- hft_throwaway 12y agoGuys who write HFT systems in Java are basically programming them like one would in C or C++. They pre-allocate byte buffers for everything and never run the GC. If you write C-style code in Java, it's going to run pretty quickly. They aren't doing architecture astronaut AbstractMetaClassFactory stuff or using much of the provided libraries for latency-sensitive code. FWIW, I don't think Jane Street is a competitor in the "ultra HFT" space where every nanosecond counts. AFAIK they are more of a statistical and quantitative trading group, so they may have less need for things like talking directly to hardware, keeping tight control over memory layout, deterministic latency w/o GC pauses, etc. Almost everything that is popular has evolved over time, and making these changes once you have established users results in compromises that can be sort of ugly. C++ has patina.
- loup-vaillant 12y ago> Almost everything that is popular has evolved over time, and making these changes once you have established users results in compromises that can be sort of ugly. C++ has patina. You will note that C++ made that sort of ugly compromises from the start. Keeping a C-like syntax really wasn't necessary. (Keeping a C-like semantics, that's a different story.)
- hft_throwaway 12y agoBut isn't that because C++ itself evolved from C? The original "C With Classes" wasn't much more than a convenient syntactic sugar for using structs and function pointers as a poor man's object system, something that was and is common in large, abstract C programs (e.g. Linux's VFS layer, Gtk+). I think you may be confusing is with ought here. Everybody sane knows C++ has flaws; I think Meyers even feels this way in his presentation. C++ is popular because it evolved and thus contains a lot of compromises. To draw an analogy, the Mormon Church is immensely popular in the US for similar reason--they basically said, "Hey the New and Old Testaments you spent your formative years learning are all good, but we've got some swell new stuff here too!" I'm sure Zen Buddhism is more theologically pure, but people like what's familiar to them. Programming languages are a network effect problem first and foremost. Just like it's hard to unseat Craigslist despite its crappy UI, it's difficult to get users for a new language that may be only marginally better in terms of features, productivity, safety or convenience. Even if it's a significant improvement existing code bases, library availability, programmer availability with domain knowledge and so on matter much more for serious projects. There's a reason why Facebook took the time to write a PHP VM instead of rewriting their code.