6 ms·

This smug attitude is something we've seen a lot from the Ruby, and especially the Rails, community, and it always burns them. They had this attitude when it c

This smug attitude is something we've seen a lot from the Ruby, and especially the Rails, community, and it always burns them. They had this attitude when it came to the maintainability of Ruby apps. They'd say that Ruby code was much more maintainable than Java code, for instance. Now that we've got some Ruby apps that are several years old, and that have been worked on by a number of different people, it has become quite apparent that Ruby code is much less maintainable, over the long term, than Java code is. This same attitude was shown when it came to Ruby's performance. Many of us had serious misgivings about just how poorly it performed, and the suitability of Ruby on Rails for anything beyond simple sites. Then when some Ruby on Rails sites started facing moderate traffic, they basically collapsed. The answer from the Rails advocates was to "throw more hardware at it". We even saw this same attitude when it came to this very issue. We'd heard about how Ruby on Rails is far more "secure" than alternatives. Yet that's proven not to be the case. When Rubyists make claims, it's best to doubt what they're saying, and to question every single detail about it. They have given themselves a bad reputation for making incorrect statements.

tptacek 14y ago
I wasn't making a language war claim. Every platform has security bugs.
FooBarWidget 14y ago
Not sure where you got the idea that it's a "smug attitude". The article explains the facts and adds some commentary, nowhere did it claim that the bug does not exist or that one should not upgrade. Its intention is provide the facts and details of the exploit to counter the FUD coming from incomplete information and knee-jerk reactions. The bug is taken very seriously.
phillmv 14y ago
I'm surprised people are still making these arguments. Well, that's okay - don't use it then! We'll figure it out on our own. I'm interested on the "maintainability" claim, though, because that one is new to me. Are there any blog posts that make this claim with some kind of example?
- amalag 14y ago
  It all depends on the writing style of the app. If someone writes the entire app as learning exercise in metaprogramming, then I am guessing it will be a nightmare to maintain.
- lobster_johnson 14y ago
  The maintainability criticism is nothing new, or unique to Ruby — it has been something that has been leveled at every dynamically-typed language (eg., Python, Perl) ever since they started to become popular for writing big apps. And it's still untrue. It comes from prejudice and fear about the lack of compile-time checks in dynamic languages. I know this personally, because I remember starting out with Python, and Java and C++ felt very safe — on a visceral level — in comparison, and Python felt very unsafe. I have since learned to recognize these feelings as irrational and unfounded. Any language allows you to shoot yourself in the foot, in different ways. It's just as easy to write an unmaintainable app in C++ as it is in Ruby.
- PommeDeTerre 14y ago
  The attitude within your first paragraph is an excellent demonstration of the maintainability problems I'm talking about. Programmers five or ten years in the future won't have much say about the software they're being asked or told to maintain. Telling them to just "not use Ruby" won't solve the maintenance issues they're facing while working on some Rails web app developed years earlier. I'm sure you can find numerous blog posts out there describing the maintainability problems with Rails web apps. Google for them. The fact that you're looking for blog articles makes me think that you may have limited experience with large-scale software development projects, especially those spanning many years and development teams. Have you ever worked on large, long-running C++ or Java projects, for instance? If you have, then it should be pretty obvious to you how inadequate the maintainability of Ruby code is. Ruby, and dynamic languages in general, lack much of the functionality that makes code maintainable after many years, or even decades. I really wish you did have this sort of experience, because I think it would make the maintenance issues more more obvious.
  - deleted 14y ago
    [deleted]
no_more_death 14y ago
It's unfair to say that the core language is flawed. Maintainability depends on how the language features are utilized. Some code uses monkey-patching gratuitously and that can harm maintainability, but judicious use of monkey patching is not a problem. On the other hand, maintaining a several gigabyte Java project can be a nightmare. Code bloat is certainly a factor here. Java is probably better for larger, more ponderous, enterprisey projects. Ruby is designed for rapid, agile development. So we don't need a "war" here; they serve different, equally important niches. I agree that there are performance issues with Ruby implementations such as the MRI. That's really part and parcel of an immature implementation, that is, it hasn't received the millions of developer man hours spent fine-tuning it, such as the Java ecosystem has received. However, I would observe that it's still easy to get Java performance very wrong. It turns out that efficient GC is hard -- really, really hard.
- MisterBastahrd 14y ago
  One man's elegance is another man's obfuscation.
rimantas 14y ago
> Yet that's proven not to be the case. You have a proof of that? Care to share? How does one even prove framework X being more secure than framework Y? > When Rubyists make claims, it's best to doubt what they're > saying, and to question every single detail about it. They have > given themselves a bad reputation for making incorrect > statements. Would you mind to reveal, what kind of -ist you are, and why the -ists you represent make only absolutely true claims? Or can we just agree, that this kind of generalization is silly and pointless?
dasil003 14y ago
Wow, you have a serious chip on your shoulder. Nothing you're saying here is more than a gross stereotypical generalization that's no better than whatever ignorant flames you read that shaped your opinion. Are you perhaps one of the Java devs that DHH poked in the eye back in the day?
petercooper 14y ago
Maybe. If so, it's only slightly more bearable than the attitude of many observers towards what or how they think "the Ruby community" collectively believe, do, or act. There's no singular Ruby community anymore than there's a C, PHP or "Linux community" whose behavior can be collectively judged.
- TallboyOne 14y ago
  Well said.
- jamesbritt 14y ago
  Thank you, Peter.
  - petercooper 14y ago
    I was convinced of your way of thinking, eventually ;-)
    - steveklabnik 14y ago
      I had this exact conversation with Chad Fowler once, where I was you and he was James. Now all four of us are in agreement.
- PommeDeTerre 14y ago
  No, I disagree. The Ruby community is, generally, far more cohesive and homogeneous than the others you listed. This may partly be due to it being a relatively young community, compared to some others. Anyone who has been to a Ruby conference, especially while not being overly involved with the community otherwise, would likely know what I'm talking about, for example. Almost the entire community is male. There are very, very, very few females involved. While other communities have an imbalance, it is nowhere near as lopsided as it is within the Ruby community. Another common trait is the use of Apple hardware. It's rare to see anything but Apple laptops or other devices being used by those within the Ruby community. I've been at talks where there are rows of 20 people, and over 15 of them are using a MacBook of some sort. There's very little true dissent within the community. The emphasis on "convention over configuration" ends up chiseling those conventions into stone, and nobody dares question them, even when they're obviously wrong. While I'm not saying every single member of the Ruby community is exactly like every other, there is a commonality that is not found in any other computing community. It's undeniable.
bstar77 14y ago
How on earth is the article smug? The author responded to the controversy with clear and concise examples demonstrating that the issue is relatively minor and very easy to address if you think you are susceptible. Additionally, most people seem to be using Devise over Authlogic now-a-days. Not saying it's ok to have bugs surfaced in less popular gems, but this thing isn't going to bring the internet down.
- tptacek 14y ago
  The issue is not relatively minor, although I think the author wrote this article in good faith not realizing how non-minor it is.
  - bstar77 14y ago
    It's minor because it's (apparently) already been patched and because the fix takes all of about 30 seconds to fix per instance of these types of functions. SQL injection and mass assignment issues are far more serious threats than something like this, but they are not interesting because it's on the developer to secure their app. This issue is is built up to be serious because many people seem to enjoy attacking rails and the community despite not realizing that the vast majority of the community is amazing. If there's a burning need to criticize ruby/rails, discuss Ruby's terrible garbage collection, or the state of MRI or Rails' lightspeed rate of change.
    - tptacek 14y ago
      I agree that it's good that the vulnerability has a transparent framework level fix, and I myself would rather see 2-3 more framework level bugs than a whole new bug class like mass assignment. Bug classes are usually worse than bugs. But that is not what people mean when they say this isn't a severe bug. They mean, "I read some article where some guy said you needed the right HMAC key on a cookie to exploit the bug", and I think that article is wrong, and thus the assertion about severity is wrong. It is a severe bug with an easy fix. Unfortunately I think there are some other bugs orbiting around it that don't yet have fixes.
derwiki 14y ago
Our Rails site successfully served 45k simultaneous requests for the National Moment of Silence two weeks ago. I call that moderate traffic, and we didn't fall over. Please stop assuming that no one can make Rails scale just because there are some popular stories of it not scaling.
- PommeDeTerre 14y ago
  What kind of hosting infrastructure was involved? You're only looking at part of the picture, I think. It's not just a matter of asking, "will the site hold up?", but rather it's one of "will the site hold up, given an economically-feasible amount of resources?" Throwing a lot of resources at a Ruby on Rails site for one day of heavy traffic is one thing. Having to do that for years on end just to maintain a reasonable level of service in the face of growth is a very different thing, and far closer to the reality that we have to deal with.
  - derwiki 14y ago
    Colo with 17 app servers. We didn't have to spin up additional workers, and this is about half the number of web servers the last startup-turn-IPO I worked at used (and they used Python!).
    - fpal3 14y ago
      2647 connections per server per second is pretty abysmal for modern server hardware, especially if you had to rely on a whole bunch of caching front-end complication and proxy web servers to make it happen.
      - FooBarWidget 14y ago
        You can't say that without knowing what the app does. A recent project that I've been involved with switch from Java to Ruby and they reduced the number of servers by 10 times (!). But I don't blame Java, I blame the programmers of the last code base. You can write unmaintainable messes in any language.
deleted 14y ago
[deleted]
- deleted 14y ago
  [deleted]
  - deleted 14y ago
    [deleted]
- PommeDeTerre 14y ago
  I suspect behind your comment there's probably a bit of nagging resentment because Rails seems to have triumphed over <PreferredFramework> despite Rails' Obvious Flaws -- amirite? No, you couldn't be any more wrong. I'm not sure why you Ruby on Rails advocates always make this assumption, or accusation, any time that you encounter somebody doesn't hold a pro-Rails attitude. I saw some other commenter in this thread make the same incorrect assumption. I couldn't even tell you exactly how many programming languages, frameworks and libraries I've worked with over my career. I've used Fortran, PL/I, COBOL, C, C++, Objective-C, Java, C#, VB, VB.NET, Python, Perl, JavaScript, and yes, even Ruby professionally at one time or another. I'm probably forgetting some, and there are also some proprietary languages I've worked with, too. I've lost track of how many different GUI, database, and web development frameworks I've encountered. Ruby on Rails is merely one among probably at least 80 to 100 frameworks that I've used at one time or another. You see, I don't really have a "preferred framework". I do know that some communities are made up of people who hold attitudes that are, to put it mildly, quite toxic. They make claims that they cannot back up. They make serious mistakes without realizing it, and then deny it when they are pointed out. The Ruby on Rails community is like this, unfortunately. I'm not going to pretend that they aren't, either.
  - jwilliams 14y ago
    Ok, but what's your point and how does it relate to the article? Your original post points to smugness, a lax approach to security and incorrect statements -- none of which I witness or interpreted from this blog post. In fact I'd argue this blog post actually refutes all of the points you are making. It's factual, detailed, to the point and it doesn't make light of the issue at all.
rjzzleep 14y ago
yeah well, tell you what. 70% of what i saw since coming to the us are enterprise .net applications(yeah, i'm not in silicon valley or nyc). the other 20% were dated oracle applications. The security practices i saw are nothing short of ridiculous. If you'd take all the rails vulnerabilities and put them in a pot, and compare them to the holes i've seen in the little time i looked at them it's like comparing a secure vault to swiss cheese. granted, saying x is secure, because y is inherently insecure is not a valid argument, but i've seen people first hand use these exaggerated advisories to justify that their bug ridden insecure enterprise stack is more justifiable for the enterprise. these people did not know pbkdf2, bcrypt, and even the sql injection whitepaper by microsoft(which btw is a joke). wanna write secure code? NEVER assume someone else is going to secure it to you. fact is, good advisories and quick reaction to those are not a weakness but a strength. You want to know the state of encryption in the enterprise world? Get a recent pastebin hack dump. Databases with passwords in plaintext, passwords in md5. as for your sites basically collapsed? yes they did, it got popular during ruby 1.8.5 ffs. what the hell do you expect? it's slow? well, that's why theres lot's of custom c around. but anyway, since then many many things changed. Java maintainable? In which world do you live? 8 different layers of OO abstractions 20 levels of dot notation, in which world is that maintainable? Notice how people move to groovy, scala, and other things, not plain java? ever wondered why? You want highly reliable systems, your answer is not going to be java. Try erlang, but that one is GENUINELY slow. Oh wait, did I even mention jruby? There you go, all the Java you want, kinda.
BUGHUNTER 14y ago
As a developer it is best to enable yourself to collect some relevant facts about technical questions and come to a decision based on that data. Basing an argument about technical things on "what people say" will not succeed, no matter what your goals are.

tptacek 14y ago

I wasn't making a language war claim. Every platform has security bugs.

FooBarWidget 14y ago

Not sure where you got the idea that it's a "smug attitude". The article explains the facts and adds some commentary, nowhere did it claim that the bug does not exist or that one should not upgrade. Its intention is provide the facts and details of the exploit to counter the FUD coming from incomplete information and knee-jerk reactions. The bug is taken very seriously.

phillmv 14y ago

I'm surprised people are still making these arguments. Well, that's okay - don't use it then! We'll figure it out on our own. I'm interested on the "maintainability" claim, though, because that one is new to me. Are there any blog posts that make this claim with some kind of example?

amalag 14y ago
It all depends on the writing style of the app. If someone writes the entire app as learning exercise in metaprogramming, then I am guessing it will be a nightmare to maintain.
lobster_johnson 14y ago
The maintainability criticism is nothing new, or unique to Ruby — it has been something that has been leveled at every dynamically-typed language (eg., Python, Perl) ever since they started to become popular for writing big apps. And it's still untrue. It comes from prejudice and fear about the lack of compile-time checks in dynamic languages. I know this personally, because I remember starting out with Python, and Java and C++ felt very safe — on a visceral level — in comparison, and Python felt very unsafe. I have since learned to recognize these feelings as irrational and unfounded. Any language allows you to shoot yourself in the foot, in different ways. It's just as easy to write an unmaintainable app in C++ as it is in Ruby.
PommeDeTerre 14y ago
The attitude within your first paragraph is an excellent demonstration of the maintainability problems I'm talking about. Programmers five or ten years in the future won't have much say about the software they're being asked or told to maintain. Telling them to just "not use Ruby" won't solve the maintenance issues they're facing while working on some Rails web app developed years earlier. I'm sure you can find numerous blog posts out there describing the maintainability problems with Rails web apps. Google for them. The fact that you're looking for blog articles makes me think that you may have limited experience with large-scale software development projects, especially those spanning many years and development teams. Have you ever worked on large, long-running C++ or Java projects, for instance? If you have, then it should be pretty obvious to you how inadequate the maintainability of Ruby code is. Ruby, and dynamic languages in general, lack much of the functionality that makes code maintainable after many years, or even decades. I really wish you did have this sort of experience, because I think it would make the maintenance issues more more obvious.
- deleted 14y ago
  [deleted]

no_more_death 14y ago

It's unfair to say that the core language is flawed. Maintainability depends on how the language features are utilized. Some code uses monkey-patching gratuitously and that can harm maintainability, but judicious use of monkey patching is not a problem. On the other hand, maintaining a several gigabyte Java project can be a nightmare. Code bloat is certainly a factor here. Java is probably better for larger, more ponderous, enterprisey projects. Ruby is designed for rapid, agile development. So we don't need a "war" here; they serve different, equally important niches. I agree that there are performance issues with Ruby implementations such as the MRI. That's really part and parcel of an immature implementation, that is, it hasn't received the millions of developer man hours spent fine-tuning it, such as the Java ecosystem has received. However, I would observe that it's still easy to get Java performance very wrong. It turns out that efficient GC is hard -- really, really hard.

MisterBastahrd 14y ago
One man's elegance is another man's obfuscation.

rimantas 14y ago

> Yet that's proven not to be the case. You have a proof of that? Care to share? How does one even prove framework X being more secure than framework Y? > When Rubyists make claims, it's best to doubt what they're > saying, and to question every single detail about it. They have > given themselves a bad reputation for making incorrect > statements. Would you mind to reveal, what kind of -ist you are, and why the -ists you represent make only absolutely true claims? Or can we just agree, that this kind of generalization is silly and pointless?

dasil003 14y ago

Wow, you have a serious chip on your shoulder. Nothing you're saying here is more than a gross stereotypical generalization that's no better than whatever ignorant flames you read that shaped your opinion. Are you perhaps one of the Java devs that DHH poked in the eye back in the day?

petercooper 14y ago

Maybe. If so, it's only slightly more bearable than the attitude of many observers towards what or how they think "the Ruby community" collectively believe, do, or act. There's no singular Ruby community anymore than there's a C, PHP or "Linux community" whose behavior can be collectively judged.

TallboyOne 14y ago
Well said.
jamesbritt 14y ago
Thank you, Peter.
- petercooper 14y ago
  I was convinced of your way of thinking, eventually ;-)
  - steveklabnik 14y ago
    I had this exact conversation with Chad Fowler once, where I was you and he was James. Now all four of us are in agreement.
PommeDeTerre 14y ago
No, I disagree. The Ruby community is, generally, far more cohesive and homogeneous than the others you listed. This may partly be due to it being a relatively young community, compared to some others. Anyone who has been to a Ruby conference, especially while not being overly involved with the community otherwise, would likely know what I'm talking about, for example. Almost the entire community is male. There are very, very, very few females involved. While other communities have an imbalance, it is nowhere near as lopsided as it is within the Ruby community. Another common trait is the use of Apple hardware. It's rare to see anything but Apple laptops or other devices being used by those within the Ruby community. I've been at talks where there are rows of 20 people, and over 15 of them are using a MacBook of some sort. There's very little true dissent within the community. The emphasis on "convention over configuration" ends up chiseling those conventions into stone, and nobody dares question them, even when they're obviously wrong. While I'm not saying every single member of the Ruby community is exactly like every other, there is a commonality that is not found in any other computing community. It's undeniable.

bstar77 14y ago

How on earth is the article smug? The author responded to the controversy with clear and concise examples demonstrating that the issue is relatively minor and very easy to address if you think you are susceptible. Additionally, most people seem to be using Devise over Authlogic now-a-days. Not saying it's ok to have bugs surfaced in less popular gems, but this thing isn't going to bring the internet down.

tptacek 14y ago
The issue is not relatively minor, although I think the author wrote this article in good faith not realizing how non-minor it is.
- bstar77 14y ago
  It's minor because it's (apparently) already been patched and because the fix takes all of about 30 seconds to fix per instance of these types of functions. SQL injection and mass assignment issues are far more serious threats than something like this, but they are not interesting because it's on the developer to secure their app. This issue is is built up to be serious because many people seem to enjoy attacking rails and the community despite not realizing that the vast majority of the community is amazing. If there's a burning need to criticize ruby/rails, discuss Ruby's terrible garbage collection, or the state of MRI or Rails' lightspeed rate of change.
  - tptacek 14y ago
    I agree that it's good that the vulnerability has a transparent framework level fix, and I myself would rather see 2-3 more framework level bugs than a whole new bug class like mass assignment. Bug classes are usually worse than bugs. But that is not what people mean when they say this isn't a severe bug. They mean, "I read some article where some guy said you needed the right HMAC key on a cookie to exploit the bug", and I think that article is wrong, and thus the assertion about severity is wrong. It is a severe bug with an easy fix. Unfortunately I think there are some other bugs orbiting around it that don't yet have fixes.

derwiki 14y ago

Our Rails site successfully served 45k simultaneous requests for the National Moment of Silence two weeks ago. I call that moderate traffic, and we didn't fall over. Please stop assuming that no one can make Rails scale just because there are some popular stories of it not scaling.

PommeDeTerre 14y ago
What kind of hosting infrastructure was involved? You're only looking at part of the picture, I think. It's not just a matter of asking, "will the site hold up?", but rather it's one of "will the site hold up, given an economically-feasible amount of resources?" Throwing a lot of resources at a Ruby on Rails site for one day of heavy traffic is one thing. Having to do that for years on end just to maintain a reasonable level of service in the face of growth is a very different thing, and far closer to the reality that we have to deal with.
- derwiki 14y ago
  Colo with 17 app servers. We didn't have to spin up additional workers, and this is about half the number of web servers the last startup-turn-IPO I worked at used (and they used Python!).
  - fpal3 14y ago
    2647 connections per server per second is pretty abysmal for modern server hardware, especially if you had to rely on a whole bunch of caching front-end complication and proxy web servers to make it happen.
    - FooBarWidget 14y ago
      You can't say that without knowing what the app does. A recent project that I've been involved with switch from Java to Ruby and they reduced the number of servers by 10 times (!). But I don't blame Java, I blame the programmers of the last code base. You can write unmaintainable messes in any language.

deleted 14y ago

[deleted]

deleted 14y ago
[deleted]
- deleted 14y ago
  [deleted]
PommeDeTerre 14y ago
I suspect behind your comment there's probably a bit of nagging resentment because Rails seems to have triumphed over <PreferredFramework> despite Rails' Obvious Flaws -- amirite? No, you couldn't be any more wrong. I'm not sure why you Ruby on Rails advocates always make this assumption, or accusation, any time that you encounter somebody doesn't hold a pro-Rails attitude. I saw some other commenter in this thread make the same incorrect assumption. I couldn't even tell you exactly how many programming languages, frameworks and libraries I've worked with over my career. I've used Fortran, PL/I, COBOL, C, C++, Objective-C, Java, C#, VB, VB.NET, Python, Perl, JavaScript, and yes, even Ruby professionally at one time or another. I'm probably forgetting some, and there are also some proprietary languages I've worked with, too. I've lost track of how many different GUI, database, and web development frameworks I've encountered. Ruby on Rails is merely one among probably at least 80 to 100 frameworks that I've used at one time or another. You see, I don't really have a "preferred framework". I do know that some communities are made up of people who hold attitudes that are, to put it mildly, quite toxic. They make claims that they cannot back up. They make serious mistakes without realizing it, and then deny it when they are pointed out. The Ruby on Rails community is like this, unfortunately. I'm not going to pretend that they aren't, either.
- jwilliams 14y ago
  Ok, but what's your point and how does it relate to the article? Your original post points to smugness, a lax approach to security and incorrect statements -- none of which I witness or interpreted from this blog post. In fact I'd argue this blog post actually refutes all of the points you are making. It's factual, detailed, to the point and it doesn't make light of the issue at all.

rjzzleep 14y ago

yeah well, tell you what. 70% of what i saw since coming to the us are enterprise .net applications(yeah, i'm not in silicon valley or nyc). the other 20% were dated oracle applications. The security practices i saw are nothing short of ridiculous. If you'd take all the rails vulnerabilities and put them in a pot, and compare them to the holes i've seen in the little time i looked at them it's like comparing a secure vault to swiss cheese. granted, saying x is secure, because y is inherently insecure is not a valid argument, but i've seen people first hand use these exaggerated advisories to justify that their bug ridden insecure enterprise stack is more justifiable for the enterprise. these people did not know pbkdf2, bcrypt, and even the sql injection whitepaper by microsoft(which btw is a joke). wanna write secure code? NEVER assume someone else is going to secure it to you. fact is, good advisories and quick reaction to those are not a weakness but a strength. You want to know the state of encryption in the enterprise world? Get a recent pastebin hack dump. Databases with passwords in plaintext, passwords in md5. as for your sites basically collapsed? yes they did, it got popular during ruby 1.8.5 ffs. what the hell do you expect? it's slow? well, that's why theres lot's of custom c around. but anyway, since then many many things changed. Java maintainable? In which world do you live? 8 different layers of OO abstractions 20 levels of dot notation, in which world is that maintainable? Notice how people move to groovy, scala, and other things, not plain java? ever wondered why? You want highly reliable systems, your answer is not going to be java. Try erlang, but that one is GENUINELY slow. Oh wait, did I even mention jruby? There you go, all the Java you want, kinda.

BUGHUNTER 14y ago

As a developer it is best to enable yourself to collect some relevant facts about technical questions and come to a decision based on that data. Basing an argument about technical things on "what people say" will not succeed, no matter what your goals are.