Rails pushes low time to market. That is all. Its built with precisely no engineering design or quality control on top of a poorly specified rickety language in a community of hype.
However, my original generalizes the problem as a human issue which is where the real problem is:
Did they do a risk analysis on rails - no
Did they verify their architecture - no
Did they perform input/type checking - no (sorry but statically typed languages win here)
Did they act responsibly - no
Would you trust them with your cash? Probably not then.
This is the opposite of banks who have multiple layers of security to prevent all the associated risks of the business.
Would a bank run their OLTP on rails? Hell no, because they did the risk analysis above, which is my point.
I agree on your analysis of the BC exchanges behavior. They neither did a proper risk analysis nor did they build a systen designed to safely handle the wallet nor did they respond in a timely and responsible manner. I just fail to see how that's rails fault.
Would a bank run their OLTP on rails? I don't know. I'd rather say that rails is a bad fit for that kind of problem, but that's not the goal. Rails is built for web-applications of a pretty specific type, quick build and release cycles while still keeping a solid focus on code quality [1]. So your problem is that folks see an opportunity to make money, take the first tool that seems to fit and build stuff that doesn't hold water. But that's language agnostic. You certainly realize that 10 years ago java was the "poorly specified rickety language in a community of hype".
Perhaps they should have done this up front, you know as part of the engineering, hence my point. Stopping and thinking for a bit usually covers these problems. I've read a huge chunk of the rails framework source code and it certainly used to be a pretty amateur piece of kit.
The argument is definitely not preposterous. Are you saying guarding against bad inputs and enforcing type is bad? A language which uses no type inference has less assumptions therefore is likely to be less error prone. I've proven this hundreds of times over the last 30 years of writing code in things from communications electronics to financial quotation platforms.
>Perhaps they should have done this up front, you know as part of the engineering, hence my point.
And you know what, I have a feeling they did have multiple people looking over the code, and it's been vigorously refactored over the years. Rails 3 is a somewhat different beast from Rails 2.
Careful auditing reduces bugs but does not eliminate them. Crowing about "proper engineering" is very nice but is somewhat farcical given the state of the art in the industry.
>Are you saying guarding against bad inputs and enforcing type is bad?
No. Of course you guard against bad inputs.
But that's wholly separate from enforcing the type of the objects. And it's not like people are eval()ing stuff willy-nilly.
"Actually, this bug was discovered precisely because people began to perform a more in depth analysis."
From Wikipedia: Ruby on Rails - Initial release July 2004
Eight-and-a-half years later, in depth analysis has come about to find this? (The exploit is present through 3.2, meaning it's been around all that time).
Rails pushes low time to market. That is all. Its built with precisely no engineering design or quality control on top of a poorly specified rickety language in a community of hype.
However, my original generalizes the problem as a human issue which is where the real problem is:
Did they do a risk analysis on rails - no
Did they verify their architecture - no
Did they perform input/type checking - no (sorry but statically typed languages win here)
Did they act responsibly - no
Would you trust them with your cash? Probably not then.
This is the opposite of banks who have multiple layers of security to prevent all the associated risks of the business.
Would a bank run their OLTP on rails? Hell no, because they did the risk analysis above, which is my point.