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

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

#111

Post by hkarthik » Mon, May 09, 2016, 7:42 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…

Any sufficiently complicated Sinatra app contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Rails.

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

#112

Post by mcknz » Mon, May 09, 2016, 7:43 PM UTC

tra3 wrote: post #54

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

Here's the video: https://www.youtube.com/watch?v=0MojR1XUEc0 As an aside, how do people consume slide decks? It doesn't seem as interesting without the associated lecture...

Decks are only consumable if they have:

   1. extensive speaker notes included as an addendum

   2. all of the content on the slides (which usually makes for a bad presentation)

Some presenters will have 2 versions of their decks -- one minimal version for the presentation, and one extended or enhanced version for later reference.

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

#113

Post by ake1 » Mon, May 09, 2016, 7:43 PM UTC

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.

and if you need to shave a couple of minutes off of that there's always http://start.spring.io/

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

#114

Post by humbleMouse » Mon, May 09, 2016, 7:45 PM UTC

olavgg wrote: post #85

humbleMouse wrote: post #66

Earlier quoted context omitted.

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?

And Grails is very similar to Rails, and you get the full power of the JVM/Spring technology stack. And Groovy is a fantastic language that gives you the flexibility everyone like to dream about.

Groovy is amazing. It's like javascript and Java had a beautiful baby that lets you compile either dynamically or statically.

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

#115

Post by davidw » Mon, May 09, 2016, 7:50 PM UTC

zdrummond wrote: post #107

marshray wrote: post #92

Earlier quoted context omitted.

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.

Exactly, and it needs underlining and saying again and again: it's very, very unlikely that your app will ever need to scale like Twitter.

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

#116

Post by joshvm » Mon, May 09, 2016, 7:56 PM UTC

vosper wrote: post #11

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…

> The problem comes when you rely on adding packages that just talk directly to your framework (like Django middleware). Once you do that a few times, you really don't know what's going on between a web request hitting your server, and your own code running I think this is where the lack of strict typing can make things harder to figure out. Especially if you're trying to understand middleware functions with opaque s…

The key is consistency I think. For matplotlib (which is probably one of the most commonly used modules that heavily uses args and kwargs), it's really useful. On the other hand it's only useful because their web documentation is really good and most of the time the args/kwargs are consistent between functions.

It also helps that most matplotlib kwargs can be controlled using an additional function, if you have a reference to the line/plot you want to modify. So you could do:

    plt.plot(range(10), ls='solid')

or equally:

    lines = plt.plot(range(10))
    lines[0].set_linestyle('solid')

But in the end it comes down to documentation. I think Python traces are generally pretty good at telling you what you did wrong.

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

#117

Post by shimon » Mon, May 09, 2016, 7:58 PM UTC

adamors wrote: post #108

marshray wrote: post #92

Earlier quoted context omitted.

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.

Your statement is too cautious. At the start of a project, getting to market quickly is VIRTUALLY ALWAYS more important than handling Twitter-scale traffic. People are simultaneously confident their idea will be popular and afraid of failure, so we have a strong tendency to over-engineer for scale.

If it does scale, don't be surprised if you have to toss out your v1 and rebuild. The difference between a good framework and a bad one isn't about whether it survives scaling; it's about the details of when it fails, how it fails, and whether you can fix it incrementally or if you're signing up for a rewrite-while-hair-on-fire.

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

#118

Post by marcosdumay » Mon, May 09, 2016, 8:00 PM UTC

elcapitan wrote: post #16

vosper wrote: post #11

Earlier quoted context omitted.

> The problem comes when you rely on adding packages that just talk directly to your framework (like Django middleware). Once you do that a few times, you really don't know what's going on between a web request hitting your server, and your own code running I think this is where the lack of strict typing can make things harder to figure out. Especially if you're trying to understand middleware functions with opaque s…

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

The problem is accepting/returning a wide and disjoint type set, together with metaprograming itself.

Static typed languages tend to require that code deals with only a restrict set of types, and avoid metaprograming in exchange of other kinds of code abstraction.

I don't think this specific problem is big, tough. The dependencies one, by its turn, is huge.

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

#119

Post by geebee » Mon, May 09, 2016, 8:00 PM UTC

crdoconnor wrote: post #91

geebee wrote: post #84

Earlier quoted context omitted.

Activereord certainly saves me a lot of time. I think the reason orms get a lot of flak is that people see them usedin wildly inefficient ways that could have been solved with a simple join or other basic sql operation. Or alternatively people to to comical levels of twister to stay within the framework and create a parallel implementation of Sal. But yeah if you use them judiciously they can remove some drudgery.

If your ORM can't handle joins you're just using a bad ORM, period. Pick a better one.

I can't think of an orm that can't handle joins. I can think of way that relatively inexperienced devs might use an orm in a day that doesn't take proper advantage of it though (seen it). I don't see this as a reason to avoid an orm of course. In rails it's pretty trivial to load associations most of the time.

There are also some queries that I think are best handled by find by sql oreven just raw sql. Sometimes this is performance othertimes it's for clarity.

Overall if you use an form properly I think it can save time and improve clarity.

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

#120

Post by tunesmith » Mon, May 09, 2016, 8:02 PM UTC

abc_lisper wrote: post #97

tunesmith wrote: post #63

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

How about writing tests that enforce invariants? I have been doing clojure dev for a little bit, and here's what I do - - Run tests in the background continuously (lein expectations will give you that. or you can write your own shell script) - Do small checkins, frequently to git - Write tests that enforce invariants. Haven't gotten to test check yet - but I guess that would be even better. The trouble with types is…

I've honestly never felt like types have gotten in the way. I also write plenty of tests with plenty of mocking, it's just that the type system means we don't have to write tests for the things the type checker checks for.

I'm having trouble thinking of a time when I felt something akin to what you describe with zombie constraints. If anything, having a good type system makes it easier to rip out code that isn't used anymore. And Generics can help with keeping your solution from getting too specific.