Today I accept that Rails is yesterday’s software • Hacker News Board

Re: Today I accept that Rails is yesterday’s software

#101

Post by Bartweiss » Mon, May 09, 2016, 7:24 PM UTC

namuol wrote: post #88

calcsam wrote: post #5

Being "yesterday's software" is a necessary step. It's the final part of the Gartner hype cycle: maturity. https://speakerdeck.com/tehviking/surviving-the-framework-hy...

The criticisms made of Rails in the article have nothing to do with its waning hipness. Rails falls into the trap of mistaking "easy" for "simple".

I feel like the comment mistook "yesterday's software" for "boring software", which is usually considered a compliment.

As you say, the actual article is about how Rails has all of yesterday's flaws, which is pretty much the opposite of "reliable and boring".

Re: Today I accept that Rails is yesterday’s software

#102

Post by lmm » Mon, May 09, 2016, 7:26 PM UTC

I've been using Scala for 5+ years now, so for me it's definitely today's software. Spray for REST backends, Wicket for HTML UIs. Clean syntax that can be as expressive as Python or Ruby, but coupled to a type system more powerful and effective than any of Swift, Rust or Go, light enough that you can lift things that had to be "magic" (like database-session-in-view) right up there into the type system.

Re: Today I accept that Rails is yesterday’s software

#103

Post by chrismccord » Mon, May 09, 2016, 7:27 PM UTC

askyourmother wrote: post #12

I remember early Rails, around 0.13, pre RC, the community was small the future seemed bright. Little did we know the horrors of what it would turn into. Most of the professional people left when they saw the security circus, the endless holes and design flaws. I learnt then - avoid any web framework which has pragprog pushing a book behind it. The new one to avoid because the masses are already circling around it is…

Author here. Hawking a book? Are you kidding me? I'm also the creator of Phoenix. I spent two years of my life outside of a FT job to get Phoenix to 1.0. We started a book because first class learning materials outside of the basic online guides is necessary on any platform. I make $3/copy from the book sales, so "hawking" a book does a disservice to me because if this was about money, I wouldn't have spent 8 months of late nights and hundreds of hours working on a book. Please reconsider your argument.

Re: Today I accept that Rails is yesterday’s software

#104

Post by tchow » Mon, May 09, 2016, 7:30 PM UTC

bphogan wrote: post #65

hardwaresofton wrote: post #57

For those that are feeling fatigued from working with and around the magic of Rails, Sinatra is a great choice (in python land Django has an alternative called Flask). http://www.sinatrarb.com/ That said, you will have to re-implement machinery that rails gave you for free. If you're building a simple API, there will be obvious simplicity benefits. If you're trying to build a server-side rendered web application, you…

You will indeed have to re-implement stuff Rails gives you. But more importantly, you will have to maintain it. I maintain a large-ish Sinatra app that should've been done with Rails. Update cycles on the gems are a nightmare. It feels cobbled together. it's a "half baked homegrown version of Rails." Someday I will just move the logic to a new Rails app and be done with it. It was a terrible idea. * your experience m…

What is a large-ish app? Just for comparison's sake?

What makes it large-ish? The number of tables? The number of views?

What is the problem that large-ish apps give that Rails solves?

Genuine questions, I only do small projects and I honestly don't see a huge benefit to using rails, despite having used it before.

Re: Today I accept that Rails is yesterday’s software

#105

Post by spriggan3 » Mon, May 09, 2016, 7:35 PM UTC

zippergz wrote: post #21

Honest question. What technology are people enjoying on the server-side with sites built in React or Angular? I've seen some of these done with Rails, and some done with Node, neither of which I personally enjoy a whole lot. (Note, I'm not making an argument that either are BAD - just that I don't really like working with them). I'm curious to hear what other people are having success with in production.

not production ready but will be soon : asp.net core. If you want something like Rails with a statically typed language like C#, that's you best bet.

Re: Today I accept that Rails is yesterday’s software

#106

Post by vosper » Mon, May 09, 2016, 7:39 PM UTC

crdoconnor wrote: post #61

vosper wrote: post #43

Earlier quoted context omitted.

I can't speak for Rails, but at least with Python (primarily Flask) it's not internal DSLs that have caused me problems. I don't think Flask attempts to be a DSL at all, actually. From what little I've seen of Django it isn't trying to be a DSL either (unless I'm misunderstanding that term). It's more when I have 2 or 3 Flask libraries or middleware and they each are documented as if they exist in a vacuum but I want…

>From what little I've seen of Django it isn't trying to be a DSL either (unless I'm misunderstanding that term). Django bundles two DSLs - the ORM (filter, etc.) and the templating language. >I don't think Flask attempts to be a DSL at all Flask bundles jinja2 and sqlalchemy which perform the same purpose.

Thanks, now I have a better idea of what constitutes a DSL. It had occurred to me that the ORM might be one, but I forgot about Jinja2 which clearly is.

Though, being pedantic, Flask doesn't bundle SQLAlchemy (though it's what you end up using) unless things have changed recently.

Re: Today I accept that Rails is yesterday’s software

#107

Post by zdrummond » Mon, May 09, 2016, 7:39 PM UTC

marshray wrote: post #92

davidw wrote: post #70

Earlier quoted context omitted.

> Rails remains to this day the tool I go to for building web applications because it's so well suited for building something quickly. Sure the effort to make it scale is present but I see any scaling effort as big regardless of framework or language. This is why I continue to use Rails despite being interested in this that and the other new thing. It's very productive in terms of getting something up and running. I…

Twitter is the poster child for dumping Ruby. Even if Rails is God's gift to CRUD app prototyping at some point you have to ask if building a tech stack on something that is going to fail hard as soon as you get popular is providing a good service to those who are paying you for the quality workmanship.

That was not what the commentator was referring to; > "It's very productive in terms of getting something up and running."

Implying that Twitter reached success under Rails, even if it was _not_ the best fit for the problem set.

Dumping Rails when you have won the market is a nice luxury to have, one that most people on HN do not have.

Re: Today I accept that Rails is yesterday’s software

#108

Post by adamors » Mon, May 09, 2016, 7:40 PM UTC

marshray wrote: post #92

davidw wrote: post #70

Earlier quoted context omitted.

> Rails remains to this day the tool I go to for building web applications because it's so well suited for building something quickly. Sure the effort to make it scale is present but I see any scaling effort as big regardless of framework or language. This is why I continue to use Rails despite being interested in this that and the other new thing. It's very productive in terms of getting something up and running. I…

Twitter is the poster child for dumping Ruby. Even if Rails is God's gift to CRUD app prototyping at some point you have to ask if building a tech stack on something that is going to fail hard as soon as you get popular is providing a good service to those who are paying you for the quality workmanship.

Getting to market quickly is often more important than contemplating about handling Twitter like traffic.

Also, I haven't heard of an application that never had to be rewritten partially/optimised after X years in production. Some problems just don't present themselves in the first couple of years.

Re: Today I accept that Rails is yesterday’s software

#109

Post by tankerdude » Mon, May 09, 2016, 7:41 PM UTC

So my question would be, what's the difference between Rails and other frameworks, especially since we are doing RESTful APIs from the start?

It would seem to me that Rails is just not the tool to use going forward for writing APIs for websites at scale. There are much better tools out there.

Rails' sweet spot is server side rendered pages that are quick to bring up and to add features. It seems great for certain types of websites so it does have its niche.

But moving forward, Rails for API vs. other frameworks in other languages is really a wash in terms of productivity, while other frameworks in those other languages are much more highly performant.

Re: Today I accept that Rails is yesterday’s software

#110

Post by btilly » Mon, May 09, 2016, 7:41 PM UTC

The problem comes from this.

1. The costs of any layer of abstraction and magic that we have internalized seem free to us. So we feel free to add a more marginal one.

2. We have little visibility into any layer of the stack above or below ours.

3. As people migrate between languages, they take what they did previously and recreate it. Only "better".

As a result, complexity grows over time. And programmers are really bad at noticing/correcting it. And when they try, they will come up with different prescriptions. Often opposing ones. Explicit is good. (Go.) Don't let people mutate state. (Functional languages.) Convention over configuration. (Rails.) Move work from programmers to IDEs and tooling. (Java.) Make programmers productive so more gets done with less code. (Most scripting languages from Perl on.)

Over my lifetime, I've watched the resulting slide into complexity. Reading up on history I recognize that it had been going on for decades before I learned how to program. And it shows every sign of continuing to accelerate going forward.