HRT's Python fork: Leveraging PEP 690 for faster imports • Hacker News Board

Re: HRT's Python fork: Leveraging PEP 690 for faster imports

#51

Post by ActorNightly » Fri, Aug 08, 2025, 8:59 PM UTC

82716f12 wrote: post #45

ActorNightly wrote: post #43

Earlier quoted context omitted.

Man from all these responses, so many people are unaware of the finance world, lol. Or just bots posting for HRT In case you are unaware - very single trading firm makes money on fees, not by outperforming the market. This goes for firms like Vanguard too. Just think about it for a little bit - if you could reliably outperform the market by any % with an algorithm why even start a company? Just take out loans, invest…

HRT is a prop firm, which means they don't have outside investors. They invest their own money like you said, no income from fees. You just proved that you have no idea what you are talking about.

No, they are a liquidity provider. Liquidity providers only make money when there are imbalances in the market. Notionally because markets tend to drive fast towards efficiency, you can't realistically make money just being a market maker.

So then, you have to offer additional services. HRT has the SDP that they provide, and of course charge fees for. But then the question is why would anyone do this, versus just going through any other financial institution.

The answer is basically all up on their website

"As a liquidity provider, HRT develops automated trading algorithms designed to provide the best prices to our clients".

The question that should be asked is as a user, why would I want to sign up with HRT or any similar financial company? The answer for HRT is because you want to have access to more complicated financial derivatives - you don't need to sign up and pay fees to buy basic stock.

So they promise that their algorithms give the user the best price, which is a legal way of saying that you will pay less for a certain asset and make money on it, and you can't say that because you can't guarantee this.

And its well known that nobody ever gets rich of an algorithm in finance unless you are well established large firm intricately tied with the government that can move so much money as to influence trading.

Re: HRT's Python fork: Leveraging PEP 690 for faster imports

#52

Post by ActorNightly » Fri, Aug 08, 2025, 9:03 PM UTC

Redoubts wrote: post #49

ActorNightly wrote: post #48

Earlier quoted context omitted.

I can't tell if people don't understand how financial firms work or are you just being sarcastic. If a company has customers, and those customers buy a product, the company charges a price for that product.

> If a company has customers They don't...

a) What do you call this at the bottom of the page https://www.hudsonrivertrading.com/liquidity/

b) If you don't have customers, why have a company?

Re: HRT's Python fork: Leveraging PEP 690 for faster imports

#53

Post by tomhow » Fri, Aug 08, 2025, 9:05 PM UTC

cjj_swe wrote: post #37

ActorNightly wrote: post #32

Earlier quoted context omitted.

>Python devs at HRT really know their stuff. Its a finance firm - i.e scam firm. "We have a fancy trading algorithm that statistically is never going to outperform just buying VOO and holding it, but the thing is if you get lucky, it could". Scammers are not tech people. And its pretty from their post. > In Python, imports occur at runtime. For each imported name, the interpreter must find, load, and evaluate the con…

[flagged]

When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."

Please don't post shallow dismissals...

https://news.ycombinator.com/newsguidelines.html

Re: HRT's Python fork: Leveraging PEP 690 for faster imports

#54

Post by ActorNightly » Fri, Aug 08, 2025, 9:05 PM UTC

mhh__ wrote: post #34

ActorNightly wrote: post #32

Earlier quoted context omitted.

>Python devs at HRT really know their stuff. Its a finance firm - i.e scam firm. "We have a fancy trading algorithm that statistically is never going to outperform just buying VOO and holding it, but the thing is if you get lucky, it could". Scammers are not tech people. And its pretty from their post. > In Python, imports occur at runtime. For each imported name, the interpreter must find, load, and evaluate the con…

> "We have a fancy trading algorithm that statistically is never going to outperform just buying VOO and holding it, but the thing is if you get lucky, it could". You wish lol. How do you think they pay for all the developers? Firms like HRT don't even take outsider money, they don't really need to. And besides, we don't get paid for beating stocks, a lot of funds will do worse than equities in a good year for the la…

I don't know what you define as outsider money, but the fact is that they are a market maker, and you are never going to make large amounts of money on arbitrage by itself.

Re: HRT's Python fork: Leveraging PEP 690 for faster imports

#55

Post by bobmcnamara » Fri, Aug 08, 2025, 9:08 PM UTC

shepardrtc wrote: post #26

htrp wrote: post #15

Earlier quoted context omitted.

when milliseconds mean millions

Honestly if you're a millisecond too slow you might as well not trade at all. From my own experience with trying to get Python to go fast for crypto trading, you can get it pretty fast using Cython - single digit microseconds on an average AWS instance for a simple linear regression was my proudest moment. They're probably pushing it even faster because nanoseconds are where the money's at. Many HFT firms are down in…

For reference, a byte at 10gbps is almost 1ns long.

Though the encoder runs 64/66bits at a time, so you really get around 8B every 7ns or so.

Re: HRT's Python fork: Leveraging PEP 690 for faster imports

#56

Post by 82716f12 » Fri, Aug 08, 2025, 9:11 PM UTC

ActorNightly wrote: post #51

82716f12 wrote: post #45

Earlier quoted context omitted.

HRT is a prop firm, which means they don't have outside investors. They invest their own money like you said, no income from fees. You just proved that you have no idea what you are talking about.

No, they are a liquidity provider. Liquidity providers only make money when there are imbalances in the market. Notionally because markets tend to drive fast towards efficiency, you can't realistically make money just being a market maker. So then, you have to offer additional services. HRT has the SDP that they provide, and of course charge fees for. But then the question is why would anyone do this, versus just goi…

Being a market maker vs "We have a fancy trading algorithm that statistically is never going to outperform just buying VOO and holding it, but the thing is if you get lucky, it could" are two very different things lol

Moreover, I would be very surprised if the majority of their $8 billion annual profit came from client market making.

Re: HRT's Python fork: Leveraging PEP 690 for faster imports

#57

Post by ActorNightly » Fri, Aug 08, 2025, 9:12 PM UTC

82716f12 wrote: post #50

ActorNightly wrote: post #47

Earlier quoted context omitted.

>Runtime imports are a maintenance nightmare and can quickly fragment a codebase I agree, which is why you should design your modules correctly and import only the stuff you need. I was pointing out that lazy imports vs runtime imports in functions are basically the same and lead to the same issues.

> I agree, which is why you should design your modules correctly and import only the stuff you need. How do you achieve this without making gazillions of modules, where each module has just a few stuff? Are you saying just use local import everywhere?

You can have one module with all the capability, but the capability is separated into submodules. And the __init__.py of the module doesn't auto import the submodules

So when you do this

    import bigmodule

It doesn't do anything functionality, and you may only have some small top level things available for you, like bigmodule.config, or bigmodule.logging.

Then, you have your big initializer code in bigmodule.financedata. But the stuff you need for running scripts is in bigmodule.scripts.

So when you write

   from bigmodule import financedata

This code will take a while.

But if you write

   from bigmodule import scripts

This will load fast.

You don't need to have gazillion modules, just good organization. Also, in general, its a good practice to gate intensive compute/network operations behind an explicit function you need to call.

Also thank you for focusing the convo on the tech stuff instead of repeating finance bro myths

Re: HRT's Python fork: Leveraging PEP 690 for faster imports

#58

Post by 82716f12 » Fri, Aug 08, 2025, 9:21 PM UTC

ActorNightly wrote: post #57

82716f12 wrote: post #50

Earlier quoted context omitted.

> I agree, which is why you should design your modules correctly and import only the stuff you need. How do you achieve this without making gazillions of modules, where each module has just a few stuff? Are you saying just use local import everywhere?

You can have one module with all the capability, but the capability is separated into submodules. And the __init__.py of the module doesn't auto import the submodules So when you do this import bigmodule It doesn't do anything functionality, and you may only have some small top level things available for you, like bigmodule.config, or bigmodule.logging. Then, you have your big initializer code in bigmodule.financedat…

That sounds good in theory, but I haven’t come across a codebase that’s really optimized and free of unnecessary imports, especially in large companies.

And when you have to depend on external libraries beyond your control, how do you typically handle those situations?

Re: HRT's Python fork: Leveraging PEP 690 for faster imports

#59

Post by mhh__ » Fri, Aug 08, 2025, 9:23 PM UTC

ActorNightly wrote: post #54

mhh__ wrote: post #34

Earlier quoted context omitted.

> "We have a fancy trading algorithm that statistically is never going to outperform just buying VOO and holding it, but the thing is if you get lucky, it could". You wish lol. How do you think they pay for all the developers? Firms like HRT don't even take outsider money, they don't really need to. And besides, we don't get paid for beating stocks, a lot of funds will do worse than equities in a good year for the la…

I don't know what you define as outsider money, but the fact is that they are a market maker, and you are never going to make large amounts of money on arbitrage by itself.

Two business models:

Good returns - take other peoples money, trade it, take 20% of profits

Excellent returns - trade your own money, make a bit less overall but keep 100% of profits

Re: HRT's Python fork: Leveraging PEP 690 for faster imports

#60

Post by ActorNightly » Fri, Aug 08, 2025, 9:23 PM UTC

82716f12 wrote: post #56

ActorNightly wrote: post #51

Earlier quoted context omitted.

No, they are a liquidity provider. Liquidity providers only make money when there are imbalances in the market. Notionally because markets tend to drive fast towards efficiency, you can't realistically make money just being a market maker. So then, you have to offer additional services. HRT has the SDP that they provide, and of course charge fees for. But then the question is why would anyone do this, versus just goi…

Being a market maker vs "We have a fancy trading algorithm that statistically is never going to outperform just buying VOO and holding it, but the thing is if you get lucky, it could" are two very different things lol Moreover, I would be very surprised if the majority of their $8 billion annual profit came from client market making.

Right, exactly what I said. They don't make money by market making. They make money by charging transaction fees, and on an access basis to their "algorithms" which are designed against analyzing the complex futures that they are the market maker for.

The incentive for users to sign up with them is to get access to "better" pricing for whatever commodity they pair the buy/sell orders for - but remember these are futures so its all betting, and so the algorithms don't really mean anything.