14 ms·

After reading “Rails is yesterday’s software”, I need to reply

259 points by D_Guidi 10y ago

rco8786 10y ago
Reposting a reply I put on the original submission, but pertinent here as well: Use whatever tools/framework you want. Whatever it is you use, you will eventually become [the original] OP. The reality is that every language/framework has warts. As you use it and get deeper into it, you will uncover these warts. Eventually, all you can see is the warts. It's important to take a minute every once in a while and look at the thing you built from a user's perspective. See what problem you've solved for people, or just what cool new thing you've built. Staring at a bug backlog and a mountain of tech debt will always get you down about your project, but that's the reality of programming...bugs and tech debt.
agmcleod 10y ago
I agree with this quite a bit. Even in my own projects, I love using Rails for web stuff, but I would never use Ruby for games. It's a pain to distribute working binaries, and really is not an ideal language for games.
aeze 10y ago
Fully agree with the post. Any time you're making decisions based on some dogma versus 'what is the best way to solve my current problem' you aren't guaranteeing an optimal solution.
- pwthornton 10y ago
  Depending on the project, I think you have to give weight to long-term maintenance and on going development as well. If you're building SASS software that people use daily and may be in the market place for a long time, you'll need to balance both solving today's problems with being able to meet the future. It's possible in this scenario, going with a proven solution like Rails me be it. I just wanted to point out that our solutions sometimes have to consider future considerations as well or have to consider continual development of a legacy product. Sometimes developers consider only whats best in the moment, and that has negative long-term consequences.
  - aeze 10y ago
    Definitely!
troxwalt 10y ago
Great follow up article. Choose the right tool for the job.
- melling 10y ago
  "Choose the right tool for the job" What exactly does that mean? It's a vague response that people have used for years when they don't want to explain why they chose a particular tool. In my experience, many developers take the path of least resistance and use what they are comfortable with and that's why "it's the right tool for the job".
  - emodendroket 10y ago
    Well, why not? "My team and I are familiar with these tools and confident that we can use them to deliver the desired result" seems like a fine reason to call something the right tool for the job.
    - Avshalom 10y ago
      They aren't the same thing but there's basically no room between "these are the tools I know"-thinking and "if all you have is a hammer"-thinking. Freely admit this is somewhat irrelevant though as most languages are the difference between a felling-ax and a splitting-ax or two sizes of screwdriver, as opposed to hammer vs drill.
      - emodendroket 10y ago
        Well, I assume most people have a handful of tools they are familiar with and choose from among them (although the proliferation JavaScript-based stuff absolutely everywhere might call that assumption into question).
  - Karunamon 10y ago
    Sometimes that's exactly what it means. The reason you see frameworks like Rails catching on, slow and bloated as it can be (and I say this as someone that loves the RoR ecosystem), is that developer time is generally more expensive than CPU time.
blub 10y ago
This is the old "use the right tool for the job" cop-out. The original post went deeper than that. I would summarize it like this: can modern complex, large-scale web apps be built with the tools we have today, be they Python, Ruby or Javascript? Or do we need an entire new class of tools which have traditionally been used to build large scale systems in the past? It's a multi-faceted question of type systems, tooling, packaging, dependency resolution and others. And as web apps continue to evolve, my guess is that the current tools will be considered lacking. It used to be that picking "the right tool" meant choosing between Ruby, Python, PHP, JS. In the future it might mean using (gulp) Java + WebAssembly or a combination of other unusual tools. This would be quite game-changing for most web developers. ;)
- emodendroket 10y ago
  > The original post went deeper than that. I would summarize it like this: can modern complex, large-scale web apps be built with the tools we have today, be they Python, Ruby or Javascript? Well, clearly they can, because lots of people are doing it. Maybe some other tools would make it easier than it is now but it is certainly possible now.
  - blub 10y ago
    With a wide interpretation of "can", the answer will be yes. But that's not a particularly interesting question to ask, as you've said it yourself. If X makes it 50% easier to create a complex product than LAMP, that's a huge difference.
- mbell 10y ago
  > The original post went deeper than that. If there was depth, I missed it. The only two points I got from it were 'I prefer static typing over duck typing' and 'avoid dependency hell'. The original post didn't add anything new to either argument and both have existed and been rehashed over and over again for decades.
  - blub 10y ago
    The trick is to ignore everything until the "duck typing" picture including the picture. Then to pay attention to the last four paragraps.
n0us 10y ago
Some software does become "yesterday's software." I'm looking at you Cold Fusion, Flash, COBOL, the Abacus. I don't think Rails belongs in this group. I recognize that it's a good framework even if I don't personally like.
- adventured 10y ago
  It's the same empty argument that started being thrown at PHP six or seven years ago. Because it's not the hot new thing, it's yesterday's software, regardless of whether it's still fully up to the task. Rails will still be going strong ten years from now without question, and there will be frequent articles proclaiming that it's terrible that whole time.
- estrabd 10y ago
  Interesting comment; I believe if you are going to implicate Cold Fusion, you also need to rope in PHP. My first exposure to web programming was HTMLScript at my university in the mid 90s (now called MivaScript and is the language used to build the MivaMerchant product). Soon after, I switched to PHP 3, but I found that I preferred Miva. I have not touched Miva in years after spending some time as a freelancer in the late 90s, but because it is tied to a successful niche e-commerce platform, the language survives. It is very similar to Cold Fusion minus the enterprise level database support. I worked with CF for a time in the late 90s/00s (when it was still a product of Allaire) along side of ASP (pre .net), and I actually preferred it to both ASP and PHP - mainly because the mixing of mark up and DSL blocks seemed really unscalable. PHP may have been seen as an evolution in web programming since it abstracted the mixing of logic and presentation a bit more than Miva or CF, but in retrospect I believe PHP was not an improvement. It made general web programming easier, but software maintenance is easier in languages like CF and Miva that embrace embedded mark up/logic. The frameworks provided by Ruby, Python, Perl, and even TCL (among others) seem to have reached a point where only blurring the lines between client and server seem like the only logical paradigm change - and that's not to say it's an improvement.
  - jsmith0295 10y ago
    This isn't really the case. There are modern web frameworks for PHP -- https://laravel.com/ https://laravel.com/ is the best example
carsongross 10y ago
I've got my problems with Rails: routing is overly complicated, the asset pipeline can be tricky, and so on. But Rails is very good at producing HTML and, in particular, partial chunks of HTML. As the current thick-clients-in-javascript trend cools off (it's happening, this was at the top of /r/webdev yesterday: https://www.reddit.com/r/webdev/comments/4iphv4/12_year_of_progress/ https://www.reddit.com/r/webdev/comments/4iphv4/12_year_of_p...) people are going to migrate back to HTML as a transport for web apps, using libraries like http://intercoolerjs.org http://intercoolerjs.org. (Disclosure: I developed it) Rails is well positioned for that.
- 67726e 10y ago
  What makes you think that being able to produce HTML is such an important piece, and that Raila delivers better than most other frameworks?
  - carsongross 10y ago
    HTML gives you HATEOAS without thinking about it: http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.ht... and is the minimum level of complexity necessary for a human web interface. Rails isn't necessarily better than other platforms at producing HTML: it does support rendering partials which is nice: http://guides.rubyonrails.org/layouts_and_rendering.html http://guides.rubyonrails.org/layouts_and_rendering.html. So, rails is pretty good at it, but I can imagine other tools being perfectly competent at the problem as well.
    - dragonwriter 10y ago
      > HTML gives you HATEOAS without thinking about it No, it doesn't, though it certainly makes it simpler (than something not designed as a hypermedia format) to do HATEOAS if you think about it.
- lmm 10y ago
  Rails is still page-oriented, no? I've found Wicket is head and shoulders above anything else for actually producing HTML, and it can already do lightweight partial ajax updates to the UI if that's the style you're suggesting.
hashkb 10y ago
Author is being nice, but I'm happy to point out that author of replied-to post is revealing they are a frustrated novice. All the focus on "Rails made programming cool" tells me "I do things for dumb reasons." Clear case of chasing the dragon.
- askyourmother 10y ago
  Aren't most if not all Rails programmers just chasing shiny magic features? Rails programmers tend to be like a McDonald's happy meal - uninspired, fills a hole, make do.
  - hashkb 10y ago
    Haha perhaps. /me is a Rails programmer, a lot of the time.
  - Tenhundfeld 10y ago
    Your comment comes across as narrow-minded and frankly, a bit arrogant. It is just so dismissive. Rails's original popularity came from developers fleeing the excessive ceremony and boilerplate code of enterprise Java – and .NET to some extent. Sure, there are some inexperienced (or simply bad) developers in the Rails community, just as there are in every community. But most of the Rails developers I've met also have experience in at least one other major web stack. They're not chasing "shiny magic features". They're chasing productivity. For me personally, Rails offers greater productivity than any other web framework I've used. The truth is Ruby has little to do with that, as much as I happen to like the language. I could go on for quite a while about why I feel Rails offers the best productivity, but it boils down to two main points: the entire Rails community is focused on building web applications, and the Rails core team is mostly comprised of people actually building web applications. Features get added because they're needed. Common frictions get ironed out. Rails isn't about "magic". Rails is about getting shit done, quickly and mostly-cleanly.
    - askyourmother 10y ago
      Uhhm, it certainly is about magic, it's creator goes on about that quite a bit. So the happy meal developers don't really have to know how to code. Just install these gems, copy these incantations from the pragprog book, you too can have your site in five minutes. You don't need to understand the shiny magic, I mean, it detracts from being saying "I'm a Rails developer", but maybe it would help if they did.
mizchief2 10y ago
Not yesterday's software, just runs so slow it makes you think you are living in the past.
janvdberg 10y ago
In the comments of that HN post this link was posted which I found highly informative regarding the matter: https://speakerdeck.com/tehviking/surviving-the-framework-hype-cycle https://speakerdeck.com/tehviking/surviving-the-framework-hy...
mberning 10y ago
I personally love ruby and rails and still find it to be extremely effective and adaptable to most web development tasks. As people flee the platform a huge amount of opportunities are going to open up for that still enjoy the platform. I can't wait.
lr4444lr 10y ago
The author leaves the business needs completely off the table, even though it would help his case. If you have a limited amount of time to launch your product in your current round of funding, and you want a framework that helps a small number of tech employees build working first generation critical features reasonably quickly, handle a large number of tasks not critical to the company's value proposition reasonably well, can be maintained and scaled on a variety of PaaS options well long enough until the company is profitable enough to move to the next phase of tech infrastructure, is Rails attractive software? I'm not an expert with it, and I don't even enjoy using it, but I believe it is.
- jetheredge 10y ago
  I considered speaking to that, but then I felt like I was delving into religious arguments. My framework is more efficient than your framework! I felt it would have drawn people away from my main point, which is to think deeply about the tools you choose, and everyone needs different tools.
cdnsteve 10y ago
"makes it easy to install 1,000 gems into your project without a single line of configuration, is exactly why it’s hard to debug". This "let someone else do the work, get it from a gem" mindset is what kills long lived projects. It has nothing to do with the tools and everything to do with experience. You don't need 1000 gems. Managing anything more than core dependancies in a project can easily create exponential bugs and consume all your resources to fix. Remember left-pad? This is true in any language and ecosystem and has nothing to do with rails/gems/ruby. The same is with Python, JS, PHP. Senior/Lead devs need to carefully curate what a projects foundation is. A strong, well designed foundation means you have something solid to build on. If you don't understand what's in your deps, haven't read their code, see how often it's updated and how many people actively use it, and can say you are using 80% or more of the code in it then don't use it. Writing your own code is often the best route since it fixes your exact use case, no matter the language, libraries or frameworks being used.
- incepted 10y ago
  > This "let someone else do the work, get it from a gem" mindset is what kills long lived projects If you replace "gem" with "library", this actually makes a lot of sense. It saves time to reuse existing (high quality) software. Plenty of ecosystems do just fine with this mindset, starting with the JVM and .net. The problem is specifically Ruby and the gems system.
  - throwanem 10y ago
    More specifically, the problem is the combination of Ruby making it very easy to monkey-patch and apply magic, and a community which more or less ubiquitously encourages gem authors to use those facilities as promiscuously as they like. Either in isolation would be dangerous; the combination is lethal.
- toolz 10y ago
  I work on some really big projects in the wild for various clients in ruby on rails and they have so many gems that often I find unused gems they are afraid to remove them in case it actually is being used, but you know what? They were moving forward with features - their user base was happy and their product worked for the most part. You know what kinds of projects I see fail? The ones who try to architect everything using a core set of libraries and build everything themselves. I've seen hugely funded projects with years of development burn for that very reason. I know I'm just a single datapoint, but it's worth mentioning that there exists projects that absolutely will do better in the long run with just installing all the gems.
vox_mollis 10y ago
I've come to the conclusion that those who defend weak/dynamic type systems and other unsafe toolchains simply buy into the fallacy of the uber-developer: the belief that while other, lesser developers need static typing and analysis, I'm so superior that I will never introduce those class of bugs, ever.
- obstacle1 10y ago
  Could you point out where the author of this post even came close to suggesting that Rails is for great developers who don't need static typing? Or did you accidentally post this unrelated opinion in the wrong thread?
  - vox_mollis 10y ago
    I'm responding to the article that the author linked to, which does mention static typing. This comment is an attempt at a hypothesis for why some developers dismiss the importance of such features/tools.
- amorphid 10y ago
  I like Elixir quite a bit, and it doesn't have a strong type system. The pattern matching removes a lot of the pain of weak types.
- jcyw 10y ago
  I found this equally true for the other side of argument too. Some people choose to ignore that Polymorphsim is a dynamic typed behavior. (Its general being multiple dispatch.) And the faith to compiler seems not come from the understanding of what a compiler is. The author of the original post doesnt seem to recognize Java is also a slow, interpreted language. Haha.
danenania 10y ago
Moving on from Rails sounds great until you try to build a serious web app with one of the alternatives. While I think that many of the architectural criticisms are valid, Rails demonstrates the primacy of ecosystem and strong conventions over language design and cs theory. 'Tomorrow's' languages and frameworks would do well to take heed. Winning this war has as much to do with culture and marketing as algorithms and data structures. Clojure, for example, is a much stronger programming language than Ruby on paper, but for a straightforward web app, you'll likely spend at least twice as long to get something working--and while it will be based on better engineering principles, it will also take new engineers much longer to grok since it doesn't follow any universal set of conventions. With Rails, you end up in the weeds in the long run, but the alternatives put you in the weeds right off the bat (with the promise of eventual salvation). The reality of most product development (ymmv) is that the former is highly preferable to the latter.
- deleted 10y ago
  [deleted]
- raverbashing 10y ago
  > With Rails, you end up in the weeds in the long run, but the alternatives put you in the weeds right off the bat (with the promise of eventual salvation). The reality of most product development (ymmv) is that the former is highly preferable to the latter. You're absolutely right. And yes, Rails has quirks and I agree with most of the criticism of the other article Option 1: Twitter is built on RoR, have growing pains and lots of whales when it has an established product (when it gets the investors and the money to invest in a rebuild) Option 2: Twitter is built on Clojure, product takes more time, iteration gets slower, hiring is slower, some other competitor gets ahead. Ooops
- dcrall 10y ago
  I agree that Rails' strong opinions are still a strength. I like Clojure a lot, but for someone new to the language trying to get a Clojure web app started is like pulling teeth. Elixir and Phoenix, with their connections to the Ruby community, really get this, and I think they provide a much better introductory experience.
Benjamin_Dobell 10y ago
Recently I upgraded a project from Rails 3.2.x to 4.0.x... 4.0.x -> 4.1.x... 4.1.x -> 4.2.x It was, and still is, a nightmare. Technically speaking Rails itself upgraded in a reasonably straight-forward way, just follow the documentation (well and a few blog posts here and there for the things missed in the official docs). But all the additional Gems, and dependencies of those Gems (and so on) made the process excruciating. Many things broke in subtle ways at runtime (no compilation, so no compiler errors) and there was no clear path to upgrade; because whilst Rails' upgrade path is documented, there's a plethora of Gems that also needed to be upgraded separately (some in contradictory manners). You might wonder why I was so out of date in the first place. Two reasons: 1. I inherited this code-base. 2. I've attempted this (or a similar) upgrade about 5 other times in the past; spending hours upon hours debugging crashes (or just weird behaviour) with enormous stack-traces where my application's own code often doesn't even appear in the stack trace. It's only now after making several failed (or rather overly time consuming) attempts I was able to come up with a "workable" upgrade path. Gems dynamically generating methods left, right and centre, Gems replacing methods of seemingly unrelated classes (when they definitely do not need to), and crazy "conventions" that hide all the actual logic make debugging any sizeable Rails project a complete disaster. Don't even get me started on the poor performance, much of which is to do with poorly designed Gems and not even the Ruby interpreter's fault. That said... I still turn to Rails when I want to get a new project (with users, database, login, admin etc.) up and running quickly. It's a shame, but in terms of development speed, it's hard to beat Ruby (and Rails). For small projects Sinatra is very solid, and Padrino is interesting - but honestly I can't wait for the day I can move to a compiled language and still achieve this sort of development speed.
- heartbreak 10y ago
  I hear horror stories like this, and I have one of my own. 1. Absolutely no tests of any kind 2. Over 100 gem dependencies Upgrade from 3.2.x to 4.2.x took one developer (me) three weeks of work. I don't know if that's a lot or not, given the major version upgrade and all of the gems (which were a huge pain). I've not had any problems in production reported via Honeybadger or by end users, so I think the upgrade was a success. I did end up writing about 200 unit and integration specs during the process. I'm thinking back to my days in the .Net world at BigCorp. Unfortunately I have nothing to compare it to, because we never upgraded anything from one major version of ASP.NET MVC to another. Is that a better situation?
zacharypinter 10y ago
It seems to me that a version of the Innovator's Dilemma might apply to software frameworks as well. By the time a project gets large enough it starts optimizing for its major stakeholders. New use cases or new ways of rethinking common use cases come along, and the small libraries that approach it from scratch have a narrowly-defined advantage. If the advantage is significant enough (e. g. virtual dom for browser UI), then new frameworks start being written around them, bringing back some but not all of the features of the older frameworks. At some point (different for each user/use case) the newer frameworks have enough functionality that people start considering them over the older ones for new projects. When enough of that happens, the older frameworks start looking like yesterday's software.
deleted 10y ago
[deleted]
mpdehaan2 10y ago
In the original article, he indicates Swift, Rust, and Go are tomorrow's languages. The issue really is that the level of support in the various frameworks, the eons of bug-crushing and feature additions, and the libraries available, are going to be behind for some time. This is why I'd still gladly pick Django today. What is "the future" isn't really so interesting as what is productive. Yes, performance matters a bit, but development time is usually much more expensive than adding a few nodes to an autoscaling group, and not worth the cost of using less fleshed out libraries.
- weberc2 10y ago
  In my experience as a professional Python dev and a hobbyist Gopher, Go's libraries are a lot less convoluted than Python libraries. In Python, you see a lot of libs that try to do everything for everyone (think long args lists and functions that try to guess the right thing to do based on arg types) whereas Go libraries just kind of snap together neatly. Go tends to be more productive for me than Python specifically because its philosophy values simplicity and orthogonality over complexity and scope breadth. > Yes, performance matters a bit, but development time is usually much more expensive than adding a few nodes to an autoscaling group, and not worth the cost of using less fleshed out libraries. Sequentially, Go outperforms Python and other interpreted languages by a wide margin (usually a factor of 10). Things get really interesting with Go because it can be massively concurrent without messing around with large async refactors. At work, we're hoping our first iteration (i.e., before any async refactors) of our Python application to handle something like 5-10 concurrent requests per machine (without degrading response times), but I'm confident a single Go process could handle at least 10X that load with better response times. This order-of-magnitude difference seems fundamentally different from the perspective of "throwing hardware at the problem". Further, Go's library story is fairly complete (for web services; GUIs and other domains are still lacking)--at least it's been a long while since I've lacked a complete library for some task.
  - mpdehaan2 10y ago
    Again, performance isn't everything. Go has specialized a bit towards low-level operations, and I tend to strongly dislike what it does with exceptions and the way those involved veto language features. As for libraries, I'm talking about things on the level of, say, Django or ORMs.
noamsml 10y ago
I feel like this is a terribly lacking reply. I'm not a trend-person by any mean: I'm a deep-backend developer, and my main language right now is Java[1]. However, when I have to maintain rails apps, even well-written ones, I find myself frustrated. I think ceding the advantages of a compiler is a fundamental mistake. Compilers and static checkers make for better software more easily; they don't replace tests, but they complement them and constitute compilable documentation for your code, enhancing its maintainability considerably. [1] I write in Java because I work for a Java shop, but even if I had my choice of languages, I'd probably be using either Swift or a compile-to-JVM language.
xaduha 10y ago
Rails wasn't even the best choice when it appeared.
- domador 10y ago
  What would you say was the best choice when Rails appeared? Since then, has Rails been the best choice at any point, in your opinion?
qaq 10y ago
The thing is in many cases you had to make a choice between performance and productivity. With things like Elixir/Phoenix you don't really have to make that choice. Maturity argument again is moot as you are building on top of Erlang/BEAM that's very mature and has very good tooling. For people coming from Ruby the syntax also makes transitioning less of a pain.
dschiptsov 10y ago
There is, perhaps, a law, such that any project with a strong tendency to pile up more crap instead of reducing it to "just right, when nothing else could be removed" (a-la 9P2000 protocol, and few foundation libs of Plan9) will end up in a J2EE-like pile of collective stupidity. At least, everything in nature tends to get reduced to a local optimum by a straightforward optimization process of trial and error. There is no way to make a reliable and efficient complex system by piling up more and more crap. And, funny enough, JavaScript will be even worse - it already makes J2EE look not that bad.)
- TheOtherHobbes 10y ago
  This should be studied in comp sci. Instead of building compilers and interpreters in the abstract, there should be a serious study of how languages/frameworks are created and developed in the wild. I suspect there are easily visible patterns and trends, and they tend to repeat over and over. The corollary is that specific languages can't fix cultural issues unless they're designed to do that.
willvarfar 10y ago
The problem I feel with Ruby and RoR apps is that people bang gems together without knowing how those gems do what they promise to do, what those gems depend upon, what those gems monkey patch, what they change. Further down the road, maintenance drowns you. I've rallied against this mindset before, e.g. regards security http://williamedwardscoder.tumblr.com/post/43394068341/rubys-principle-of-too-much-power http://williamedwardscoder.tumblr.com/post/43394068341/rubys... I find large Python apps fairly unmaintainable too, but to a much lesser degree.
brightball 10y ago
At the moment, the alternatives mentioned to Rails aren't actually alternatives. You are still going to make major trade offs in productivity compared to Rails... Unless he's talking about Elixir and Phoenix, which IMHO is the future of web development.
- DevinTheDude 10y ago
  As someone who has never heard of Elixir/Phoenix, why do you think it's the future. What does it do better than Rails? I'm looking to start a new web application, and I'm open to new technologies.
  - brightball 10y ago
    Elixir is a nicer to work with language that Erlang that compiles down to the Erlang VM. That gives it a better concurrency model and fault tolerance than Go. Rails core team members have been building Phoenix. It's syntax is built to be extremely familiar to Rails but it's been built from the ground up to correct a lot of core issues that come up long term with Rails. It's basically fast Rails. You get a very equivalent level of productivity with performance and fault tolerance of Erlang. Benchmarks show performance on par with Go. It's really fascinating. I've been programming professionally for about 17 years now and it's the first time I've been truly excited about a language for a long time.
    - DevinTheDude 10y ago
      First, thanks for taking the time to answer my question, I'm at my day job (I program at night) so I can't do much research >correct a lot of core issues that come up long term with Rails. I've never gotten to this point, what are some of these issues? From reading comments here, it seems like dependency hell could be one, but what do you think? I've had issues in my short time with outdated gems, but I don't know if this is necessarily an issue with the framework/language.
      - brightball 10y ago
payne92 10y ago
As more of the computational elements of UIs shift from server-side HTML to client-side Javascript, server-side frameworks like Rails, Django, PHP, etc. become less relevant. Fast forwarding, many apps are (or will be) big JS blobs using APIs/microservices back to the server. In that version of the future, frameworks like Rails can get in the way more than they help.
0xfaded 10y ago
Dynamic languages reduce the formal overhead required to develop new ideas. I can't imagine that an "eliminate boilerplate via convention at the cost of explicitness" mentality would have evolved independently in a world where assurances are earned by proving extra properties to the compiler. However mordern compiled languages now formalise the shortcuts afforded by dynamic languages, e.g. type inference, generics, implicit conversions, typesafe macros, type classes, etc. Similarily conventions popularised by rails-esqe frameworks are being formalised using the tools listed above. I fall into the scala camp, but have used rails at a previous job. My guess is I need 1.5x scala lines vs Ruby which I believe is a justified cost. Opinions of course vary.
methehack 10y ago
Anyone finding any of this resonating really owes it to themselves to try elixir / phoenix and, at the very least, keep an eye on it.
ryanmarsh 10y ago
Many of the complaints against Rails in this HN discussion are around code base maintainability, gem proliferation, and amateurs. Any tool that allows the rapid (almost effortless) accretion of complexity will suffer these problems. It goes with the territory.
- wvenable 10y ago
  I think that's a good point. JavaScript with Node is arguably worse than Rails for exactly that reason.
k__ 10y ago
why do most people only see the extremes? you don't have to use bleeding egde libs instead of rails... hapi instead of koa react instead of cycle ember instead of react etc...
- piotrkubisa 10y ago
  Because we do love them, just like Vim vs Emacs, PHP vs Ruby, Go vs Elixir, jQuery vs React... But there is always something what I personally find very positive between all these differences. Please look at Windows and the Linux - some years ago we got used to installing a dual-boot environments and now we may experience Canonical's Ubuntu on Windows with real Bash.
shams93 10y ago
I've seen the biggest benefit from a client heavy approach even with rails. Make the api the core of your system, makes it easier to refactor down the road into microservices. For a lot of web apps there is no real need for server side templating, once you get beyond server templating its easier to make native versions of your app or use xamarian to access the same api from a common c# codebase for native. Place your business logic in the api and there's really nothing for someone to steal from view source because your clients are just REST wrappers.
padseeker 10y ago
I have to say I'm loving reading the thoughtful and insightful comments on this thread. With any programming language and/or framework you have to pick your poison. Rails backloads a lot of big development obstacles that ultimately you may never actually encounter in the life of your app. The issue regarding gems can be aggravating. But the speed in which you can get your app built cannot be understated. Rails is not a one size fits all, and you might eventually outgrow rails (i.e. Twitter). Be grateful the framework got you to the point you could outgrow it, rails helped you get there.
lo_fye 10y ago
PHP is the day before yesterday's software, but it still gets a shitload of profitable work done.
mmedley 10y ago
It simply boils down to what you're most proficient with. Depending on the problem, you're likely to encounter some technologies are better suited than others. That to me is where you'll get the most bang for the buck, being able to decide on the right tool for the problem.
ksec 10y ago
Sometimes I wonder if Ruby and Rails is 5x faster then now by default and allow really simple scaling without much thoughts, would it still get so much critics? Most of the time People will answer saying moving away from Rails as you scale is a good problem to have. But the day Rails isn't fast enough or scale easy enough is coming a lot quicker as the Internet Population expands. And the good old saying of passing this to Morre's Law no longer works as we haven't had much CPU improvement. I am hoping JRuby with Graal and Truffle will fix that.

259 points by D_Guidi 10y ago

Reposting a reply I put on the original submission, but pertinent here as well: Use whatever tools/framework you want. Whatever it is you use, you will eventually become [the original] OP. The reality is that every language/framework has warts. As you use it and get deeper into it, you will uncover these warts. Eventually, all you can see is the warts. It's important to take a minute every once in a while and look at the thing you built from a user's perspective. See what problem you've solved for people, or just what cool new thing you've built. Staring at a bug backlog and a mountain of tech debt will always get you down about your project, but that's the reality of programming...bugs and tech debt.

agmcleod 10y ago

I agree with this quite a bit. Even in my own projects, I love using Rails for web stuff, but I would never use Ruby for games. It's a pain to distribute working binaries, and really is not an ideal language for games.

aeze 10y ago

Fully agree with the post. Any time you're making decisions based on some dogma versus 'what is the best way to solve my current problem' you aren't guaranteeing an optimal solution.

pwthornton 10y ago
Depending on the project, I think you have to give weight to long-term maintenance and on going development as well. If you're building SASS software that people use daily and may be in the market place for a long time, you'll need to balance both solving today's problems with being able to meet the future. It's possible in this scenario, going with a proven solution like Rails me be it. I just wanted to point out that our solutions sometimes have to consider future considerations as well or have to consider continual development of a legacy product. Sometimes developers consider only whats best in the moment, and that has negative long-term consequences.
- aeze 10y ago
  Definitely!

troxwalt 10y ago

Great follow up article. Choose the right tool for the job.

melling 10y ago
"Choose the right tool for the job" What exactly does that mean? It's a vague response that people have used for years when they don't want to explain why they chose a particular tool. In my experience, many developers take the path of least resistance and use what they are comfortable with and that's why "it's the right tool for the job".
- emodendroket 10y ago
  Well, why not? "My team and I are familiar with these tools and confident that we can use them to deliver the desired result" seems like a fine reason to call something the right tool for the job.
  - Avshalom 10y ago
    They aren't the same thing but there's basically no room between "these are the tools I know"-thinking and "if all you have is a hammer"-thinking. Freely admit this is somewhat irrelevant though as most languages are the difference between a felling-ax and a splitting-ax or two sizes of screwdriver, as opposed to hammer vs drill.
    - emodendroket 10y ago
      Well, I assume most people have a handful of tools they are familiar with and choose from among them (although the proliferation JavaScript-based stuff absolutely everywhere might call that assumption into question).
- Karunamon 10y ago
  Sometimes that's exactly what it means. The reason you see frameworks like Rails catching on, slow and bloated as it can be (and I say this as someone that loves the RoR ecosystem), is that developer time is generally more expensive than CPU time.

blub 10y ago

This is the old "use the right tool for the job" cop-out. The original post went deeper than that. I would summarize it like this: can modern complex, large-scale web apps be built with the tools we have today, be they Python, Ruby or Javascript? Or do we need an entire new class of tools which have traditionally been used to build large scale systems in the past? It's a multi-faceted question of type systems, tooling, packaging, dependency resolution and others. And as web apps continue to evolve, my guess is that the current tools will be considered lacking. It used to be that picking "the right tool" meant choosing between Ruby, Python, PHP, JS. In the future it might mean using (gulp) Java + WebAssembly or a combination of other unusual tools. This would be quite game-changing for most web developers. ;)

emodendroket 10y ago
> The original post went deeper than that. I would summarize it like this: can modern complex, large-scale web apps be built with the tools we have today, be they Python, Ruby or Javascript? Well, clearly they can, because lots of people are doing it. Maybe some other tools would make it easier than it is now but it is certainly possible now.
- blub 10y ago
  With a wide interpretation of "can", the answer will be yes. But that's not a particularly interesting question to ask, as you've said it yourself. If X makes it 50% easier to create a complex product than LAMP, that's a huge difference.
mbell 10y ago
> The original post went deeper than that. If there was depth, I missed it. The only two points I got from it were 'I prefer static typing over duck typing' and 'avoid dependency hell'. The original post didn't add anything new to either argument and both have existed and been rehashed over and over again for decades.
- blub 10y ago
  The trick is to ignore everything until the "duck typing" picture including the picture. Then to pay attention to the last four paragraps.

n0us 10y ago

Some software does become "yesterday's software." I'm looking at you Cold Fusion, Flash, COBOL, the Abacus. I don't think Rails belongs in this group. I recognize that it's a good framework even if I don't personally like.

adventured 10y ago
It's the same empty argument that started being thrown at PHP six or seven years ago. Because it's not the hot new thing, it's yesterday's software, regardless of whether it's still fully up to the task. Rails will still be going strong ten years from now without question, and there will be frequent articles proclaiming that it's terrible that whole time.
estrabd 10y ago
Interesting comment; I believe if you are going to implicate Cold Fusion, you also need to rope in PHP. My first exposure to web programming was HTMLScript at my university in the mid 90s (now called MivaScript and is the language used to build the MivaMerchant product). Soon after, I switched to PHP 3, but I found that I preferred Miva. I have not touched Miva in years after spending some time as a freelancer in the late 90s, but because it is tied to a successful niche e-commerce platform, the language survives. It is very similar to Cold Fusion minus the enterprise level database support. I worked with CF for a time in the late 90s/00s (when it was still a product of Allaire) along side of ASP (pre .net), and I actually preferred it to both ASP and PHP - mainly because the mixing of mark up and DSL blocks seemed really unscalable. PHP may have been seen as an evolution in web programming since it abstracted the mixing of logic and presentation a bit more than Miva or CF, but in retrospect I believe PHP was not an improvement. It made general web programming easier, but software maintenance is easier in languages like CF and Miva that embrace embedded mark up/logic. The frameworks provided by Ruby, Python, Perl, and even TCL (among others) seem to have reached a point where only blurring the lines between client and server seem like the only logical paradigm change - and that's not to say it's an improvement.
- jsmith0295 10y ago
  This isn't really the case. There are modern web frameworks for PHP -- https://laravel.com/ https://laravel.com/ is the best example

carsongross 10y ago

I've got my problems with Rails: routing is overly complicated, the asset pipeline can be tricky, and so on. But Rails is very good at producing HTML and, in particular, partial chunks of HTML. As the current thick-clients-in-javascript trend cools off (it's happening, this was at the top of /r/webdev yesterday: https://www.reddit.com/r/webdev/comments/4iphv4/12_year_of_progress/ https://www.reddit.com/r/webdev/comments/4iphv4/12_year_of_p...) people are going to migrate back to HTML as a transport for web apps, using libraries like http://intercoolerjs.org http://intercoolerjs.org. (Disclosure: I developed it) Rails is well positioned for that.

67726e 10y ago
What makes you think that being able to produce HTML is such an important piece, and that Raila delivers better than most other frameworks?
- carsongross 10y ago
  HTML gives you HATEOAS without thinking about it: http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.ht... and is the minimum level of complexity necessary for a human web interface. Rails isn't necessarily better than other platforms at producing HTML: it does support rendering partials which is nice: http://guides.rubyonrails.org/layouts_and_rendering.html http://guides.rubyonrails.org/layouts_and_rendering.html. So, rails is pretty good at it, but I can imagine other tools being perfectly competent at the problem as well.
  - dragonwriter 10y ago
    > HTML gives you HATEOAS without thinking about it No, it doesn't, though it certainly makes it simpler (than something not designed as a hypermedia format) to do HATEOAS if you think about it.
lmm 10y ago
Rails is still page-oriented, no? I've found Wicket is head and shoulders above anything else for actually producing HTML, and it can already do lightweight partial ajax updates to the UI if that's the style you're suggesting.

hashkb 10y ago

Author is being nice, but I'm happy to point out that author of replied-to post is revealing they are a frustrated novice. All the focus on "Rails made programming cool" tells me "I do things for dumb reasons." Clear case of chasing the dragon.

askyourmother 10y ago
Aren't most if not all Rails programmers just chasing shiny magic features? Rails programmers tend to be like a McDonald's happy meal - uninspired, fills a hole, make do.
- hashkb 10y ago
  Haha perhaps. /me is a Rails programmer, a lot of the time.
- Tenhundfeld 10y ago
  Your comment comes across as narrow-minded and frankly, a bit arrogant. It is just so dismissive. Rails's original popularity came from developers fleeing the excessive ceremony and boilerplate code of enterprise Java – and .NET to some extent. Sure, there are some inexperienced (or simply bad) developers in the Rails community, just as there are in every community. But most of the Rails developers I've met also have experience in at least one other major web stack. They're not chasing "shiny magic features". They're chasing productivity. For me personally, Rails offers greater productivity than any other web framework I've used. The truth is Ruby has little to do with that, as much as I happen to like the language. I could go on for quite a while about why I feel Rails offers the best productivity, but it boils down to two main points: the entire Rails community is focused on building web applications, and the Rails core team is mostly comprised of people actually building web applications. Features get added because they're needed. Common frictions get ironed out. Rails isn't about "magic". Rails is about getting shit done, quickly and mostly-cleanly.
  - askyourmother 10y ago
    Uhhm, it certainly is about magic, it's creator goes on about that quite a bit. So the happy meal developers don't really have to know how to code. Just install these gems, copy these incantations from the pragprog book, you too can have your site in five minutes. You don't need to understand the shiny magic, I mean, it detracts from being saying "I'm a Rails developer", but maybe it would help if they did.

mizchief2 10y ago

Not yesterday's software, just runs so slow it makes you think you are living in the past.

janvdberg 10y ago

In the comments of that HN post this link was posted which I found highly informative regarding the matter: https://speakerdeck.com/tehviking/surviving-the-framework-hype-cycle https://speakerdeck.com/tehviking/surviving-the-framework-hy...

mberning 10y ago

I personally love ruby and rails and still find it to be extremely effective and adaptable to most web development tasks. As people flee the platform a huge amount of opportunities are going to open up for that still enjoy the platform. I can't wait.

lr4444lr 10y ago

The author leaves the business needs completely off the table, even though it would help his case. If you have a limited amount of time to launch your product in your current round of funding, and you want a framework that helps a small number of tech employees build working first generation critical features reasonably quickly, handle a large number of tasks not critical to the company's value proposition reasonably well, can be maintained and scaled on a variety of PaaS options well long enough until the company is profitable enough to move to the next phase of tech infrastructure, is Rails attractive software? I'm not an expert with it, and I don't even enjoy using it, but I believe it is.

jetheredge 10y ago
I considered speaking to that, but then I felt like I was delving into religious arguments. My framework is more efficient than your framework! I felt it would have drawn people away from my main point, which is to think deeply about the tools you choose, and everyone needs different tools.

cdnsteve 10y ago

"makes it easy to install 1,000 gems into your project without a single line of configuration, is exactly why it’s hard to debug". This "let someone else do the work, get it from a gem" mindset is what kills long lived projects. It has nothing to do with the tools and everything to do with experience. You don't need 1000 gems. Managing anything more than core dependancies in a project can easily create exponential bugs and consume all your resources to fix. Remember left-pad? This is true in any language and ecosystem and has nothing to do with rails/gems/ruby. The same is with Python, JS, PHP. Senior/Lead devs need to carefully curate what a projects foundation is. A strong, well designed foundation means you have something solid to build on. If you don't understand what's in your deps, haven't read their code, see how often it's updated and how many people actively use it, and can say you are using 80% or more of the code in it then don't use it. Writing your own code is often the best route since it fixes your exact use case, no matter the language, libraries or frameworks being used.

incepted 10y ago
> This "let someone else do the work, get it from a gem" mindset is what kills long lived projects If you replace "gem" with "library", this actually makes a lot of sense. It saves time to reuse existing (high quality) software. Plenty of ecosystems do just fine with this mindset, starting with the JVM and .net. The problem is specifically Ruby and the gems system.
- throwanem 10y ago
  More specifically, the problem is the combination of Ruby making it very easy to monkey-patch and apply magic, and a community which more or less ubiquitously encourages gem authors to use those facilities as promiscuously as they like. Either in isolation would be dangerous; the combination is lethal.
toolz 10y ago
I work on some really big projects in the wild for various clients in ruby on rails and they have so many gems that often I find unused gems they are afraid to remove them in case it actually is being used, but you know what? They were moving forward with features - their user base was happy and their product worked for the most part. You know what kinds of projects I see fail? The ones who try to architect everything using a core set of libraries and build everything themselves. I've seen hugely funded projects with years of development burn for that very reason. I know I'm just a single datapoint, but it's worth mentioning that there exists projects that absolutely will do better in the long run with just installing all the gems.

vox_mollis 10y ago

I've come to the conclusion that those who defend weak/dynamic type systems and other unsafe toolchains simply buy into the fallacy of the uber-developer: the belief that while other, lesser developers need static typing and analysis, I'm so superior that I will never introduce those class of bugs, ever.

obstacle1 10y ago
Could you point out where the author of this post even came close to suggesting that Rails is for great developers who don't need static typing? Or did you accidentally post this unrelated opinion in the wrong thread?
- vox_mollis 10y ago
  I'm responding to the article that the author linked to, which does mention static typing. This comment is an attempt at a hypothesis for why some developers dismiss the importance of such features/tools.
amorphid 10y ago
I like Elixir quite a bit, and it doesn't have a strong type system. The pattern matching removes a lot of the pain of weak types.
jcyw 10y ago
I found this equally true for the other side of argument too. Some people choose to ignore that Polymorphsim is a dynamic typed behavior. (Its general being multiple dispatch.) And the faith to compiler seems not come from the understanding of what a compiler is. The author of the original post doesnt seem to recognize Java is also a slow, interpreted language. Haha.

danenania 10y ago

Moving on from Rails sounds great until you try to build a serious web app with one of the alternatives. While I think that many of the architectural criticisms are valid, Rails demonstrates the primacy of ecosystem and strong conventions over language design and cs theory. 'Tomorrow's' languages and frameworks would do well to take heed. Winning this war has as much to do with culture and marketing as algorithms and data structures. Clojure, for example, is a much stronger programming language than Ruby on paper, but for a straightforward web app, you'll likely spend at least twice as long to get something working--and while it will be based on better engineering principles, it will also take new engineers much longer to grok since it doesn't follow any universal set of conventions. With Rails, you end up in the weeds in the long run, but the alternatives put you in the weeds right off the bat (with the promise of eventual salvation). The reality of most product development (ymmv) is that the former is highly preferable to the latter.

deleted 10y ago
[deleted]
raverbashing 10y ago
> With Rails, you end up in the weeds in the long run, but the alternatives put you in the weeds right off the bat (with the promise of eventual salvation). The reality of most product development (ymmv) is that the former is highly preferable to the latter. You're absolutely right. And yes, Rails has quirks and I agree with most of the criticism of the other article Option 1: Twitter is built on RoR, have growing pains and lots of whales when it has an established product (when it gets the investors and the money to invest in a rebuild) Option 2: Twitter is built on Clojure, product takes more time, iteration gets slower, hiring is slower, some other competitor gets ahead. Ooops
dcrall 10y ago
I agree that Rails' strong opinions are still a strength. I like Clojure a lot, but for someone new to the language trying to get a Clojure web app started is like pulling teeth. Elixir and Phoenix, with their connections to the Ruby community, really get this, and I think they provide a much better introductory experience.

Benjamin_Dobell 10y ago

Recently I upgraded a project from Rails 3.2.x to 4.0.x... 4.0.x -> 4.1.x... 4.1.x -> 4.2.x It was, and still is, a nightmare. Technically speaking Rails itself upgraded in a reasonably straight-forward way, just follow the documentation (well and a few blog posts here and there for the things missed in the official docs). But all the additional Gems, and dependencies of those Gems (and so on) made the process excruciating. Many things broke in subtle ways at runtime (no compilation, so no compiler errors) and there was no clear path to upgrade; because whilst Rails' upgrade path is documented, there's a plethora of Gems that also needed to be upgraded separately (some in contradictory manners). You might wonder why I was so out of date in the first place. Two reasons: 1. I inherited this code-base. 2. I've attempted this (or a similar) upgrade about 5 other times in the past; spending hours upon hours debugging crashes (or just weird behaviour) with enormous stack-traces where my application's own code often doesn't even appear in the stack trace. It's only now after making several failed (or rather overly time consuming) attempts I was able to come up with a "workable" upgrade path. Gems dynamically generating methods left, right and centre, Gems replacing methods of seemingly unrelated classes (when they definitely do not need to), and crazy "conventions" that hide all the actual logic make debugging any sizeable Rails project a complete disaster. Don't even get me started on the poor performance, much of which is to do with poorly designed Gems and not even the Ruby interpreter's fault. That said... I still turn to Rails when I want to get a new project (with users, database, login, admin etc.) up and running quickly. It's a shame, but in terms of development speed, it's hard to beat Ruby (and Rails). For small projects Sinatra is very solid, and Padrino is interesting - but honestly I can't wait for the day I can move to a compiled language and still achieve this sort of development speed.

heartbreak 10y ago
I hear horror stories like this, and I have one of my own. 1. Absolutely no tests of any kind 2. Over 100 gem dependencies Upgrade from 3.2.x to 4.2.x took one developer (me) three weeks of work. I don't know if that's a lot or not, given the major version upgrade and all of the gems (which were a huge pain). I've not had any problems in production reported via Honeybadger or by end users, so I think the upgrade was a success. I did end up writing about 200 unit and integration specs during the process. I'm thinking back to my days in the .Net world at BigCorp. Unfortunately I have nothing to compare it to, because we never upgraded anything from one major version of ASP.NET MVC to another. Is that a better situation?

zacharypinter 10y ago

It seems to me that a version of the Innovator's Dilemma might apply to software frameworks as well. By the time a project gets large enough it starts optimizing for its major stakeholders. New use cases or new ways of rethinking common use cases come along, and the small libraries that approach it from scratch have a narrowly-defined advantage. If the advantage is significant enough (e. g. virtual dom for browser UI), then new frameworks start being written around them, bringing back some but not all of the features of the older frameworks. At some point (different for each user/use case) the newer frameworks have enough functionality that people start considering them over the older ones for new projects. When enough of that happens, the older frameworks start looking like yesterday's software.

deleted 10y ago

[deleted]

mpdehaan2 10y ago

In the original article, he indicates Swift, Rust, and Go are tomorrow's languages. The issue really is that the level of support in the various frameworks, the eons of bug-crushing and feature additions, and the libraries available, are going to be behind for some time. This is why I'd still gladly pick Django today. What is "the future" isn't really so interesting as what is productive. Yes, performance matters a bit, but development time is usually much more expensive than adding a few nodes to an autoscaling group, and not worth the cost of using less fleshed out libraries.

weberc2 10y ago
In my experience as a professional Python dev and a hobbyist Gopher, Go's libraries are a lot less convoluted than Python libraries. In Python, you see a lot of libs that try to do everything for everyone (think long args lists and functions that try to guess the right thing to do based on arg types) whereas Go libraries just kind of snap together neatly. Go tends to be more productive for me than Python specifically because its philosophy values simplicity and orthogonality over complexity and scope breadth. > Yes, performance matters a bit, but development time is usually much more expensive than adding a few nodes to an autoscaling group, and not worth the cost of using less fleshed out libraries. Sequentially, Go outperforms Python and other interpreted languages by a wide margin (usually a factor of 10). Things get really interesting with Go because it can be massively concurrent without messing around with large async refactors. At work, we're hoping our first iteration (i.e., before any async refactors) of our Python application to handle something like 5-10 concurrent requests per machine (without degrading response times), but I'm confident a single Go process could handle at least 10X that load with better response times. This order-of-magnitude difference seems fundamentally different from the perspective of "throwing hardware at the problem". Further, Go's library story is fairly complete (for web services; GUIs and other domains are still lacking)--at least it's been a long while since I've lacked a complete library for some task.
- mpdehaan2 10y ago
  Again, performance isn't everything. Go has specialized a bit towards low-level operations, and I tend to strongly dislike what it does with exceptions and the way those involved veto language features. As for libraries, I'm talking about things on the level of, say, Django or ORMs.

noamsml 10y ago

I feel like this is a terribly lacking reply. I'm not a trend-person by any mean: I'm a deep-backend developer, and my main language right now is Java[1]. However, when I have to maintain rails apps, even well-written ones, I find myself frustrated. I think ceding the advantages of a compiler is a fundamental mistake. Compilers and static checkers make for better software more easily; they don't replace tests, but they complement them and constitute compilable documentation for your code, enhancing its maintainability considerably. [1] I write in Java because I work for a Java shop, but even if I had my choice of languages, I'd probably be using either Swift or a compile-to-JVM language.

xaduha 10y ago

Rails wasn't even the best choice when it appeared.

domador 10y ago
What would you say was the best choice when Rails appeared? Since then, has Rails been the best choice at any point, in your opinion?

qaq 10y ago

The thing is in many cases you had to make a choice between performance and productivity. With things like Elixir/Phoenix you don't really have to make that choice. Maturity argument again is moot as you are building on top of Erlang/BEAM that's very mature and has very good tooling. For people coming from Ruby the syntax also makes transitioning less of a pain.

dschiptsov 10y ago

There is, perhaps, a law, such that any project with a strong tendency to pile up more crap instead of reducing it to "just right, when nothing else could be removed" (a-la 9P2000 protocol, and few foundation libs of Plan9) will end up in a J2EE-like pile of collective stupidity. At least, everything in nature tends to get reduced to a local optimum by a straightforward optimization process of trial and error. There is no way to make a reliable and efficient complex system by piling up more and more crap. And, funny enough, JavaScript will be even worse - it already makes J2EE look not that bad.)

TheOtherHobbes 10y ago
This should be studied in comp sci. Instead of building compilers and interpreters in the abstract, there should be a serious study of how languages/frameworks are created and developed in the wild. I suspect there are easily visible patterns and trends, and they tend to repeat over and over. The corollary is that specific languages can't fix cultural issues unless they're designed to do that.

willvarfar 10y ago

The problem I feel with Ruby and RoR apps is that people bang gems together without knowing how those gems do what they promise to do, what those gems depend upon, what those gems monkey patch, what they change. Further down the road, maintenance drowns you. I've rallied against this mindset before, e.g. regards security http://williamedwardscoder.tumblr.com/post/43394068341/rubys-principle-of-too-much-power http://williamedwardscoder.tumblr.com/post/43394068341/rubys... I find large Python apps fairly unmaintainable too, but to a much lesser degree.

brightball 10y ago

At the moment, the alternatives mentioned to Rails aren't actually alternatives. You are still going to make major trade offs in productivity compared to Rails... Unless he's talking about Elixir and Phoenix, which IMHO is the future of web development.

DevinTheDude 10y ago
As someone who has never heard of Elixir/Phoenix, why do you think it's the future. What does it do better than Rails? I'm looking to start a new web application, and I'm open to new technologies.
- brightball 10y ago
  Elixir is a nicer to work with language that Erlang that compiles down to the Erlang VM. That gives it a better concurrency model and fault tolerance than Go. Rails core team members have been building Phoenix. It's syntax is built to be extremely familiar to Rails but it's been built from the ground up to correct a lot of core issues that come up long term with Rails. It's basically fast Rails. You get a very equivalent level of productivity with performance and fault tolerance of Erlang. Benchmarks show performance on par with Go. It's really fascinating. I've been programming professionally for about 17 years now and it's the first time I've been truly excited about a language for a long time.
  - DevinTheDude 10y ago
    First, thanks for taking the time to answer my question, I'm at my day job (I program at night) so I can't do much research >correct a lot of core issues that come up long term with Rails. I've never gotten to this point, what are some of these issues? From reading comments here, it seems like dependency hell could be one, but what do you think? I've had issues in my short time with outdated gems, but I don't know if this is necessarily an issue with the framework/language.
    - brightball 10y ago

payne92 10y ago

As more of the computational elements of UIs shift from server-side HTML to client-side Javascript, server-side frameworks like Rails, Django, PHP, etc. become less relevant. Fast forwarding, many apps are (or will be) big JS blobs using APIs/microservices back to the server. In that version of the future, frameworks like Rails can get in the way more than they help.

0xfaded 10y ago

Dynamic languages reduce the formal overhead required to develop new ideas. I can't imagine that an "eliminate boilerplate via convention at the cost of explicitness" mentality would have evolved independently in a world where assurances are earned by proving extra properties to the compiler. However mordern compiled languages now formalise the shortcuts afforded by dynamic languages, e.g. type inference, generics, implicit conversions, typesafe macros, type classes, etc. Similarily conventions popularised by rails-esqe frameworks are being formalised using the tools listed above. I fall into the scala camp, but have used rails at a previous job. My guess is I need 1.5x scala lines vs Ruby which I believe is a justified cost. Opinions of course vary.

methehack 10y ago

Anyone finding any of this resonating really owes it to themselves to try elixir / phoenix and, at the very least, keep an eye on it.

ryanmarsh 10y ago

Many of the complaints against Rails in this HN discussion are around code base maintainability, gem proliferation, and amateurs. Any tool that allows the rapid (almost effortless) accretion of complexity will suffer these problems. It goes with the territory.

wvenable 10y ago
I think that's a good point. JavaScript with Node is arguably worse than Rails for exactly that reason.

k__ 10y ago

why do most people only see the extremes? you don't have to use bleeding egde libs instead of rails... hapi instead of koa react instead of cycle ember instead of react etc...

piotrkubisa 10y ago
Because we do love them, just like Vim vs Emacs, PHP vs Ruby, Go vs Elixir, jQuery vs React... But there is always something what I personally find very positive between all these differences. Please look at Windows and the Linux - some years ago we got used to installing a dual-boot environments and now we may experience Canonical's Ubuntu on Windows with real Bash.

shams93 10y ago

I've seen the biggest benefit from a client heavy approach even with rails. Make the api the core of your system, makes it easier to refactor down the road into microservices. For a lot of web apps there is no real need for server side templating, once you get beyond server templating its easier to make native versions of your app or use xamarian to access the same api from a common c# codebase for native. Place your business logic in the api and there's really nothing for someone to steal from view source because your clients are just REST wrappers.

padseeker 10y ago

I have to say I'm loving reading the thoughtful and insightful comments on this thread. With any programming language and/or framework you have to pick your poison. Rails backloads a lot of big development obstacles that ultimately you may never actually encounter in the life of your app. The issue regarding gems can be aggravating. But the speed in which you can get your app built cannot be understated. Rails is not a one size fits all, and you might eventually outgrow rails (i.e. Twitter). Be grateful the framework got you to the point you could outgrow it, rails helped you get there.

lo_fye 10y ago

PHP is the day before yesterday's software, but it still gets a shitload of profitable work done.

mmedley 10y ago

It simply boils down to what you're most proficient with. Depending on the problem, you're likely to encounter some technologies are better suited than others. That to me is where you'll get the most bang for the buck, being able to decide on the right tool for the problem.

ksec 10y ago

Sometimes I wonder if Ruby and Rails is 5x faster then now by default and allow really simple scaling without much thoughts, would it still get so much critics? Most of the time People will answer saying moving away from Rails as you scale is a good problem to have. But the day Rails isn't fast enough or scale easy enough is coming a lot quicker as the Internet Population expands. And the good old saying of passing this to Morre's Law no longer works as we haven't had much CPU improvement. I am hoping JRuby with Graal and Truffle will fix that.