Live data from Hacker News

Robinhood trading site seizes up, customers miss stock rally

bloomberg.com

51–60 of 65 posts

Re: Robinhood trading site seizes up, customers miss stock rally

#51

I checked one of their backend engineering job postings, using Python and Go... mostly python? Probably should have chosen something ~~boring~~ safe, like Java. A dynamic language like python/ruby doesn't seem to be a good choice for critical financial applications. I'm know it can be done in python, but its about curbing any potential for human errors. Interested in seeing the RCA for this.

As far as I know, there’s no evidence of correlation between static types and bug density. Java should be no better a choice than Python or Ruby. You should still be testing your code.

Re: Robinhood trading site seizes up, customers miss stock rally

#52
post #32

Earlier quoted context omitted.

They said this isn't the case - https://twitter.com/AskRobinhood/status/1234861941413351434?...

According to https://www.reddit.com/r/RobinHood/comments/48mep4/robinhood... Robinhood went down 4 years ago, off by one day, to the date. Hard to take that reply seriously.

4 years ago, March 2nd was a wednesday, if it was leap year, wouldnt it have crashed on the monday or tuesday when the date didnt line up?

Re: Robinhood trading site seizes up, customers miss stock rally

#54

I would love to get on RH put down train, but my not no name 401k provider had issues with their website entire Thurs morning last week. It is kinda like a bank rush, only really well heeled institutions can survive everyone and their mother jumping in the fray. Now.. the common question is whether the company should have an infrastructure that can support its customer load at times like this.

I think to answer your question, yes, the company absolutely should have an infrastructure that can support this kind of load. The product that RH is selling is execution of trades, and failure to do so has drastic consequences. They are not some social network that can afford to go offline for a few hours due to high traffic, the stakes are significantly different. Another thing to consider is that there are so many…

Believe it or not, I agree with you. In cases like this I point to ISPs and their ability to sell more bandwidth than they can reasonably handle. Brokerages for regular clients know that lost uptime equals angry customers, who can and will move their money ( if not more ).

Re: Robinhood trading site seizes up, customers miss stock rally

#55
post #43
post #27

Earlier quoted context omitted.

Counterpoint: Erlang. Also, if "rigorous, non-optional" is good, why would you want _Java_ and not, I dunno, Haskell or ML or some other powerful type system? Is there any evidence this bug would have been prevented in Java? If anything, Java is prime ground for the related YYYY vs yyyy formatter bug.

Hiring pool for Java is orders of magnitude larger, let's not pretend this isn't an issue with esoteric languages like Haskell

So your argument is you need a language with static typing to prevent defects, but also the language must be proverbially this tall to ride, and so you end up with, say, Java?

Re: Robinhood trading site seizes up, customers miss stock rally

#56
post #15

I'm not a Robinhood user -- do they have guaranteed stop losses? This is something that could appease lots of users (assuming it's used correctly) even in this kind of situation (since _guaranteed_ stop losses exist pretty much for exactly this eventuality).

Stop losses are a feature you can use on the platform, but I don't know if they were executed on time if the whole platform was down...

Sure, but guranteed stop losses are a form of insurance where, even if the platform's out and stop losses don't execute in time, the customer will be reimbursed for any money lost as a result -- this is what's really more valuable here.

Re: Robinhood trading site seizes up, customers miss stock rally

#57
post #35

I saw a tweet that showed they didn't 'account for' leap years.. And by account for I mean: use a standard date library to handle dates. I too have made this mistake when younger and tried to be smart with dates, but not on a f'ing multi million dollar service >_<

Could you stop spreading a hoax.....

[deleted]

Re: Robinhood trading site seizes up, customers miss stock rally

#58
post #20

Earlier quoted context omitted.

Static typing makes it easier to discover errors before the code is running in production.

There is no rigorous study that has proven this. I wish there were because I strongly prefer static typing but it’s more a belief than anything proven.

I'm always surprised by what comes across to me as a dogmatic need for a "study" to prove something. There is no study that says my yard needs mowing once a week to look good. I know it because I've lived it. Similarly, I've lived in code bases that were once dynamic and were rewritten to be static. This is not an academic argument: the compiler catches things that I would otherwise have had to remember to put into a test.

Re: Robinhood trading site seizes up, customers miss stock rally

#59
post #39

I saw a tweet that showed they didn't 'account for' leap years.. And by account for I mean: use a standard date library to handle dates. I too have made this mistake when younger and tried to be smart with dates, but not on a f'ing multi million dollar service >_<

People saying the leap year thing is a hoax need to review what happened precisely four years earlier. (Hint: the same damn thing)

Wouldn't that have happened on the first trading day following the 28th? People are saying that the outage four years ago hit on Wednesday the 2nd. That makes no sense for this narrative.

Re: Robinhood trading site seizes up, customers miss stock rally

#60
post #27

Earlier quoted context omitted.

Rigorous, non-optional type checking isn't such a bad idea for high reliability.

Counterpoint: Erlang. Also, if "rigorous, non-optional" is good, why would you want _Java_ and not, I dunno, Haskell or ML or some other powerful type system? Is there any evidence this bug would have been prevented in Java? If anything, Java is prime ground for the related YYYY vs yyyy formatter bug.

> Counterpoint: Erlang.

Not even that much of a couterpoint; if you want strict typing, you can do it in Erlang with pattern matching / guards and tagged tuples, and/or with Dialyzer and type annotations.

Post reply on HN