Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

codethinked.com

Post reply on HN
Print view View original

61–70 of 219 posts

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

#61

Post by stevetrewick »

n0us wrote: post #10

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.

Some transaction you perform today will touch a system running on COBOL. I've come across finance and retail systems that have been running for almost as long as I've been alive, some of it on original hardware [0]. The reason we don't develop anything new in it isn't because it's awful (though it is awful), it's because most of the important things we wrote in it are still working.

[0] Sometimes this is better than the 'N layers of crufty consultant supplied virtualisation' model. Sometimes it is not.

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

#62

Post by vox_mollis »

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.

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

#63

Post by criddell »

lmm wrote: post #48
criddell wrote: post #29

Earlier quoted context omitted.

> In the future it might mean using (gulp) Java + WebAssembly You know, after being out of the Java world for about ten years now, I'm starting to get the itch to use it again. I was one of those people that used to joke about programming in XML, but that's really just a layer of indirection which is often a good solution to a problem. It's a very nice language, is fast, and has so far not been destroyed by Oracle. P…

Let me take the opportunity to plug Scala, which gives you (better than) the expressiveness of Python or Ruby but with (better than) the safety of Java. (OCaml, F# or Haskell are other options in a similar quadrant).

Scala and Clojure are both on my list of things to investigate.

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

#64

Post by danenania »

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.

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

#65

Post by [deleted] »

danenania wrote: post #64

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…

[deleted]

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

#66

Post by olavgg »

criddell wrote: post #29
blub wrote: post #6

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, toolin…

> In the future it might mean using (gulp) Java + WebAssembly You know, after being out of the Java world for about ten years now, I'm starting to get the itch to use it again. I was one of those people that used to joke about programming in XML, but that's really just a layer of indirection which is often a good solution to a problem. It's a very nice language, is fast, and has so far not been destroyed by Oracle. P…

Add Groovy to that, and you have the dynamic typing and flexibility you see in Python and Ruby with Java. JDBC with Groovy SQL or JSON parsing with Groovy's JsonSlurper is a joy to work with.

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

#67

Post by Benjamin_Dobell »

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.

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

#68

Post by smacktoward »

blub wrote: post #6

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, toolin…

Has Rails ever been for "complex, large-scale web apps" though?

My understanding of it has always been that it was for the vast majority of web apps, which are neither particularly complex nor particularly large-scale. Rails was there to help those projects get started easily and iterate rapidly. If your Rails app turned out to be a hit you'd probably need to rewrite it, but that was OK because (1) very few apps qualify as "hits" and (2) only apps that actually get written can become hits, and with Rails it was much easier to turn ideas into functioning code.

Large-scale web apps have their own unique types of problems. New tools may be needed to cope with them, but that's a whole different thing than the problems Rails was created to solve.

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

#69

Post by obstacle1 »

vox_mollis wrote: post #62

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.

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?

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

#70

Post by raverbashing »

danenania wrote: post #64

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…

> 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

Post reply on HN