Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Case study: Algorithmic trading with Go

polygon.io

Post reply on HN
Print view View original

121–130 of 311 posts

Re: Case study: Algorithmic trading with Go

#121

Post by IshKebab »

RomanPushkin wrote: post #103

Go itself, or any other language won't give you too much of an advantage. What gives you advantage is trading algo, which is always hard to find. I've spent months on figuring out the best parameters for trading. Ended up this working only on historical data, while in reality it was totally different. I could use Visual Basic, and it would be better than Go, Rust, or whatever it is out there, given the algo and strat…

You overfitted. That can happen due to human optimisation as well as computer optimisation. After you have experimented on some historical data for a while it becomes less useful.

Re: Case study: Algorithmic trading with Go

#122

Post by IshKebab »

dataviz1000 wrote: post #68

I've been building a bot with Typescript because it is what I know and Python because of the tools available. It is an overwhelming lonely endeavor. With all my other projects, I've always worked on teams, although they have always been very small teams and most of my work was autonomous -- still there was the occasional meeting and stand-ups. I've been working on this for six months and thought about bringing a frie…

How can you hope to compete with the pros? You're not going to be faster than them and unless you have several PhDs in maths it's unlikely you'll come up with a better algorithm.

The only way I can think of is to get data that they can't.

Re: Case study: Algorithmic trading with Go

#123

Post by devgoth »

_zkyx wrote: post #59
slashdev wrote: post #52

Earlier quoted context omitted.

Fascinating. Have you considered open sourcing this without your algorithms ( empty buy/ sell loops)? I’d like to play with something like this but I couldn’t be bothered to build it all from scratch.

Yeah, I can do that. Ping me at [redacted] and I'll send you a note when I've done it.

sign me up as well! I would def be interested too.

Re: Case study: Algorithmic trading with Go

#124

Post by hu3 »

_zkyx wrote: post #106
RomanPushkin wrote: post #103

Go itself, or any other language won't give you too much of an advantage. What gives you advantage is trading algo, which is always hard to find. I've spent months on figuring out the best parameters for trading. Ended up this working only on historical data, while in reality it was totally different. I could use Visual Basic, and it would be better than Go, Rust, or whatever it is out there, given the algo and strat…

Hey, I write this. I did program this in Go. The reason is that it's my go to programming language. Using it is actually a disadvantage in that the industry uses C++ and Python but that's just what I know how to program in. I wasn't trying to be misleading. Go does work really well for taking in data, doing something with it, and then calling a remote API. So, it actually works really well but if you wanted to get a…

Go is great for network heavy apps like algo trading!

I used Go to write trading algos that would find small windows of triangle arbitrages in crypto exchanges. Made me some money but the risk of a big loss made me stop pursing crypto trade and it required too much time and attention. It's a full time job from my experience. Reasons I could lose big at any given time if I scaled up the stakes:

- Exchanges temporarily pausing some specific crypto trading for N reasons (happened very often) while I'm in the middle of the arbitrage.

- Getting caught in the middle of a pump and dump event (also frequent)

- Any algo mistake that would perform excessives trades in succession would incur huge losses because crypto exchanges charge %.

Also, most cryptos have too low volatility. Every time I tried to scale my bot would start interferring oo much with the market. And it wasn't even much money.

Re: Case study: Algorithmic trading with Go

#125

Post by tomcam »

quickthrower2 wrote: post #98
tick_tock_tick wrote: post #82

Earlier quoted context omitted.

Single point of failure is a simple justification right off the top of my head. What happens if you have a critical failure that brings down an exchange for several days?

As a counter I had some VW shares I couldn’t access for 6 months because they were moved to another exchange. 20 calls to the broker to find out what had even happened. Eventually I was able to sell them.

Well, your first problem was investing in VW (KIDDING!). But seriously, I usually stick to self-serve stock purchases. Was this a situation where you had to contact a human to make the buy in the first place, or was it that you bought it yourself, then VW changed up their infrastructure and inadvertently locked you out?

Shitty situation either way.

Re: Case study: Algorithmic trading with Go

#126

Post by tomcam »

allenrb wrote: post #89
ilyt wrote: post #84

Earlier quoted context omitted.

So many intelligent people applied for something that has no value whatsoever to humanity regardless of how you look at it.

Essentially yes. When I worked in algo trading, it never bothered me that we were extracting profits from the markets, nor that we served little social good. It felt like a step up from where I’d been before (being told that we were making the world a better place, when every engineer knew otherwise.) At least we weren’t making things obviously worse. What did bother me, and was acknowledged by my coworkers, was how…

Seems like every person I've ever met in M&A has ended up hating life because of their career choice. They seem to burn out in 5 years or so after salting away a million bucks or 3. Was that your feeling doing the HFT thing?

Re: Case study: Algorithmic trading with Go

#127

Post by Ntrails »

joshu wrote: post #57

also having worked in the space: HFT should not exist. Break up the day into segments and have a single crossing. Do it every five minutes or whatever for sufficient timeliness. the millisecond race does not make anything better for anybody except the people doing the trading.

We tried this in Taiwan. They reverted to continuous matching.

Re: Case study: Algorithmic trading with Go

#128

Post by tomcam »

hu3 wrote: post #124
_zkyx wrote: post #106

Earlier quoted context omitted.

Hey, I write this. I did program this in Go. The reason is that it's my go to programming language. Using it is actually a disadvantage in that the industry uses C++ and Python but that's just what I know how to program in. I wasn't trying to be misleading. Go does work really well for taking in data, doing something with it, and then calling a remote API. So, it actually works really well but if you wanted to get a…

Go is great for network heavy apps like algo trading! I used Go to write trading algos that would find small windows of triangle arbitrages in crypto exchanges. Made me some money but the risk of a big loss made me stop pursing crypto trade and it required too much time and attention. It's a full time job from my experience. Reasons I could lose big at any given time if I scaled up the stakes: - Exchanges temporarily…

It was my (admittedly ignorant) impression that C++ was preferred over garbage-collected languages because you'd be more likely to avoid GC pauses. Yes, of course I know that Go's is super efficient, but if you're doing a million trades a day even a tiny percentage of slowdowns that would be otherwise preventable could be a career-limiting move. Am I just behind the times?

Re: Case study: Algorithmic trading with Go

#129

Post by HWR_14 »

chollida1 wrote: post #117
HWR_14 wrote: post #111

Earlier quoted context omitted.

If the NYSE went down, wouldn't most trading stop because of people being frightened about using old mismatched prices? Besides, when has an exchange gone done for hours, let alone days? Absent intentional breaks in trading as speedbumps.

> If the NYSE went down, wouldn't most trading stop because of people being frightened about using old mismatched prices? Why would you assume that. Every exchange is a valid place to trade and the sip ensures you always have the correct NBBO

I assumed that some exchange provides enough volume that without it there would be worries that you aren't getting true price discovery. Isn't that a concern with low trading volume? Not that that would necessarily be true, but there would be enough concern to cause some people not to trade. And others to want to trade specifically with those kind of nervous people wouldn't because the people they expected to profit by were staying put. And then it would cascade.

Re: Case study: Algorithmic trading with Go

#130

Post by hu3 »

tomcam wrote: post #128
hu3 wrote: post #124

Earlier quoted context omitted.

Go is great for network heavy apps like algo trading! I used Go to write trading algos that would find small windows of triangle arbitrages in crypto exchanges. Made me some money but the risk of a big loss made me stop pursing crypto trade and it required too much time and attention. It's a full time job from my experience. Reasons I could lose big at any given time if I scaled up the stakes: - Exchanges temporarily…

It was my (admittedly ignorant) impression that C++ was preferred over garbage-collected languages because you'd be more likely to avoid GC pauses. Yes, of course I know that Go's is super efficient, but if you're doing a million trades a day even a tiny percentage of slowdowns that would be otherwise preventable could be a career-limiting move. Am I just behind the times?

I think you're right! Go will never beat C++ in this aspect.

I used Go because that's what I knew and for the non-professional trading I was aiming, C++ wouldn't have made much difference. My bottlenecks were network (1s+ per trade roundtrip) and chaotic unreliable crypto markets.

Just note that Java is used in HTF, but it's a different beast than our average CRUD Java. For example this article states:

"Essentially, we use a contrived form of Java that avoids all the Java constructs that make things go slow. We only use the constructs that are fast and efficient, and we avoid all the garbage."

https://www.efinancialcareers.co.uk/news/2020/11/low-latency...

Post reply on HN