After reading “Rails is yesterday’s software”, I need to reply • Hacker News Board

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

#131

Post by barrkel » Wed, May 11, 2016, 4:27 PM UTC

r-s wrote: post #88

Benjamin_Dobell wrote: post #67

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 excruc…

I have upgraded a very large Rails 3.2 app to 4.2 recently. It was about 2 weeks solid of work for my team. It was a project I inherited and when I got it the test suite took an hour to run. The biggest problem which I had was dealing with the dependencies. This project used just under 300 gems, many of them unmaintained and a few of them I had to fork to get to work with rails 3. I am very fast making things in Rail…

  $ find -iname '*.rb' | xargs cat | wc -l
  135106

No real problems working with this codebase. ~190 gem dependencies.

Mind, most of the code is tests:

  $ find -iname '*.rb' | grep /spec/ | xargs cat | wc -l
  96899

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

#132

Post by akmiller » Wed, May 11, 2016, 4:28 PM UTC

dcrall wrote: post #71

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…

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.

I've been doing Clojure for the better part of 3 years now and I'm not sure I get why people feel doing web development in Clojure is hard. Our first foray in Clojure was/is an API to manage our users that was built by 2 developers who were new to the language and has been running largely unmodified since being released.

I actually believe the opposite. Jumping into and doing Clojure web development is extremely simple at the core. The issue with frameworks like Rails (and I'm not against Rails as I have used it on multiple successful projects and still think it's great) is that you get so much for free and don't have to understand how all the pieces fit and work together (at least initially). Soon enough you have to have more knowledge of that and that's were the complexity comes in.

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

#133

Post by noam87 » Wed, May 11, 2016, 4:35 PM UTC

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…

Elixir/Phoenix gets this right. Working on a side project right now and so far it's a very enjoyable experience.

I find the abstractions much more intuitive. The framework as a whole is just as "magical" for fast prototyping, but it's composed of much simpler individual modules that are easy to wrap one's head around.

It's surprising how mature the whole ecosystem feels considering it's still quite niche. It helps to have decades of battle-tested Erlang libraries at your disposal.

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

#134

Post by spdionis » Wed, May 11, 2016, 4:37 PM UTC

discordance wrote: post #104

tim333 wrote: post #98

Earlier quoted context omitted.

Also PHP still powers much of the web and has taken a step forward with PHP 7 which seems to run a good bit faster than Ruby and the like.

Mostly because of one application (Wordpress).

It runs a bit faster because of wordpress? :)

Assuming you were answering to your GP, modern PHP is a totally fine language to program in with a lot of upsides (that would take too muh to enumerate here).

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

#135

Post by borkborkbork » Wed, May 11, 2016, 4:37 PM UTC

busterarm wrote: post #109

engineerDave wrote: post #102

Earlier quoted context omitted.

The main problem I see in the ruby community, in this regard, is the willingness to make breaking changes and justify it via Semantic Versioning. While on the surface this seems ok the underlying problem, as I see it, is the old version isn't maintained, so essentially the only maintained version now has breaking API changes. There are few ways this could be addressed, e.g. separate branches for old gems, and some de…

I think this is the source of the early focus on unit testing in the Ruby community. The problem is a lot of Ruby developers have not felt this pain yet and eschew testing because they work in startups that are in a state of permanent death-march. A little (okay, a lot) of unit testing goes a long way to ease this pain. The people making breaking changes in their gems usually/hopefully have good testing in place and…

I went through the same upgrade process that the OP mentioned at scale. The company had 5 or 6 microservices that needed to be upgraded from Rails 3.1. While having 10,000+ unit tests was very helpful for reducing regressions, we still had several huge problems:

1) We couldn't be sure that we hadn't broken something because we knew we didn't have 100% test coverage.

2) Some of the gems we depended on conflicted so severely that we had to rip them out and implement the solution ourselves or pick a different gem.

3) Our tests themselves of course contained code with breaking API changes. That means we had to maintain the tests as well as the production code through the upgrade, and had to make changes to many of those tests.

All of this uncertainty means that this was not your typical test-driven confident refactor. QA still had to do massive regression testing, and we're pretty sure we introduced at least a new bug or two. It took a pair of devs 4 months of non-stop work to get these services up to Rails 4.1. The upgrade was absolutely necessary as the Rails core team had already stopped fixing major security holes in 3.1 long ago. The company incurred a tremendous cost during this upgrade process. If they would have kept things up to date all along they could've saved money, but of course that would have eaten into the supposed time-savings of Rails.

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

#136

Post by eric_h » Wed, May 11, 2016, 4:38 PM UTC

mordocai wrote: post #101

eric_h wrote: post #94

Earlier quoted context omitted.

There's an argument to be made that Rails, by not actually enforcing conventions like TDD, gives an amateur/impatient developer a very high calibre footgun. Unfortunately, of course, that gun doesn't usually go off until it's handed to someone else.

Is there anything that actually "enforces" TDD? Because if there is I want to stay away from it.

My "enforcing TDD" point was rather tongue in cheek. Really, I was just saying that a rails app of even moderate complexity with no tests is a very dangerous beast, and something I would not wish upon my worst enemies.

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

#137

Post by jcyw » Wed, May 11, 2016, 4:40 PM UTC

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.

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.

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

#138

Post by ktRolster » Wed, May 11, 2016, 4:44 PM UTC

manifestsilence wrote: post #85

Benjamin_Dobell wrote: post #67

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 excruc…

I've found upgrade hell can apply to C#/dotnet stuff too. I work on a project that has attempted to upgrade Entity framework versions multiple times and keeps pushing it off because we get buried in compile time errors. It's a case where Microsoft supported several different paths to architect an app and then quietly deprecated half of them - database first vs. code first, POCOs vs. ObjectContext, etc. and we happene…

Indeed, Microsoft's lack of commitment to APIs is what inspired Joel's famous essay: http://www.joelonsoftware.com/articles/APIWar.html

IMHO .net has lost some stability with the recent packaging systems like NuGet and chocolatey; they don't really encourage stability.

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

#139

Post by busterarm » Wed, May 11, 2016, 4:44 PM UTC

borkborkbork wrote: post #135

busterarm wrote: post #109

Earlier quoted context omitted.

I think this is the source of the early focus on unit testing in the Ruby community. The problem is a lot of Ruby developers have not felt this pain yet and eschew testing because they work in startups that are in a state of permanent death-march. A little (okay, a lot) of unit testing goes a long way to ease this pain. The people making breaking changes in their gems usually/hopefully have good testing in place and…

I went through the same upgrade process that the OP mentioned at scale. The company had 5 or 6 microservices that needed to be upgraded from Rails 3.1. While having 10,000+ unit tests was very helpful for reducing regressions, we still had several huge problems: 1) We couldn't be sure that we hadn't broken something because we knew we didn't have 100% test coverage. 2) Some of the gems we depended on conflicted so se…

I believe it and know that sucked, but unfortunately in Rails 3 we got caught with our collective pants down in terms of security. Nobody competent was really auditing it (as was demonstrated against Github) to match the amount of momentum that it had. I see that as more of a Black Swan event than any inherent problem with the framework (yes, I'm basically blaming its users). This wasn't typical of the Rails 2 to 3 upgrade path and doesn't look like it'll be the 4 to 5 path either...and certainly not for incremental updates.

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

#140

Post by VeejayRampay » Wed, May 11, 2016, 4:48 PM UTC

carsongross wrote: post #13

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_p... ) people are going to migrate back to HTML…

The assets pipeline can be tricky, sure, but it's tackling an issue that is really hard to get right. Routing in Rails on the other hand, I don't really see what's so complicated about it. You define resources, you have namespaces, constraints, the DSL is extremely nice and straightforward, I think it's actually one of the huge successes of Rails as a framework.