27 ms·

My time with Rails is up

• __mp 10y ago
  Scrolling in Firefox (OSX) is very slow.
  • questionfy 10y ago
    I noticed that too. But it renders and scrolls perfectly on Chrome. I wonder what's the difference? Firefox is typically a lot slower than Chrome, but the performance difference this time is amazingly large.
    • benvds 10y ago
      For me as well. It becomes unresponsive so I can't even debug why it's so slow.
    • __mp 10y ago
      It seems to be a bug. See here: https://news.ycombinator.com/item?id=11749503 https://news.ycombinator.com/item?id=11749503
  • solnic 10y ago
    Sorry about that, you can use Reader View in FF which works fine. Crazy part - it's not JS, I tried disabling it and it's still sluggish.
    • deleted 10y ago
      [deleted]
  • Twirrim 10y ago
    Was bad in Firefox on Windows too (even to the point of me googling to find tab profiling tools for firefox out of curiosity, didn't find anything useful that's still active, so I've no clue what it is doing it)
    • __mp 10y ago
      See this comment here: https://news.ycombinator.com/item?id=11749503 https://news.ycombinator.com/item?id=11749503
  • barkbro 10y ago
    styles-bluegreen.css seems to be the problem, firefox preforms fine if you block it.
  • thenonameguy 10y ago
    It's because of this bug in Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1250947 https://bugzilla.mozilla.org/show_bug.cgi?id=1250947 Disable the box-shadow on .widewrapper.main and it works fine.
    • solnic 10y ago
      Thank you my friend, I just fixed it <3
      • mstange 10y ago
        Thanks!
  • mstange 10y ago
    Oh no, it's that box-shadow bug again :-( We fixed in in Firefox 47, but the fix was deemed too risky to be uplifted to Firefox 46. That was probably a mistake. Anyway, Firefox 47 is going to be released in two weeks on June 7th. In the meantime you can remove the box-shadow from .widewrapper.main using the devtools, or you can use Firefox Beta (47) or Firefox Developer Edition (48), which you can get here: https://www.mozilla.org/en-US/firefox/channel/#developer https://www.mozilla.org/en-US/firefox/channel/#developer
    • __mp 10y ago
      Great! Thank you for the info! I'll stay with the current version: I have a Chrome installation for exactly that purpose.
• samfisher83 10y ago
  Trying to visit this page makes my browser lock up.
• tptacek 10y ago
  This is how Rails works, classic example: User.create(params[:user]) You see a simple line of code, and you can immediately say (assuming you know User is an AR model) what it’s doing. The problem here is that people confuse simplicity with convenience. It’s convenient (aka “easy”) to write this in your controller and get the job done, right? Now, this line of code is not simple, it’s easy to write it, but the code is extremely complicated under the hood because: - params must often go through db-specific coercions - params must be validated - params might be changed through callbacks, including external systems causing side-effects - invalid state results in setting error messages, which depends on external system (i.e. I18n) - valid params must be set as object’s state, potentially setting up associated objects too - a single object or an entire object graph must be stored in the database This lacks basic separation of concerns, which is always damaging for any complex project. It increases coupling and makes it harder to change and extend code. This feels like the core of the argument of the whole post. It does not seem correct. In isolation, the call to User#create seems magical. But there's not enough context here to criticize it. We don't know enough to say whether there's inadequate separation of concerns. No matter how we handle "users", we are going to need to do all 6 things in the list the author presented. No matter how we structure those 6 things, there is going to be a single entrypoint function that kicks them off --- end users won't be pushing 6 different buttons to drive them. So: what's the better design here?
  • tangue 10y ago
    This might no be the the best example, but this is not a Medium blogspam, the guy has wrote several widely used gems and we should not stop at this technical example to invalidate the whole points he is trying to make (and I don't consider this code to be the core argument of the post.)
  • braythwayt 10y ago
    I agree that this is not a good example of simplicity vs ease, but I think his core argument is still correct about what Rails is. (Whether you or I may like/dislike "What Rails Is" is, of course, another matter.)
    • 10y ago
• fiatjaf 10y ago
  This should come at no surprise, although I don't see anyone criticizing Rails anywhere. I've never written a line of Ruby, but trying to read Rails code evokes me all this: it seems like a framework created with the sole purpose of hiding everything possible from the programmer.
  • gonyea 10y ago
    It's not hiding anything, other than the conventions. Django's spammy boilerplate is just default behavior.
    • kowdermeister 10y ago
      Conventions is something I try to avoid at all costs. Conventions are usually things that are hard to find in documentation. Conventions are things that every experienced user says that "oh, this is common knowledge" and conventions are the reason why things seem to work magically. Obviously if you follow a framework from day 0 you don't even notice it. For newcomers, it's a source of frustration.
      • nitrogen 10y ago
        Frameworks should be designed for experts as well as newcomers. I was a Ruby-only developer and, after starting a full time Rails job, picked it up quickly enough.
      • lobster_johnson 10y ago
        That's not really what convention refers to here. Rails' motto "convention over configuration" simply means that boilerplate should be avoided, and that code should use sensible defaults whenever there isn't information. For example, ActiveRecord class names map to table names through a simple pluralizer (UserProfile -> user_profiles). That's a convention, no configuration needed. Just write a class and off you go. You can override this behaviour, but you can also write huge apps that just follow the convention. Other frameworks would typically make this mapping explicit. You do need to read the documentation to see what the conventional behaviour is, but it's not very deep knowledge. It's not much worse than other frameworks, where you need to find how things are configured.
• btcboss 10y ago
  Another Rails is good/bad post. Just like the rest....
• tangue 10y ago
  Rails developers are spending more time fighting Rails these days than improving it. I have the feeling that good coders have left the ROR ship and that Rails is now the framework for code-schools and learn-to-code bootcamps. It's a bit sad, but as long as Rails is tied to Basecamp I don't see any solutions. The author is right, competition is important, the Rails/Merb scenario is the open-source version of Microsoft E.E.E
  • dhagz 10y ago
    Really, even if it weren't tied to Basecamp I think if DHH remains as Rails' BDFL, we won't see the type of changes a lot of developers want to see. Which just means we need to highlight other frameworks like Hanami, Trailblazer, et al. in Ruby user groups.
• gonyea 10y ago
  This isn't a Rails gripe. He only seems to know Ruby/Rails and lashes out at it. Frameworks = Lots of abstraction. At least the abstractions in Rails aren't leaky.
  • eropple 10y ago
    solnic wrote the majority of DataMapper, its successor rom-rb, and the Virtus object modeling library. He knows much more than Rails and understands its problems.
    • waffle_ss 10y ago
      Not to take away from solnic's many valuable contributions to open source, but I think it would be more accurate to say he was a heavy contributor to DataMapper rather than that he wrote the majority of it https://github.com/datamapper/dm-core/graphs/contributors https://github.com/datamapper/dm-core/graphs/contributors
      • solnic 10y ago
        Yes, I was on the core team between 2010-20#{hard-to-tell}. DataMapper was created by Sam Smoot and quickly taken over by Dan Kubb who did a crazy amount of work, practically rewriting it and introducing all the crucial features, and then maintained it for a couple of years with the help from a small group of people.
        • dkubb 10y ago
          This is correct. It's probably hard to measure a person's total contribution to DataMapper because the gems are spread out across 20 to 30 repositories, not just dm-core. I did maintain DM for a few years, but burnt out as there wasn't enough time to keep up with the community demands and work a full time job. There were a couple of years I effectively worked 40-60 hours a week on DM and only 5-10 on work; this wasn't tenable long term and burned me out. The small dev team, of which solnic was a core member, are an amazing group and there's no way I could've maintained DM for even a fraction of the time I did without their support.
• blairanderson 10y ago
  ️
• dk8996 10y ago
  I personally can't wait for Rails to be a distant past. So many start-ups got burnt badly by using Rails -- easy to start, hard to scale, maintain, and extend. Rails is too opinionated and if your use-cases don't fit into "Rails way" your screwed.
  • deleted 10y ago
    [deleted]
  • pmontra 10y ago
    But at least it got them started and they could understand if there is a market for their product. My bet: if twitter started with Java Struts (it was 2006) they would have had to spend so much money and have needed so much time to launch that we would be using something else now. Not necessarily a system bootstrapped with Ruby, but you got the idea. > if your use-cases don't fit into "Rails way" your screwed Of course. If a startup service doesn't fit Rails, they should have picked something else. I'm not using Rails for everything.
    • dk8996 10y ago
      Startups usually try on a bunch of use-cases (features, ideas, workflows) before they gain traction or die. Your saying that startups should know all the use-cases they plan on building before they even start -- that simply impossible. Maybe your point is that startups shouldn't use Rails and its more suited for dev projects with a clear spec.
      • danenania 10y ago
        Not really. Rails is good for quickly hacking things together across a very wide range of the domains that startups usually play in, which makes it as good as anything out there when upfront productivity is the priority and you have rapidly evolving specs. The only really common startup use case it's decidedly bad at is realtime/sockets/streaming data, where Node takes its place as the hack-it-together tool of choice--at a significant productivity penalty compared to Rails. It's also, of course, pretty bad at all kinds of tasks unrelated to web development or REST apis. You wouldn't want to write machine learning algorithms or do statistical analysis in Rails, just like you wouldn't want to do 3d game development in Rails. And while you do occasionally see startups who have bolted some heavy data processing or pseudo-ML monstrosity onto their Rails apps, I've never seen anyone in the Rails community claim that was a good idea. The vanilla recommendation there is to keep your main server stack in Rails and then write services in something more appropriate for those needs.
• jon-wood 10y ago
  I'm somewhat split on the author's opinion here. I also picked up Rails back in the day (I think the first version I installed was 0.8), and I have a bit of a love/hate relationship with it. As a framework for building comventional HTML templated database backed websites I still think it's near unbeatable, especially with the addition of a few common gems. However it so often gets shoehorned into other places - API backends, rich client apps, and massive systems. Places where the Rails conventions rapidly go from everything falling into place to getting in the way and needing to be worked around, or heavily tuned. I completely agree that ActiveRecord is the core of why big Rails applications are complex to work with and often exhibit disproportionally poor performance. It doesn't lend itself well to composition, and results in data persistence being intertwined with business logic. That's fine for early prototypes, and in all honesty will get you to market quickly, but it makes extracting the concepts you discover during development into a coherant API much more complex than I'd like. These days I still use Rails for the aforementioned HTML generating web applications, but it's often acting as an API client to systems built on top of a Grape based backend, with an API built around service objects and a simple data access later.
  • keithwhor 10y ago
    Interesting you bring up the point about API backends. I'm the author of Nodal [1], with the goal of bringing the best design patterns and practices from Rails and Django to the world of Node, focused completely on building a decoupled API layer. There is no view / template logic at all. The project is very lightweight right now (benefits of being a young project with a sole full-time contributor), but I'd be interested to hear your feedback as to what you think is or isn't necessary for continued development. :) [1] http://github.com/keithwhor/nodal http://github.com/keithwhor/nodal
    • jon-wood 10y ago
      Interesting, I think I came across Nodal while evaluating options for a side project a while back. Having just taken another look the big thing that seemed to be missing was something to serialize objects to JSON, although that may be because serializing objects is so trivial on JavaScript anyway. There also didn't seem to be much documentation about the operational side of things, most glaring was nothing being said about how the scheduler actually schedules jobs and ensures they get run.
• artellectual 10y ago
  Although I may not agree with your perspective entirely, but I respect it. I think everyone has different needs, and you have your personal needs which Rails no longer satisfies, so you are moving on. Rails still solves a lot of problems for a lot of people I believe. I work as a consultant for a few companies and in some cases I see people losing time and money on what would be resolved immediately if they had just made the right call by using Rails. Good luck on your journey, and remember the rails community will always have its door open for you :). Your projects on github look exciting, I will take a look at them. Very cool stuff!
• vonklaus 10y ago
  Reminds me of Zed Shaw's critique of Rails[0] which explains many of the short comings of Rails. Zed wrote the mongrel server for rails. Assume this article is massively politically incorrect & vulgar as hell, just as a heads up. Really good read though, and does explain some of the interior politics of rails and how it evolved. [0]http://harmful.cat-v.org/software/ruby/rails/is-a-ghetto http://harmful.cat-v.org/software/ruby/rails/is-a-ghetto
  • pcwalton 10y ago
    This article is nothing like "Rails is a Ghetto". Zed's rant is 90% personal feuds, drama that is practically completely irrelevant today. The article being discussed is 90% technical critique.
    • vonklaus 10y ago
      > This article is nothing like "Rails is a Ghetto". Zed's rant is 90% personal feuds, drama that is practically completely irrelevant today. The article being discussed is 90% technical critique. True. And yet, it reminded me of that article Zed wrote, which I summarized as a vulgar critique of the internal politics of the rails community.
• clessg 10y ago
  I too have stopped using Rails. To other Rails refugees, I highly recommend the up-and-coming Phoenix Framework for the Elixir language: http://www.phoenixframework.org/ http://www.phoenixframework.org/. Simple as in simple, fast, productive, beautiful Ruby-like syntax. Favors a functional and immutable workflow over object-oriented and mutable spaghetti code.
  • jmcgough 10y ago
    Spun up my first Phoenix toy project 6 months ago and fell in love. You can really tell that a number of the core contributors are/were rails contributors, it carries over a lot of its strengths and tries to learn from its failings. Could really see Phoenix replacing Rails some day.
    • sotojuan 10y ago
      The creator of Elixir is in the Rails core team and helped (wrote?) write Rack. The creator of Phoenix built Rails apps for quite a while before finding Elixir—their experience definitely helps because they take what is good about Rails but know which "pain points" to improve on.
  • marvel_boy 10y ago
    Elixir/Phoenix is the way. Just try it, it's awesome.
  • danenania 10y ago
    How's the community and library ecosystem looking in Elixir/Phoenix? It sounds great in principle. I'd love to move from Rails toward something more functionally-inspired, but I worry that lack of libraries and google results is going to be a net productivity killer over the Rails + evolving into micro-services approach.
    • vvanders 10y ago
      Community: Very good, both Jose and Chris are outstanding examples of how you run a community. Can't comment extensively on the library ecosystem but you have access to everything from Erlang via trivial interop.
• brightball 10y ago
  The thing that has blown my mind about Elixir and Phoenix is how it gets everything right. It's the clear migration path from Rails.
  • pmontra 10y ago
    Phoenix is very Rails like in the way it makes developers work and very un-Erlang. I mean: Phoenix apps are monoliths and not loose collectives of processes with an explicit http process. Check "Phoenix is not Your Application" at http://www.elixirconf.eu/ http://www.elixirconf.eu/ It starts with the right claim but it ends with workers inside Phoenix. Instead the router and the http server should be at the same level of the other workers. Actually, they shoul be much less important, an implementation detail.
    • chrismccord 10y ago
      A new phoenix application is not a monolith. The `phoenix.new` generator generates a regular Elixir application for you that sets up a default Endpoint worker in your supervision tree, as well as a web directory to put phoenix related files (routers, controllers, etc). wrt to collective process, we add `worker(MyApp.Endpoint, [])` into your supervision tree, so we do exactly what you are wanting. Building a Phoenix application is building an Elixir application, not the other way around. Your phoenix dependency and related workers are just one component to your larger Elixir/OTP infrastructure. Note: Lance Halvorsen, who gave the "Phoenix is not your App" talk, is on the Phoenix core team. We have been pushing these ideas since the beginning and as Lance I and laid out in our ElixirConfEU talks, we're taking a stronger stance on isolation with upcoming changes to guides and phoenix resource generators.
      • askyourmother 10y ago
        I said this before: phoenix is the new Rails, and that is not a good thing. Phoenix will end up bogged down with the same great "ideas", hex will end up chock full of crap like gems. Elixir ok, phoenix not so much.
• cloudjacker 10y ago
  What I'm trying to understand is why all these coding academy students are learning ruby on rails: To make them have to go back to coding academy school in two years? So that they maintain legacy codebases and don't touch the new shiny features the experienced engineers are working on until they get their training wheels off? Because there is actual demand for ruby on rails despite all the hate and sunsetting of rails I see on HN?
  • trowawee 10y ago
    HN is a place where people who are on or fancy themselves on the bleeding edge of tech congregate. It shouldn't be surprising that the opinion of that group, with the selection pressure it experiences, is dismissive of anything that's closer to "stable, mature project" than "hot new thing".
  • mwfunk 10y ago
    You're making the mistake of assuming that what people talk about on HN/etc. is correlated with the state of the industry. Tech forums are always going to be focused on news and up-and-coming things, whether or not those up-and-coming things actually succeed at displacing the technologies they're aimed at displacing. Also, and I'd love to see actual demographics on this but I know it's impossible, while lots of posters on HN/proggit/whatever are professionals, a lot of them are also high school or college students that are still coming at it from a hobbyist perspective (i.e., focused on what's new and exciting rather than engaged in the relatively boring world of getting paid to solve other people's problems). For that matter, a lot of the professionals approach their work from a hobbyist perspective (not necessarily a good thing for their customers). I don't mean to sound like I'm down on hobbyists or students at all, just that different people care about different things, and just because most HN posters know a lot about the technologies they post about doesn't mean they know or care about the actual state of the industry (just their corner of it)(that applies to me too of course, we're all like the blind men and the elephant). https://en.wikipedia.org/wiki/Blind_men_and_an_elephant https://en.wikipedia.org/wiki/Blind_men_and_an_elephant
  • larzang 10y ago
    I can't speak for other cities because I haven't watched their job markets enough, but anecdotally in Chicago I've seen it break down mostly like this: Big companies use enterprise Java unless they're stuck with a legacy VB/ASP/Coldfusion stack, with C# less commonly. Fintech companies use a mix of C# and C++. Small companies started before ~2010 use PHP, with Rails less commonly. Small companies started after ~2010 use Rails, with hipster Java (Scala/Groovy/et al) less commonly. I can only remember offhand seeing one job ad for a company using Sinatra instead of Rails for their Ruby stack.
• tunesmith 10y ago
  Having little experience with Rails, it's the tone of that "Crazy, Heretical" article [1] that really strikes me. That tone where you're laboring to describe something that really truly does make sense when you're in the company of a bunch of people that just don't want to hear it. There's too much purism in those kinds of arguments, arguments that really are more about spectrums. It sounds like Rails is really great for learning the shallowest 40% of a wide variety of programming concerns, and a lot of web solutions for small clients aren't ever going to dip below that 40%. And as soon as you get beyond that 40%, asking questions like "but what if it doesn't make sense to do it that way?" and "what is that weird runtime bug that doesn't happen in my development environment?" and "why can't I refactor without being scared I'll introduce a weird regression bug?" then it's totally fine to be attracted to the idea of static typing, compilation, and libraries/frameworks that are more explicit. [1] http://jamesgolick.com/2010/3/14/crazy-heretical-and-awesome-the-way-i-write-rails-apps.html http://jamesgolick.com/2010/3/14/crazy-heretical-and-awesome...
• vintageseltzer 10y ago
  Is Django any better?
  • dedsm 10y ago
    The main difference is that Django does not rely on monkeypatching or magic methods, and for me the separation of concerns feels just natural in Django. When I started with Rails it felt like magic, you didn't know why things worked.
• chuhnk 10y ago
  I was quite happy to walk away from the Ruby on Rails world 4 or 5 years ago. I basically escaped before the onslaught of Rails 3.0 and what came next. I think somewhere around the adoption of coffee script I got pretty concerned. While at Google I became aware of Go and what that looked like at scale. I would highly recommend trying out Go. I think the simplicity will be a refreshing change but there will also be some familiarity coming from the Ruby/C world, can't quite pinpoint why but just feels that way. And if you're looking for frameworks, shameless plug, I'm working on this https://github.com/micro/micro https://github.com/micro/micro.
• deleted 10y ago
  [deleted]
• pmontra 10y ago
  I used Rails mostly for small or medium sized projects, one or two developers teams, all of us freelancers. It's the perfect tool for this kind of work. We can deliver quickly, send invoices, move on to something else or come back later to add features. Do projects get complicated? Yes, some of then. Mainly because most customers pay for features and not for refactoring or design, which they don't understand (remember, no in house technical staff). Try to sell them a new page with attached the price of a major refactoring... good luck with that. So sometimes features get kludged together because of budget constraints. I have projects with suboptimal UX (understatement) because they rationally decide to make tradeoffs between usability and costs. It's their privilege. I bet this would happen with any language or framework. Your customers could be more long sighted than mines, I hope they are. So, would I move away from Ruby and from Rails? Yes, when customers won't like starting a project with Rails anymore. This means that other tools don't have to cost them more. Do I care about Rails architectural shortcomings? A little, but I appreciate its shortcuts more. They work well in my projects.
  • erikpukinskis 10y ago
    This is my takeaway from Rails. Good default for your 1.0. Frankly, I would probably use Rails even if I was starting a startup. It's easy to hire, easy to talk about. Heck you will often find graphic designers who have played with Rails. Choosing Rails will definitely lead to problems in the long run, but at least they are well understood problems. You're going to do an in-flight replacement of your 1.0 eventually anyway. You just need one grayhair on the team to steer the younglings away from the worst abuses and you'll have a stable, if clunky, platform to build on. It's the definition of mitigating risk. Java and C# are of course equally boring, but I think the fact that Rails is culturally open source provides a huge benefit over them. JavaScript, Go, Haskell, etc are arguably better if you really understand them, but they're research projects. Lots of great pieces of code, but the story of how to use them together is still being written. I would use one of them if my intention was to hire slow and keep my dev team fewer than ~30 people in the long term.
    • fishnchips 10y ago
      Did you just call JavaScript a research project? I seriously hope you meant Node.
• adamors 10y ago
  I have 2 main concerns going forward with any Rails alternative (ie. Trailblazer and the like): community support and jobs. I have no idea how big the community behind each library/framework is and honestly I don't have the time to properly test-drive multiple and research the health of their respective ecosystems. With Rails I can rely on 10-15 gems that can help me with 80% of my projects. Perhaps I overestimate my reliance on 3rd party code, but that leaves me with my second issue. Ruby jobs are de facto Rails jobs. I have weekly email newsletters set up for Ruby jobs and in the last 3+ years only a handful were Sinatra/Rack based. It would be interesting to see a reliable source of non-Rails Ruby jobs out there.
  • chucksmash 10y ago
    At some point you'll be in a position to decide which tech stack a company should use. I suspect you'll find there's a bit of a chicken and egg problem here - you'll want access to the largest pool of good candidates possible so you will also be disincentived from straying from the well worn path. Even if you grant that good programmers can pick up new languages or frameworks easily (which I'm not entirely convinced of - there is a wide gulf between "can follow the tutorial" and "successfully used in anger"), you'll incur a penalty in velocity while all your new hires learn Framework X. Anecdotal example of the perils of going off the beaten path: I often see a job advert on StackO for a company looking for Python/Django guys. When you click through to the job description, they are actually using Perl/Dancer. Not that there's anything wrong with that, but for me personally that's a deal breaker. I have no interest in investing the time to become proficient on that particular stack.
    • pessimizer 10y ago
      > Even if you grant that good programmers can pick up new languages or frameworks easily (which I'm not entirely convinced of - there is a wide gulf between "can follow the tutorial" and "successfully used in anger"), you'll incur a penalty in velocity while all your new hires learn Framework X. I think the question is more "Does what we're doing require good programmers, or can we get by with shitty ones?" More often than not, you're not doing anything special, and you want to pick a platform that the cheapest, most common programmers out there can add features in a non-disastrous amount of time (different depending on industry + your competition), and not generate enough technical debt to collapse everything before the next rewrite/upgrade cycle.
• programminggeek 10y ago
  The elves are leaving Middle Earth.
  • gfgjmfgjmgh 10y ago
    ...but these are the same people who made what Rails what it is today. What is concerning is their occupation of top seats on other hot projects (Rust, Elixir etc.).
• unclebucknasty 10y ago
  A few years ago if you said anything negative about Rails, you were either pure evil or unbearably stupid; or both. If you didn't fully embrace tableless design with CSS, despite the latter's glaring defeciencies for that task, it was the same treatment. I also recall great pressure to adopt EJB with its deeply flawed architecture, etc. I could go on, but the point is that there seems to come a time when all of these things face a moment of truth, wherein sober minds feel a little freer to speak aloud on their shortcomings. This frequently snowballs into all out backlash against the tech in favor of The Latest Shiny Thing. The enforcers of what's hip and smart for everyone now move on to browbeating Developer Land with the new tech, and we all allow it to happen again. Why do we keep repeating this process when we've all seen the movie so many times?
  • tariqali34 10y ago
    Reminds me of "The programming language lifecycle"[1] (written in 2006), which essentially implies that the reason programmers continually search for new languages is simply out of a desire to 'distinguish' themselves from their peers, and have little to do with the actual merits of the languages in question. [1]https://quoderat.megginson.com/2006/03/06/programming-languages-of-distinction/ https://quoderat.megginson.com/2006/03/06/programming-langua...
• cynusx 10y ago
  I think rails has plateaud in terms of improvements. The article is pointing out the tight coupling of activerecord with business logic which is the consequence of a belief that I strongly disagree with in the rails community. 'fat models, skinny controllers' has caused a lot of mayhem as minor database updates (or update intention) triggers a cascade of actions. This behaviour is counter to the model2 MVC implementation that rails is using as controllers should really be in charge of coordinating (helped by specialized classes if need be). The author correctly points out that the way rails deals with views is painful however rails views are not tied to the model at all, they are tied to controllers and this can be modified if need be. I personally maintain an approach of tying dedicated ruby classes to view files (e.g. SidebarComponent) and compose the view in the controller using a chain of these classes. This approach is much more object-oriented and avoids the weird pass-along view-hierarchies that many rails projects have. There are much things to improve about rails but the project doesn't seem to absorb more object-oriented approaches over time and is tilted heavily towards DSL's for everything and doesn't value creating a more specialized class hierarchy to encapsulate more complexity. I don't see a need to move away from Rails yet though as you can easily work inside the framework in a more Object-oriented approach. I guess you can characterize my approach as skinny models, skinny controllers, fat business logic objects and every partial is powered by a view object.
  • askyourmother 10y ago
    Improvements are a strong word, I thought they were still playing whack a mole on the numerous Rails RCE security issues.
• thejerz 10y ago
  Quite a huffy, histrionic (self-described) rant. My advice to OP is to take a Xanax and relax. Rails is just one tool -- like all tools, it excels in some areas and is deficient in others. If Rails isn't the right tool for the job, use something else. If you have a better idea, write some OSS. Personally, I've been using Rails for 9+ years, but I also use vanilla Ruby, Rack, Sinatra, Java, vanilla SQL, Go, and C when appropriate. If you only use Rails, You're Gonna Have A Bad Time™.
  • angersock 10y ago
    Thaank you for that well-reasoned rebuttal! I especially like your deep insights into the different issues the author is having.
• Locke 10y ago
  Nostalgia warning: I also grew frustrated with Rails / ActiveRecord and jumped to Merb / DataMapper with excitement. Perhaps it will sound like a small thing, but I remember feeling especially frustrated that every ActiveRecord model became such via inheritance. This drove me crazy: class User < ActiveRecord::Base Why should my `User` extend from `ActiveRecord::Base`? Is a User of my app also an ActiveRecord::Base? What is an ActiveRecord::Base anyway? So, when DataMapper came along and favored composition over inheritance I was sold. However, my experience with DataMapper was that it didn't have the stability of ActiveRecord, nor did it reach feature parity. And, then Rails killed Merb. At the time I thought it was a tragedy. The competition Merb provided did improve Rails, it would have been nice if that competition had been longer term, though. On the flipside, I wonder if there would have been enough community to support two large Ruby web frameworks. In the end I made peace with Rails and ActiveRecord (and, believe it or not, even ActiveSupport!). I don't have great love for Rails, but it is a powerful tool, so I accept it for what it is. That said, I think the author's criticisms are well stated and hopefully there will be some influence on the future direction of Rails, etc, and the way devs approach Rails.
  • jsnk 10y ago
    I don't get your complaint about "class User < ActiveRecord::Base". If you don't want to use ActiveRecord::Base methods, why don't you just declare a class without it? You can just do "class User" you know.
    • Goopplesoft 10y ago
      I don't ruby but I'm guessing OP prefers the "include" that DataMapper uses since inheritance 'feels' weird ... a weak point nevertheless.
      • solnic 10y ago
        `include` is also inheritance, multiple inheritance. I try to avoid inheritance and prefer composition. It is very simple in ruby and very powerful.
      • deleted 10y ago
• funkaster 10y ago
  I have the same sentiment with Rails. I built a big warehouse/delivery system (routing, etc) on 2006 with Rails 1.2.3. still being used up to this day. After that, I never looked at rails again. All of my web apps small and medium were made with Sinatra. After reading this article, I'll give a look to hanami.
• Nemant 10y ago
  What is a good alternative?
  • biokoda 10y ago
    As mentioned multiple times in this thread: Elixir and the phoenix framework
  • phonon 10y ago
    Django.
    • antod 10y ago
      Although the writer was a fan of DataMapper. I imagine the Pyramid/SQLAlchemy combo might appeal more to them.
  • thawab 10y ago
    There is no good alternative without specifying the use case. In the main article he is looking into Elixir, Clojure and Haskell, because it fits what his working on.
  • robto 10y ago
    He mentions it at the end, but I'd strongly agree that Clojure addresses the issues he mentions. I see a lot of discussion in this thread about Elixir and Phoenix, but I'd take another look at Clojure. It's got a strong, friendly ecosystem that encourages small, composable libraries. For every level of your application, there's competition - http servers, sql abstractions, front end libraries. And there's great resources to help you choose what works best for your use case - the Luminus docs, books, blogs, and several active forums for discussion with library owners and just regular developers. Couple that with a community that really took Rich Hickey's "Simple made easy" talk to heart and the default immutability and functional paradigm and the abstractions that Clojure itself has to offer, not to mention the performance the JVM brings to the table, and I think it's a great language to hang your hat on in the long haul.
    • 10y ago
• VLM 10y ago
  Sounds like he wants Arachne. Which isn't written yet. He even mentions learning Clojure. Linked article stops just short of mentioning it, but there are some themes that are common between the linked article and the story of what Arachne should fix. http://arachne-framework.org/ http://arachne-framework.org/ The concept of the zeitgeist is interesting. A lot of general dislike of Rails is in the air and the only question seems to be what the replacement will be, not if there will be a replacement. Naturally the ruby guy thinks it'll be a new OO ruby framework which has always done the impossible before and the Clojure people think it'll be the usual immutable functional magic which has always done the impossible before. Best plan for the future is wish them all luck and wait and see. I don't see any other useful strategy at this instant? My money is quite literally on the Clojure guys, I was one of the backers of the Arachne kickstarter, but best of luck to Hanami and rom.rb and all the new wave ruby stuff. One of you revolutionaries had better succeed, or else... Some of it may be the natural result of success and age. A near decade of continually having to revamp my rails code "because the guys at hulu really need it" or "this is very helpful for github" is inevitably going to eventually make me say (if you'll excuse the profanity) F them I'm sick of rails and authoritarian monoculture in general and hulu is very nice but it can just go help itself, I have work to do that isn't "I have to chase latest fad that someone else needs". It may be a natural state for the lifespan of a framework to enter a stage where staying on the bus is more expensive than hopping off, maybe even hopping off anywhere. I tried some Play framework projects and I felt the sirens pull of static typing, but, after a few years, unless you keep up with changes, the technical debt just accumulates each framework revision until I'm sick of seeing releases instead of pumped. I'm talking about projects that last many years not a semester or so. I'm not sure the chronological nut has been cracked of heres a magic solution for long lived projects. Assuming there is a magic solution. Perl CGI I suppose (only slightly tongue in cheek kidding)
• deleted 10y ago
  [deleted]
• vinceguidry 10y ago
  > Now, this line of code is not simple, it’s easy to write it, but the code is extremely complicated under the hood because: Every time I hear someone complain about Rails, I ask myself if this person is really just complaining about how complex web dev is. I've never seen a complaint that passed this smell test. Yes, Rails abstracts over a veritable shit-ton of complicated domains. The problem is, that complexity isn't going to go away if you decide not to use those abstractions. Every single one of that laundry-list of things that ActiveRecord::Base.create does will have to be implemented again, by you, badly, if you choose to roll your own. It boggles my mind why developers don't take the web seriously as a domain, like it's not real coding or something. It's the worst instance of bike-shedding I've ever seen. Rails isn't perfect, by any means. But Rails is not a black box, it's all free software. You are more than free to re-implement anything Rails does yourself and release it as a gem. Modularity and flexibility are built right in. It seems incredibly odd to leave Rails over this. For what, Java? Unbelievable.
  • jamra 10y ago
    I'm not a rails dev, but I believe that you are misconstruing his argument. It is not about inevitable complexity, but about the ownership of that complexity. If you are able to control the side effects part of development, you can control how it scales and debug it much more easily.
    • mooreds 10y ago
      > It is not about inevitable complexity, but about the ownership of that complexity. I've been there, done that--was part of a team that owned a java application that grew over a decade (and eventually ran the team). A year or so after I left, they retired the application. Why? Because we owned all the complexity and couldn't support it. Maybe that was my failing. Maybe the team's failing. But I don't think that having control of how the whole codebase fits together means you necessarily have more control over complexity.
      • ethbro 10y ago
        Those who trade for buried complexity are doomed to start digging whenever they discover an edge case. Maybe they never need to do that, in which case that's a bargain. But I tend to think that any old enough codebase continually accrues edge cases that must be solved.
• kazinator 10y ago
  > First of all, it worries me that many people react like that. We’re discussing a tool, not a person, no need to get emotional. Laughably, no. Code is written by people; it's essentially a set of ideas that execute and do things in accordance with the vision of the creators. The creators poured themselves into the tool. Code is an extension of the self. (If it isn't, it should be; people take the best responsibility for code when it's like that, and it's probably the main essence that separates OSS from most proprietary work. People don't fully invest themselves into creations that can completely disappear out of their lives forever upon the next organization restructuring.)
• themgt 10y ago
  I've also seen the writing on the wall for leaving Rails/Ruby. I think a lot is down to Ruby the language simply not being well-suited for an increasingly multi-core/concurrent future. That said, a more reasonable approach is to begin transitioning a few projects at a time, and make sure you've solidified on your new tools of choice before chucking the old ones. I remember a few years ago I teased with ditching ruby for node.js. I'm glad I dipped my toes in the water and waited for Elixir.
• yodasays 10y ago
  Explicit is better than implicit.
• nine_k 10y ago
  This article formulates well why I strongly prefer libraries to frameworks. A framework dictates you the structure of what you are doing. Libraries can be combined, replaced, and used in various ways, fitting more the task at hand than the mist common case.
• fishnchips 10y ago
  I'm not surprised by this development. I'm familiar with Piotr's code and it's hard to miss the fact that he's writing Ruby as if it was a functional language. Sharing inspiration between languages and paradigms is an awesome thing but if you're going to try hard writing Ruby like if you wrote Haskell you'd probably be much better off writing Haskell in the first place. Back to the original article I think it says more about Piotr's personal path as a developer than Rails and Ruby community at large.
  • solnic 10y ago
    That's not true, although there's a lot I took from FP. Like avoiding mutable state, and functional composition for data transformations. This doesn't change the fact my code is OO - I use objects, composition, decoration, delegation and many other OO techniques, and in general try to avoid heavy inheritance-based patterns. I can understand how people may think I'm trying to use ruby in an awkward way, but this is really not the case.
    • fishnchips 10y ago
      I find your Ruby code super awkward. Like you're trying to turn it into a language that it is not. At least it is not in my book but then again I'm just some random dude on the internet, a sample of one ;)
• douchescript 10y ago
  Oh no, the Merb heresy comes back to haunt. No merb was not better, it was just different and sucked in some different ways.
• douchescript 10y ago
  The things that suck in rails are the views, the asset pipeline and the stupid helper methods for routes that are so complicated for nested routes it's a joke. The database part is actually the good part if you do it right.
• Ericson2314 10y ago
  Now I never use dynamic languages and never thought Rails was a good idea. But I'm glad I read as through as the "Convenience-Oriented Design" and the simple vs easy quote. I've seen many designs which have sacrificed consistency or orthogonality to make the common case as tiny as possible, and struggled to articulate what was wrong when I was counter with "how simple the tool is to use". Hopefully this will give me some better language.
  • Ericson2314 10y ago
    I feel like the very world "simple" is part of the problem. Orthogonality/Consistency is much more important. Also don't treat odd use-cases as gratuitous features to be someday supports. No, a use-case is not a feature, but that hacks that will be added to accommodate those are. And features are bad: "[things] should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary."
• zinssmeister 10y ago
  Rails is great. And of course it isn't and will never be perfect. Obviously the author would love some alternative frameworks, mainly so he can use some more and some less exotic code patterns. Maybe after almost a decade of writing CRUD apps in Rails he is a bit bored? I can't blame him and seeing the Ruby community so focused on basically one framework is a tiny bit sad. So I definitely see where he is coming from with all this, but truth be told it was never Rails' indent to be a precision instrument. It has been a reliable framework that makes a lot of Developers very happy. A great reliable car for the masses so to speak. But not a Ferrari.
• elliotlarson 10y ago
  I've been developing apps with Rails since it was announced. It's been an amazing tool/toolchain, providing a very useful level of abstraction that allows rapid development. Recently, I've been doing a lot of Go (Golang) development. For me, it's sort of the anti-Ruby-Rails. I really like the fact that it requires me to "roll my own" in so many situations. I need to understand what's happening under the hood to make things work. But, the abstraction/magic of Rails is useful. Speed to market with trustable, battle tested magic is a profitable proposition. I want to introduce Golang into my current project, but I haven't quite found the right place for it yet. Rails makes it so much easier and faster to add functionality at our scale.
  • pdimitar 10y ago
    It might be a better sell if you try to introduce Elixir, and I am guessing its Phoenix library/framework as well. I've tinkered a bit with Golang and I love it but IMO it's too much extra work in the Web development part. It's exciting and very educational to pop the hood and understand how many things fit together, especially if you're coming from Rails, but you should be aware that after a while the novelty wears off and sooner or later you'll start looking for the quicker paths to introduce trivial Web cruft. I am yet to experiment with Elixir + Phoenix but the community feedback so far has been fantastic.
• soheil 10y ago
  > rather than hitting F5. Just saying. QED. My hypothesis was confirmed, up to this point I was pretty sure he's been living under a rock possibly for decades complaining about how hard programming can sometimes be until I realized he is an IE user. Show us a better solution without sacrificing everything that rails has given us and maybe we will listen.
  • ThisIs_MyName 10y ago
    What does IE have to to do with anything? F5 and ctrl/cmd+r work in all browsers.
• matt4077 10y ago
  If any of the frameworks glorified on HN were subject to the same scrutiny as Rails, Github would need a suicide hotline. I've recently had the pleasure of working on a new, medium-sized node/react project. Now I was new to a lot of the technology, but I've learned a few and would think I have some experience. It probably took me a week to get webpack running the way I wanted. The documentation is an atrocious mix of stuff that is outdated (older than 6 months) and stuff that's too new (webpack 2.0) without any indication as to the validity. There're six different ways to get hot reloading/replacement to work, with similar problems. The configuration's syntax is heavily influenced by brainfuck with a /\w/[{\[]/s thrown in for good measure. As a soothing measure, webpack doesn't complain about anything but parse errors with the configuration. The version I was using came with 12 different options to render source maps, none of which worked in chrome (since fixed). And that's just the linker. I actually had presets to search for, i. e. ["express.js" from:<date-of-last-stable-release> to:<date-of-following-alpha/beta-release>]. node_modules once managed to consume 4TB of hd space (someone managed to create a circular dependency) and even in regular use gets to the point where I'm looking for the elasticsearch plugin for ls *<x>. If you have checkouts of several versions or projects, each one will have it's own version of left_pad & friends at around 230MB (just checked with a clean install of mxstbr/react-boilerplate) with no way of deduplication. I enjoy playing with new technology (currently elm & swift) but I know that it's time "joyfully wasted" right now and don't try to justify it. There's no amount of type-safety bugs that could cost as much time as a new framework's kinks.
  • BurningFrog 10y ago
    The most used frameworks are always the most complained about. It's an easy mistake to think that means they're the worst.
    • rtpg 10y ago
      While that's true, why don't we see this sort of stuff with Django or Flask? Of course we see people complain about these tools, but my impression is that people who end up leaving those communities are rarely because of community issues (more like "I'm going to do some Go instead"-style things) Surely something is different. It's not like Django is unused...
• matt4077 10y ago
  I can't grasp the hostile attitude towards rails at HN. Even agreeing with (some) of the criticism, I'm deeply thankful to Rails, DHH and everyone else involved. Because before rails 1.0, I worked in php. Many people may actually be too young to remember, but the jump from php and anything else that was state-of-the-art at the time to rails was without doubt the biggest leap web development ever took. The most meaningful advances actually weren't just technical but social. It would've been possible to write an excellent webapp before rails, but just about nobody ever did. The opinionated nature of Rails many are complaining about today was a revolution because it taught everyone using it good architecture. You can nitpick about any one of those opinions, sure. But back then it was common to join a project with >100kloc with directories containing password.php, passwprds.php, pass.v3-old.inc, large_image.head.2002-v1.jpg & employees.xls. The quality of almost any rails project I have seen is, in comparison, excellent. It'd say a new team member on a rails project was productive in less than a third of the time it took in non-rails projects at the time. So, to anyone complaining: I'm pretty sure that looking into any of your strongest held believes on web dev, you'll discover that rails had significant influence in creating them in the first place. To do something like that, pretty much as just one guy on the beginning, should afford someone a certain amount of respect.
  • ascendantlogic 10y ago
    This is my initial response as well. I came from the land of Java web dev and Rails was the best thing to ever happen. But it's been 10+ years since it really took the world by storm and things have changed. This "I will never use Rails again" saber rattling is just linkbait crap but well reasoned critiques of tools and patterns are always a good thing.
  • sanderjd 10y ago
    I whole-heartedly agree with everything you said, but I also felt stifled and stymied by Rails for years, and am happy to be doing other things at the moment. It is possible (and I think fairly common) to both deeply appreciate Rails while finding fault with it, and to respect the validity of its approach while preferring other tools.
  • mattmcknight 10y ago
• Doctor_Fegg 10y ago
  I read this with a lot of head-nodding but also a great sense of sadness. I agree with pretty much every brickbat hurled at Rails in this article, except for one thing: > Both projects were ultimately killed by Rails as Merb was “merged” into Rails, what turned out to be a major Rails refactor for its 3.0 version. DataMapper lost its community attention and without much support, it never evolved as it could if Merb was not “merged” into Rails. DataMapper wasn't killed by Rails absorbing Merb. DataMapper was killed by "Things You Should Never Do, Part I": > "They did it by making the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch." (http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html) DataMapper 2 was insanely ambitious, and true enough, it was never finished. A core subset was salvaged as ROM (Ruby Object Mapper), which has a certain artisan purity but is a long way from hitting the readable/understandable sweet spot that DataMapper originally had. But DataMapper 1 was abandoned by its developers. Pull requests languished and there weren't even any maintenance releases. I idled in the DataMapper IRC channel for a while and pretty much every query was answered with "don't bother, wait for DM 2". Unsurprisingly, people switched to ActiveRecord instead. I still use DataMapper. I use it in my own framework, which is plaintively simple compared to Rails and no doubt makes a load of mistakes, but they're the mistakes I've chosen to make (which, as per DHH, is "opinionated" software). I would love DataMapper to be, if not revived, at least slightly maintained. There is life outside Rails, but you have to want it.
  • twic 10y ago
    It astounds me that people are still citing that Spolsky article when its central example of what not to do is the writing of Firefox, which turned out to be a huge success. Not that rewriting from scratch is always a good move. Evidently, DataMapper proves that!
    • WillPostForFood 10y ago
      The Spolsky article is about Netscape 6. That rewrite took 3 years, during which time (1997-2000) they lost ~80% of their users to competing browsers? It may have been amazing software, but not a success. Firefox/Netscape 8 was 2005ish.
• orthoganol 10y ago
  I can't take his opinions too seriously because his 3 central gripes, which he wrote extensively about, boil down to: 1) Too much complexity is hidden by simple interfaces Those simple interfaces make programming enjoyable and don't break, so... 2) Your app logic is going to be too tightly coupled to core Rails features like AR, helpers, controllers ("your app is Rails") Yes, you are in fact using the features of Rails when you use Rails. Is this actually a problem? 3) ActiveSupport. "No actual solutions, no solid abstractions, just nasty workarounds" ActiveSupport has saved me bajillions of hours and never broke anything for clients. I wasn't aware it was such a flawed library, if it is? Rails is maximized for developer happiness by, among other things, making things simple (yes, which to a large extent means hiding complexity), giving you a bunch of Omikase core features that you can in fact use, and gives you a lot of sugary methods for handling things that are tedious. I understand people wanting to try other things and leave Rails, no problem with that, but his stated reasons reveal a lot more about him than about Rails.
  • BinaryIdiot 10y ago
    > Those simple interfaces make programming enjoyable and don't break, so... Speak for yourself. The last time I worked on a rails project this was the part I most disliked. It made debugging annoying, I never knew what each line of code was doing in totality and and I had to practically live in the documentation to figure out the side affects of everything I did. This is versus most other frameworks I've used for web services where most things are explicit enough that, even if you don't know the language well / at all, you can still figure out what most of everything does. Jumping into a rails project without knowing ruby and how rails works? Good luck figuring that out without studying the documentation.
  • phamilton 10y ago
    > his stated reasons reveal a lot more about him than about Rails. They reveal that he has tried to build sotware that didn't fit the Rails approach. They reveal that he has been frustrated trying to build tools that allow him to stray from the standard Rails approach without abandoning Rails completely. They reveal he's tired of the lack of success on that front and is going to just move on.
• mark_l_watson 10y ago
  I usually find "I am stop using XXX" type articles to be a bit negative. That said, I stopped using Rails years ago myself, so the linked article resonates with me. My goto web frameworks are Ruby+Sintra and Clojure+ring+compojure. Sometimes I also use meteor.js but it is more like Rails in that it is a complete package of everything you are likely to need, pre-configured.
• hhw3h 10y ago
  Is it uncommon to use other patterns within rails like service objects? I like using Draper, Pundit, and other gems which provide decorator and policy objects. I prefer to not use Helpers and AR callbacks (generally Concerns too) as I don’t think they encourage good OO even though they are officially part of rails. Ultimately it comes down to what your goal is. Is it to deliver some business value fast to end users? Build a new product with a small team? Then I think rails is a great tool to achieve that.
• a2800276 10y ago
  What I don't understand is why people feel the need to proclaim that they're leaving xyz? Why not just focus on the positive and focus your energy on the new stuff you'll be doing. It sounds like someone who just broke up and keeps claiming they're totally over it but just can't stop talking about what a bitch their ex is. If you're planning to do haskell, elixir, clojure and scala, write about that.
  • Roboprog 10y ago
    Oh, God, you're right. Sounds like my daughter on Facebook :-) "That David is such an asshole. I never want to see him again..." (with apologies to DHH, whom I find amusing, even if he is a bit "coarse")
  • kazinator 10y ago
    > What I don't understand is why people feel the need to proclaim that they're leaving xyz? Often, such proclamations are not noteworthy. However, if the speaker has been a long time user of xyz and a contributor to it, then the proclamation is noteworthy.
  • jordan0day 10y ago
    There's a small bit of irony here in that there was a rash of "Why I'm leaving X for Rails" posts between 2008 and 2012 or so.
    • rhapsodic 10y ago
      Oh yes. I remember it well.
• george_soros 10y ago
  His beef should in general be with OO in ruby. Rails is just a consequence of that.
• kyledrake 10y ago
  I'm not going to pretend it's better than Rails, but I implement most of my projects as Sinatra psuedo-frameworks, with Sequel for the ORM. Sequel is a solid ORM that has a reputation of being stable and reliable. Sinatra is just simple (vs easy sometimes) and I like the way it integrates routing directly. It's good enough to power Neocities anyways, and I've baked in some of the niceties you'd expect from a larger framework (such as testing).
  • bdcravens 10y ago
    I've been doing a lot of the same recently. Super light in terms of code and very readable. When appropriate, easy to gemify and then mount in a Rails app
  • cyberferret 10y ago
    I wonder if the author of the article above has looked into Sinatra? It seems to be the solution he is looking for, in a sense. I have used Padrino (http://www.padrinorb.com http://www.padrinorb.com) a lot recently, which is really a framework on top of Sinatra that make things like testing, ORMs and renderers easier to integrate into a raw Sinatra base. I especially love that I can use 95% of gems written for Rails in it - about the only ones I can't use are the ActiveRecord specific ones. (Note: I use DataMapper in most of my projects, but looking at Sequel as the ORM for my current app).
• im_down_w_otp 10y ago
  Secondly, avoiding mutable state is a general, good advice, which you can apply in your Ruby code. Ditching global state and isolating it when you can’t avoid is also a really good general advice. As an Erlang programmer I agree with the general sentiment here, but wouldn't doing this in Ruby really lean hard on one of the pathologically nasty Ruby runtime issues? Which is that it doesn't release memory back to the system? When every new operation on a data-structure starts by producing a copy of the previous version it seems like you'd really want a runtime which is efficient and intelligent about how it manages memory? Unless that idiosyncrasy of Ruby has changed since I last used it several years ago. In which case. Nevermind. :-)
  • pdimitar 10y ago
    Ruby's MRI never returns RAM to the kernel, yes. But if you use immutable data structures and release them relatively quickly, the GC will have much easier time releasing their memory back to the pool that MRI is using for allocating new ones. So the inevitable RAM bloat that MRI accumulates over time is still there, but is slowed down. As far as my not-so-big experience with them goes, the immutability programming techniques in Ruby actually help a lot with its sticky RAM problem. Complex object hierarchies of mutable objects and references to them are a nightmare for the GC. Having structures/objects that are used and [quickly] thrown away without (or rarely) being attached to complex object graphs is making the GC work more reliably, and faster.
• dorianm 10y ago
  TLDR: People don't do what I want them to do. They don't think the way I want them to think. And my way of thinking is way better than theirs.
  • cwyers 10y ago
    Alternatively: Rails doesn’t believe in doing anything that would make it anything resembling modular so people who don't agree on everything can still work together easily.
• deleted 10y ago
  [deleted]
• captain_crabs 10y ago
  I'm a full-time Rails developer, and I've run into the exact pains that he's talking about. By and large, I've fought with ridiculous things as projects grew, and run into extremely 'magical' bugs. It's frustrating as hell. But I've found the way through them is actually to lean into ActiveRecord, not away from it. When it really boils down to it, ActiveRecord is a perfect pattern to deal with the "submit a form, validate it, run some logic, return the results" round-trip that's the core experience of web applications. Do you have validated data you need to do really complex logic on? Sweet. Send it on over to some PORO's. Have a complex query that isn't easy to cache? Nice! ActiveRecord will get out of your way. What's really hard is figuring out how to frame the problem in a way that makes Rails a great solution for it. This part is really really hard, I think in a lot of ways akin to art (and by 'art' I don't mean some deeper honor or aesthetic - just that there's no guidance), since the principles and patterns actually come from your domain and not somewhere else. And the developers I know who really hate the way Rails does something, especially ActiveRecord, are huge on applying patterns. When I've taken the time to think through how to structure, really deeply, the applications are a pleasure to change and modify even when I come back much later. And for me, the proof is in the pudding: those aforementioned other developers who hate ActiveRecord don't complain! They'll see it, give a small 'huh,' then go do what they need to do just fine. But when I don't, they turn into the twisted spaghetti nightmares. I see a massive sub-current of dissatisfaction with Rails, and I think the reason for this is just a subtle but markedly different priority of thought. I can't articulate it yet, I just know what it looks like when I see it. Anyway, I love Rails as it is now. Soon I hope I can deploy a single application across web and mobile platforms natively, along with supporting them all, as one guy. That's insane. Really like this blog post because I've got some things I'd like to be able to do with the ActiveRecord API, but I'm not really sure how. I don't know why the thought never occurred to me to just ask!
• dedsm 10y ago
  I've always said Rails is good for short-lived build and forget projects, it's too "magic" for my taste. I can't imagine what it must feel like to receive a mid-to-large sized Rails project to maintain.
  • pdimitar 10y ago
    You don't want to know. I inherited and am currently tech-leading a large e-commerce project powering an e-shop doing $10k+ sales a day. Even a small bugfix or a very minor UI addition is taking days because outdated tests are breaking, because there are dozens of tight integrations directly in the code, because there's zero separation of concerns, and awfully inefficient ActiveRecord queries everywhere. Making a cart checkout with ONE item takes 50+ ActiveRecord queries. Yep... It is extremely challenging and very educational for me, and I appreciate the experience. I've always been a fan of repairing and improving things -- but truth be told, it gets tiresome and annoying VERY quickly. I am currently working hard to stabilize the entire process of small refactorings for the sake of the new features/bugfixes, streamlining deployment, making full separate QA/Staging environment (yes, even that wasn't addressed by the previous team) so we can test with confidence and without fearing we'll break Prod, and to reduce the 3rd party API dependencies -- right now they are 20+. I am hopeful that after I stabilize the project and make the process of introducing new code easier and quicker, I could then make the case for gradual exodus to Elixir/Phoenix. Realistically, I am not seeing that Rails abomination I inherited to be a sustainable job for even one year. Inevitably I'll burn out, the customers will lose patience, and my employer will be unhappy both with me and the customers. Not cool for anyone involved. So I'll try to gradually run away from Rails. As pointed by numerous smart people here, it's suited for medium-sized projects at best. Even Sinatra/Padrino and 50+ attached libraries would have been much easier to maintain.
    • AnthraxAlex 10y ago
      Ive got a similar problem, dealing with a rails app i inhereted that collects telemetry data from thousands of remote units traveling out in the field. Basically there is no separation at all of active record and buisness logic. You end up with connections to ftp servers and other application layer adapters down in active record models. With all of the application layer in the AR models its only a matter of time before the developers end up weaveing a thick carpet of spaghetti dependency through everything. On top of that changing the database becomes a royal nightmare because the database is what defines this AR model that all of your buisness logic and application layer spaghetti dependency relies on. The databases usually end up full of garbage because without complex validations and lots and lots of tests which by the way were never written ruby and rails will dump any trash into your db whenever. So you end up with columns with like 10 variations of the definition of NULL or FALSE. Usually around this point your app just slips into a state of quantum uncertainty. It essentially ceases to behave deterministically at least when viewed from within the bounds of human perception. Its hard for experienced developers to bend rails in away so that things don't become overly dependent on each other and neigh impossible for average or beginner rails developers to manage. Im just really not impressed with rails at all especially coming off of 6 years of development time on huge enterprise apps written with the c# .net libraries. I mean really they are light years ahead using IOC dependency injection for injecting service apis into controllers while using mapping patterns for keeping buisness and database logic separate. Its the only way to break up large apps and keep them sane and maintainable. Additionally static typing is the only thing that keeps things sane in really large applications doing complex business logic through many layers of interfaces.
• kfir 10y ago
  Without being negative anyone else found this statement a bit strange - "as my bachelor thesis was about Rails" * I am not aware of any CS program that do thesis at a bachelor level. * It is hard for me to imagine getting approval for doing a thesis on "Rails", it is mostly a CRUD web framework.
  • geebee 10y ago
    I found it a bit strange, but not that strange. First, a "thesis" isn't too uncommon at the BA level. I majored in math at UCSC where this is an option. Can't say if this is something people do in CS, but I wouldn't be surprised. http://www.math.ucsc.edu/undergraduate/compreq.html http://www.math.ucsc.edu/undergraduate/compreq.html I could see how someone might find material in the emergence of Rails in web programming for a thesis at the undergraduate level.
• pm24601 10y ago
  Another point that was subtly made, but needs highlighting. If you are programming in ruby you are ONLY doing a front facing webapp. There are lots of servers out there that run headless. The ruby ecosystem is completely dominated and controlled by rails. As a result, ORM mappings and gems are completely focused on a web-response centric world. As monolithic ruby apps are broken into microservices, ruby as a language will also be abandoned for those microservice back-ends - simply because the ruby ecosystem has only one way of viewing the world.
• jakelarkin 10y ago
  my two cents on Rails (as someone who's worked with Rails/Ruby, Node, Scala, Golang in some depth) - ORM is bad at any sort of scale/complexity. - Net IO that looks like property access makes it too easy for devs to do bad things, N+1 queries etc. - ORM abstraction is not helpful when you know the exact efficient query you want. - ActiveRecord Models + the Ruby module system encourage OO bloat. - ActiveRecord database drivers are too numerous and not well implemented. Default schema generation includes many SQL anti-patterns. - ActiveRecord has too many public interfaces, too much meta-programming. Hard to understand scope, Hard to analyze and improve performance. - ActiveSupport monkey patches too much of Ruby. Need an very deep understanding of language to understand what's going on at a non-superficial level. - Rails/Ruby community places too much emphasis on "clever" DSLs / APIs - If your stack/framework choices limited to dynamic languages, Rails is a lot less efficient than Node and for web apps you need JS developers anyway.
  • est 10y ago
    > - ORM is bad at any sort of scale/complexity. ORM is good, as long as you use only SQL in your backend.
• Bombthecat 10y ago
  I like rails. A lot. The syntax is amazing. Period. If you can get a gem or get what you need from rails. It is simply close to amazing. But dare you. You just go down one simple level. (first level is what you get with rails and for example extending active record.) it becomes a horrible mess of dependencies and magic / structures. I never found a framework so hard to modify. ( for example writing your own multi category / multi tag gem) That's when i stopped web dev. It was just mind boggling. This is several years ago. I think around version 3 or even 2? And every version broke the active record stuff... I really thought rails would catch on in germany. But if you look on indeed there are literally like five jobs in Germany... Maybe I'm not alone with that problem...
• chaostheory 10y ago
  I'm not going to argue. However if you've run into the same problem where you feel like you need to either make fat model or fat controller in Rails, here's a simple solution: https://github.com/collectiveidea/interactor https://github.com/collectiveidea/interactor
• agentgt 10y ago
  I have seen posts like this time after time of experienced developer eventually hating (opinionated and/or coupling) framework. I too eventually came to a similar conclusion albeit on different platforms. Frameworks get you started quickly but you will eventually hate them. And I do mean framework and not library (there is a subtle but massive difference... yes the oxymoron was intentional). Its even worse in Javascript land. You could rewrite this post and just insert one of the many Javascript frameworks like Angular.
• charlysisto 10y ago
  A simple formula to take a lot of AR's bloat away is to use it mainly as a read library (AR's great for generating complex queries in a simple & readable manner). For write operations (aka user interaction) I use a combination of solnic gem (Virtus) with ActiveModel that way I remove a s*t load of responsibilities from AR and the controller : - params management (and strong params) - validations - nested associations - callbacks - And all the context management (like user vs admin...) That way I only mildly part from the rails way and yet have a good separation of concern. Actually ActiveModel is used by ActiveRecord so having a form object relying on it is still very much rails compliant. The refactoring is minor (no hexagonal stuff) and the level of indirection very low.
• nicolasMLV 10y ago
  Here is a new blogpost from DHH "Provide sharp knives" https://m.signalvnoise.com/provide-sharp-knives-cc0a22bf7934 https://m.signalvnoise.com/provide-sharp-knives-cc0a22bf7934
• geebee 10y ago
  Great article, and only 391 posts. Clearly I need to show up 24 hours after the fact and put in my two cents ;) From what I've read here, it really doesn't sound like his time with rails is quite "up". It sounds like he has read the writing on the wall about rails, after a very long time with the framework (certainly longer and more involved than I've been, though I have used Rails quite a bit). This is different from realizing that a technology won't last "forever", it's a more distinct understanding that you see where things are going and how your current tools don't quite match up anymore. But when my time with Rails is "up", that will mean that I have largely stopped using it. I'm mot counting maintenance, or perhaps the occasional one-off, I mean that if my time with a technology is "up", that means I don't use it anymore for day to day work. I'd be interested in reading more from Piotr Solnica on this topic, because I'm in a similar spot. I don't see Rails as the ideal match for much of what I'm doing on the web, but I'm not anywhere near ready to give it up. I increasingly need much more interaction between the client and server than I get from the MVC approach, but I'm not sold on javascript front ends with a web service backend, at least not the way it's been presented now. For starters, I personally (yes, this is very much a personal trait) don't relish the idea of giving up Ruby to write most of my app in Javascript. It's not just that I like ruby, I don't really like the idea of giving up the very rich set of languages I can choose from on the server side, or minimizing their role, in order to allow javascript to take over most of my programming work. I also feel that javascript front end frameworks are still a moving target, and I have a suspicion (like I said, I'm trying to sort this out) that when the dust settles, elaborate javascript front ends communicating with a web service written in something else won't be where I go next. I've read about some exciting new possible directions in this blog post, and I've read interesting things elsewhere (Volt, specifically, non-js languages transpiled to isomorphic javascript, more generally). It is all very exciting and promising, but is this the moment to give up on Rails, which works though I find myself increasingly shoehorning things into it? For me (again, just for me, everyone has a different set of interests and tasks), no, not yet. Drawing on my past experience - the last time I felt this way was when web programming in java moved from the jdbc/servlets/html with libraries to struts, struts2, spring mvc, pico, spring di, jpa, hibernate, ibatis, wicket, tapestry and so forth. Looking back, I wish I'd had the conviction to stick with the old way of doing things even though I knew its days were numbered. Keep an eye on things, keep learning. It sounds to me, from the end of this article, that this is what Piotr is doing. There are some good suggestions of where to go next, but I guess my question for the author is this: where are you going now? Is your time with rails "up" in the sense that you no longer have a substantial day to day use for it, that there is a new technology that you'll be working with now the way you worked with rails for 9+ years? Or is this more a situation where you see that your time with rails is ending - if not today, then certainly before long?
• bigtunacan 10y ago
  Things aren't always the best fit for a person and they have to decide to move on. Solnic has contributed a lot to the Ruby community and I'm not surprised to see him leave. Within the the web domain of Ruby there has very much been a Highlander attitude of "there can be only one". That one has always been Rails. For someone that wants to create better pieces or have more choices other languages are more accepting. On much of what he said in the article he is on point. Personally I've never been a big DataMapper fan (sorry dude, I just prefer Sequel), but I do agree ActiveRecord isn't great. I've considered leaving the Ruby eco-system, but I look around and don't like the alternatives I see either. One of the great things about learning Ruby on Rails is job skill relevance. If you want to make a move and you know Rails then pretty much all job search matches are a green light. If you know Java and you are working with Play then nobody wants you because they want experience with Stripes, Spark, or god forbid Struts; now you have to relearn the whole framework and rinse repeat each time. Personally I stick mostly to Ruby on Rails (and JavaScript) for my professional work, and then on personal projects I work in various obscure technologies that I just enjoy because I enjoy and I don't need to worry about if it will help bring in the bacon.
• frostymarvelous 10y ago
  This is simply why I've never liked Laravel. Don't get me wrong, I love the packages esp. Eloquent and Blade (validaton and translation not far behind) and I reuse them in all my projects now. I simply hate the "magic". I don't touch anything with too much magic going on and even avoid some features of Eloquent because of that. And since it is heavily inspired by rails...
• jm3 10y ago
  Thanks for posting this, I otherwise I would never have learned about dry-rb, hanami, trailblazer, and rom-rb!
• garfieldnate 10y ago
  Funny, his complaint about Ruby completely owning your app and the creators wanting it that way are the same that James Shore gives for Ember (also made by the Rails people) on TDJS.