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.
Robinhood trading site seizes up, customers miss stock rally
51–60 of 65 posts
Re: Robinhood trading site seizes up, customers miss stock rally
#52Earlier 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.
Re: Robinhood trading site seizes up, customers miss stock rally
#53Re: Robinhood trading site seizes up, customers miss stock rally
#54I 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…
Re: Robinhood trading site seizes up, customers miss stock rally
#55Earlier 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
Re: Robinhood trading site seizes up, customers miss stock rally
#56I'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...
Re: Robinhood trading site seizes up, customers miss stock rally
#57I 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.....
Re: Robinhood trading site seizes up, customers miss stock rally
#58Earlier 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.
Re: Robinhood trading site seizes up, customers miss stock rally
#59I 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)
Re: Robinhood trading site seizes up, customers miss stock rally
#60Earlier 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.
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.