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

Today I accept that Rails is yesterday’s software

medium.com

Post reply on HN
Print view View original

61–70 of 166 posts

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

#61

Post by crdoconnor »

vosper wrote: post #43
elcapitan wrote: post #16

Earlier quoted context omitted.

But is that really a problem of non-strict typing, or rather a problem of metaprogramming? I could imagine even a very strongly typed system in Haskell or Scala would probably be hard for an IDE to support if it uses a lot of complex abstractions to create internal DSLs (like Rails and I guess Django as well do).

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.

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

#63

Post by tunesmith »

I've been doing enterprise backend development (java/spring, scala, akka) for a while and occasionally miss the practice of sitting down and creating a fullstack app myself, which I used to do with php and crappy html. But then I sit down and try to work with existing Ruby/Rails codebases and hit a mental block.

I guess example #1 is method_missing. I get it, it's a huge time-saver and lets you do all kinds of cool things like specify a default behavior for an API if someone sends a random command, or, define the behavior of a method dynamically by the name of the phantom method. But then the rest of me is reflexively saying, "Seriously??" And I get that Spring Data does sort of the same thing, but at least there it's limited by domain. If I'm in a Ruby codebase that is taking regular advantage of that, my first instinct would be find calls that eventually go to method_missing, and then just define the damn method somewhere so that my IDE's "Find Usage" will work again. How the heck do you explore a codebase quickly if your IDE doesn't work?

I guess for me it just reinforces the same rules of thumb. Dynamic languages are fine if you're prototyping or doing an MVP. But as soon as you find that your codebase is being read/maintained more often than it's being written (which will happen sooner than you think), or as soon as you start finding weird production runtime bugs that don't happen in your local environment, you're better off with something strong or static or compiled.

As for how to get that safety full-stack these days, I'm still poking around. Scalajs seems interesting, or Angular2 with Typescript, or something that uses RxJs...

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

#64

Post by mirekrusin »

rahimnathwani wrote: post #3

The article seems to be lamenting three things: 1) Batteries-included web frameworks (like Rails and Django) 2) Interpreted languages without strict typing (like Ruby and Python) 3) Programmers relying on large numbers of dependencies (e.g. ruby gems), and the resulting difficulty in reasoning about the software The last paragraph then goes on to suggest that different languages are required. This seems wrong. If you…

Assembler solves all 3 of those problems, right?

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

#65

Post by bphogan »

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 may vary. :)

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

#66

Post by humbleMouse »

tootie wrote: post #25

Just use Java people. You can bootstrap a Spring project in 10 minutes and it will have every feature (ORM, security, caching, MVC) available with just a maven dependency or you can roll your own and it will work fine. Strong typing, good performance, sensible stack traces (if you don't overdo annotations) and all the testing and monitoring tools you could ever dream of.

This comment is what I feel like replying with to every article about some "fast iterating" language. IMO the only reason to use rails if you don't actually understand how web development actually works. Why would you pick a slower language and platform like ruby/rails when java/spring is right there available to anyone?

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

#67

Post by dasil003 »

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…

Okay, I'll bite: what's your web framework of choice?

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

#68

Post by askyourmother »

xutopia wrote: post #49
icpmacdo wrote: post #18

I am thinking about completely stopping reading Hacker News. I enjoy the community a lot but every time I am learning something new I read about how its old and shitty and will cause hair loss when you try and invest any time in it. It puts the breaks on actually learning with the distraction of going and trying to find that new ambiguous stack that the author is hinting at.

Rails has a bright future ahead despite what this article states. Consider for a moment that most projects just need to figure out product-market fit before we know where to throw the money to scale. 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 regardl…

Sure now it is Rails 5 - enterprise Rails strikes back! Seriously though, I am looking forward to Rails 8 - with the ActionSecurityHolePipeline.

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

#69

Post by geebee »

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...

Yep!

Nothing wrong with yesterday's technology if you're solving yesterday's problems! I don't mean that in a sarcastic or glib way, most of your problems really are yesterday's problems. Or even yesteryear's problems…. now that I think of it, when I depart from rails in a rails project (which is common), it's usually to use raw sql, unix, various networking protocols, or other programming languages that predate rails and ruby.

There was a good book out recently from pragmatic bookshelf called "rails angular postgres and bootstrap". Not saying you should necessarily use this stack (I don't), but the idea that you don't need to do everything in rails to use rails is worth listening to.

Generally, you're going to want to go back in time, to use tools that were designed for even older problems. For instance, why reinvent sql in a new language? If it's convenient to use active record and there's no performance hit, ok, use it, but don't go into contortions to avoid sql.

On a similar note, for those parts of a project where you really should go forward in time and start using tools that haven't withstood the test of time, by all means, go for it. But you aren't obligated to write the other 95% of the project in some new framework.

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

#70

Post by davidw »

xutopia wrote: post #49
icpmacdo wrote: post #18

I am thinking about completely stopping reading Hacker News. I enjoy the community a lot but every time I am learning something new I read about how its old and shitty and will cause hair loss when you try and invest any time in it. It puts the breaks on actually learning with the distraction of going and trying to find that new ambiguous stack that the author is hinting at.

Rails has a bright future ahead despite what this article states. Consider for a moment that most projects just need to figure out product-market fit before we know where to throw the money to scale. 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 regardl…

> 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 mean, heck, Twitter started with Rails, and despite some hiccups, managed to grow. And Twitter is pretty much the poster child for something that has to scale massively. Odds are, you won't have the same problem.

Post reply on HN