11 ms·

Recognizing that it is not politically correct in these parts to pose this question, I sometimes wonder if the Github team (which seems like a highly-skilled, c

• sitharus 14y ago
  I've stopped building on Rails because of things like this. Point releases shouldn't break functionality. I got tired of regression testing my apps for framework changes.
  • voidlogic 14y ago
    When I read the blog, the first thing I thought was "boy am I glad I don't use rails". I realize all frameworks and toolkits have issues, but Rails seems to be particularly bad. I think the big take away here is the importance of apparently redundant sanity checks....
    • shurcooL 14y ago
      What would be some potential alternatives?
      • Siecje 14y ago
        Django?
      • eranation 14y ago
        Play framework, Grails, Node, Django, Revel...
      • sitharus 14y ago
        ASP.NET MVC works pretty well these days. It's open-ish source as well, as in you don't need to pay to deploy it on Mono. I've used it with NHibernate for the ORM and Postgres.
        • manojlds 14y ago
          And don't forget the Web API http://www.asp.net/web-api http://www.asp.net/web-api
      • voidlogic 14y ago
        To rails? Thousands- so much depends on what exactly you need. Python? Django, Tornado, Twisted, etc Go? "net/http" + Gorilla (http://www.gorillatoolkit.org/) Java? JSF 2.0, GWT, Spring, Tapestry, etc etc C#? ASP.NET MVC This list could be almost infinite... or at least could be discussed infinity :)
        • kibibu 14y ago
          I've started a side-project using Go + Gorilla. It's actually very nice, but I don't think it's quite as productive for the early-stage as Rails is. I can certainly recommend Django - I've been working with a large-ish Django codebase for 3 years and have yet to see a security vulnerability as bad as the ones Rails seems to have every month.
        • tptacek 14y ago
          Any suggestion that implies Golang + Gorilla is comparable to Rails is poorly informed (and I really like Golang). "You know what you could do instead of using Rails? Implement your own ad-hoc version of 60% of Rails!"
          • voidlogic 14y ago
            I don't think that is fair; I did say "so much depends on what exactly you need." Maybe you don't need to whole kitchen sink. Also its not as though there are not other Go libraries to get other functionality from such as DB/ORM functionality.
            • tptacek 14y ago
              What's a good Golang ORM that you could use in a production app?
          • cmccabe 14y ago
            If people want something like Rails in Golang, it probably makes more sense to point them at Revel. Gorilla is more like Sinatra, for better or for worse.
      • cgh 14y ago
        While fully realising that the language itself is pretty terrible, Java + Spring + JavaMail is a pretty good framework and as a bonus involves minimal XML these days. I'm sure one of the alternative JVM languages would make this setup tolerable to work with, even pleasurable, but I don't know them.
      • gnuvince 14y ago
        OCaml [1] [1] https://news.ycombinator.com/item?id=2235204 https://news.ycombinator.com/item?id=2235204
      • ahmadss 14y ago
        google app engine (based on python)
      • throwawayG9 14y ago
        Symfony2
      • Freaky 14y ago
        Sinatra and Padrino are some of the more common Ruby alternatives, especially for smaller sites.
      • draegtun 14y ago
        Mojolicious - http://mojolicio.us http://mojolicio.us
    • sitharus 14y ago
      They all have issues - sure - but I've never encountered one so likely to break so spectacularly. Then again, it feels like ActiveRecord is a more complex beast than most others I've used. I've mostly used Hibernate and NHibernate, and SQLAlchemy a few years ago.
  • CamperBob2 14y ago
    I got tired of regression testing my apps for framework changes. I get tired of paying taxes and brushing my teeth, too, but I still do it, because life will get worse in a hurry if I don't.
    • Kudos 14y ago
      I think he's probably talking about dealing with the fallout from failed tests rather than the tests themselves.
    • j_s 14y ago
      Trying to understand where you're coming from here... I should write tests for every portion of the .NET Framework my app uses because it might break on a security update?
      • CamperBob2 14y ago
        If Microsoft had a history of breaking things with .NET framework security patches, then yes, absolutely. That's what people are saying happens with Rails, isn't it?
        • rtwtlkj 14y ago
          What are you, crazy? No, what you do is that you jump ship.
  • 33degrees 14y ago
    To be honest, I've had a lot more problems with gems external to rails than problems with rails itself; and this particular case seems like an issue that should have gotten caught via testing.
• niggler 14y ago
  "regrets building on Rails." I'm surprised they haven't tried to build their own framework / programming language (like Facebook with HipHop). It wasn't a bad idea to start with rails, but now they subject themselves to the issues of Ruby and Rails without an alternative
  • nonamegiven 14y ago
    I sometimes wonder if a good alternative to django/rails is to use the most minimal framework that's reasonable to start with, and then gradually customize it away.
    • mhartl 14y ago
      This actually sounds like a promising idea, though only if you've got insane dev chops on the founding team. In the Ruby world, Sinatra would be the obvious place to start. On the other hand, you might just end up reinventing Rails.
      • nathansobo 14y ago
        Tried it. You spend way too much time solving problems that are already easily solved in the existing larger ecosystems.
        • tlarkworthy 14y ago
          Yes indeed, and also leaves everyone in the muck when the lead dev leaves. Your left with a load of code you had wish you had documented as well as the previous frameworks. The value of existing frameworks is the documentation and stack overflow answers.
      • larrywright 14y ago
        I love Sinatra, but there's a long-running joke that if you look at the source for any Sinatra application with even a little complexity, you'll find a half-baked re-implementation of Rails inside. I've built apps like that and it's definitely not an exaggeration.
• tptacek 14y ago
  When Github started, they didn't just use Rails: they used Rails and shelled out to command line programs to integrate with git. If you have misgivings about engineering at Github now (I don't; I have the opposite of misgivings about they way they handle software), imagine a site built in the equivalent of shell scripts. I think the short answer is probably, nobody at Github has a lot of macro-level regrets at this point. I think the real issue is that the Rails community should be supremely grateful that they have a team like Github's building on the framework they've chosen. They all get to draft off the deployment/security/development/reliability work Github sinks into the platform. And, painful though it will surely be for HN to hear this, snags like the one today are how frameworks eventually get to be solid. Spent much time looking at Java Spring's track record?
  • phillmv 14y ago
    I think people forget how transformative Rails was. When it came out it blew people away. We all make fun of the 15 min blog today, but at the time it was really impressive. Nowadays it's not so amazing by comparison because everyone's caught up. Honestly, I think it's great that this all gets aired out in the open. The amount of transparency behind all of this is a breath of fresh air. Rails has had its share of growing pains; it really sucks that a security patch had a regression and I think this gave people a lot of flash backs to the pre Rails 3 days. By the end of this, however, we'll end up having a solid security infrastructure. I'm willing to wager that 90% of the time these kinds of issues just get swept under the rug and silently patched.
    • fuzzix 14y ago
      "We all make fun of the 15 min blog today, but at the time" I made fun of it at the time. "Great! Now audit and deploy it."
    • pjmlp 14y ago
      > I think people forget how transformative Rails was. When it came out it blew people away. We all make fun of the 15 min blog today, but at the time it was really impressive. Nowadays it's not so amazing by comparison because everyone's caught up. This was true for young developers or people without the right experience developing web sites at the time. Already in 1999 our company was using TCL framework built as Apache module that was quite similar to Rails. Following some designs similar to AOL Server. We just happened to be in Portugal and never had the press coverage that Rails did. By the time Rails appeared we had already moved into .NET/C++ to improve the scalability of our product. The same scalability issues that Twitter, LinkedIn and other American companies found out with Rails while deciding to move to JVM based alternatives.
• dubcanada 14y ago
  Github is not a website in the normal sense. Github is a layer over top of Git. One of the best wrappers for libgit/what ever there is (regardless of Language) is the Ruby rugged library which Github pretty much built. Before that was grit which was also Ruby based. And what Github was built on. Everything else is just extra they added on. Their core product is a Web based Git. But I sometimes wonder this as well, I love Ruby a ton. But I wonder how Github would have done had they used another language PHP, Python, Lua what ever. But then again the same thing can be said about Facebook, would they need less servers if they switched to another language?
• danenania 14y ago
  It's become fashionable to hate on rails, and honestly I understand the motivation--it isn't cool and cutting edge anymore. It's slow. It doesn't do concurrency well. Ruby is nice for what it is, but it lacks the power and stability of functional languages, and lacks the performance of go or javascript on v8. But rails is just doing what it's always done: trying to optimize developer productivity for front end web dev and routine web tasks. In this it's far ahead of the pack, and for many businesses, both small and large, this is exactly the right thing to optimize. Say what you want about github, but they push a lot of features and push them fast. Rails is not for crafting algorithms, but when you need to crank out 6 new pages with various complex crud views and forms by Friday, and by the way can it be exportable to cvs and oh can you also do paypal and oauth integration and user avatars with thumbnails, and keep it all reasonably readable and organized... the sad fact is that for all of rails' heft and lack of cs cred, trying the above with any other framework after you know rails will drive you insane, because despite how great the language is or how many connections your server can handle, you are again and again spending days on things that take an hour in rails. Ultimately, I don't think the way forward from rails is to search for a partial reimplementation of rails in some other language. Rails is the best we've got for rapid front end and shallow back end work. So use it for what it does well. For what it doesn't do well, use something else. Personally, I think it's silly to have an ORM written in ruby. ActiveRecord is for the most part a lovely api, but its guts should be a separate service written in go or something. Building a complex recommendation engine or game AI? Write clojure or haskell services. But when the data comes back and you need to dice it up and lay it out as html, with a hundred little ohs and ifs and buts, it's not a fun time without rails.
  • eru 14y ago
    Intereting. Your arguments sound a lot like the usual arguments in favour of PHP.
  • rtwtlkj 14y ago
    >>It's become fashionable to hate on rails, and honestly I understand the motivation Well, they were pretty vocal about calling everybody, in no uncertain terms, for using frameworks other than Rub/Rails, an idiot. There is plenty of bad will that they've been accumulating because of that and this is simply the backlash. If you really think you are the best there is no need to insult developers who do not use your frameworks. Unfortunately that is exactly what they did. People have long memories. And in my opinion they deserve every bit of it. The comment below by user mhartl demonstrates the attitude of pretending everybody else is shit. >>Ah, so following Greenspun's tenth rule [1], perhaps we >>have this: >> Any sufficiently complicated web application contains >> an ad hoc, informally specified, bug-ridden, slow >> implementation of half of Ruby on Rails. >>[1] http://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule http://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule The nerve to call other frameworks bug-ridden as if their shit didn't stink. Specially in light of all the security problems with Ruby/Rails that have come to light recently.
• jrockway 14y ago
  Rails isn't the problem. If it wasn't this bug that caused the emails to be exposed, it would have been some other bug. The problem was that there wasn't enough test coverage, and there weren't enough runtime assertions to shut off failing software. (if to_emails > 10: logging.fatal("Sending message to too many emails %s", to_emails))
  • kaoD 14y ago
    So if I'm driving my car and the accelerator pedal gets stuck... it's my fault for using the pedal without proper extensive testing? Even if the pedal got stuck after fixing my door locks because the manufacturer stuck the pedals as a side effect with no previous notice? There is no excuse: change of behavior shouldn't happen when installing security patches, specially if it's not mentioned anywhere in the patch release notes (which were reviewed by the GitHub team). Okay, I get your point, they should have tested it, you're right, but saying that Rails is not the problem is kind of being in denial.
    • jrockway 14y ago
      It's more like taking a homebuilt experimental aircraft out for its first test flight. When the engine blows up 30 seconds into your flight and you crash into a house, you'll probably wish you turned the thing on on the ground before actually flying it. Sure, the engine was faulty, but any of the parts could have caused the failure. The root cause was that you didn't even try to see if the thing worked in safe conditions.
      • kaoD 14y ago
        Security updates are not experimental! They're security updates. If it works fine and it breaks with a security update then it's the framework maintainer's fault.
        • jrockway 14y ago
          Like I said: yes, the engine failed, and the engine shouldn't fail. But it's unreasonable to expect that if only the engine had continued working, the test flight would have gone fine.