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

121–130 of 166 posts

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

#121

Post by ryanbrunner »

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.

Any ORM can handle joins. There are certain types of joins / aggregations / whatever that are harder for ORMs to support, and thinking that this is the fault of the ORM births monstrosities like Hibernate.

ActiveRecord for me hits a sweet spot in that it covers most of what you would need to do day-to-day in SQL and gives you easy ways to bypass it if you need to do something more complicated.

The biggest issue with ActiveRecord IMO is Rails devs who feel that falling down to raw SQL when it's warranted is wrong, and end up building insanely unreadable garbage using ARel (which in and of itself isn't a bad library, but should almost never be used in "high-level" code.)

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

#122

Post by Tenhundfeld »

humbleMouse wrote: post #66
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?

> IMO the only reason to use rails if you don't actually understand how web development actually works.

I'm not following your reasoning. Just because Ruby/Rails runs slower than Java/Spring, why does that mean you "don't understand how web development actually works" if you choose Ruby/Rails?

That's a serious question. Runtime performance of a language/framework is only one small sliver of the overall performance of a large system. And overall runtime performance of a system is only one factor, among many, when choosing the right stack for a business.

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

#123

Post by gedy »

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.

Node.js, it's a great fit because it doesn't try to be much more than a thin framework for web services. The value of code JS sharing between server and client is a bit overblown imho, but sharing same language skills is nice.

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

#124

Post by smrtinsert »

hellofunk wrote: post #27
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…

All 3 of those lamentations could also apply to Clojure, but I don't think anyone who used Clojure would lament it.

Yes they would. The rumblings of clojure and the dynamic language trap are already out there.

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

#125

Post by VLM »

polysaturate wrote: post #9

I…don’t understand the point of the article? Ok Ruby is duck typed and has a dynamic runtime. It has for…all of the time since it was created. Rails has magic… since…all of the time since it was created. I’m not even defending Ruby or Rails here. Use at your own benefit/risk…as with every other programming language and framework.

Its the culture. My first RoR application a decade ago had basically no dependencies. The medium article implies the cool kids won't build an app unless it has enough dependencies to be unmaintainable and undeployable. So either you can't use the cool kids or you can't use the tool, the combo is no longer sustainable, its just done. The high time preference people will insist you install GEMs until the crash, its a technological bubble of sorts.

Also my first CRUD app was very small and boring. That means un-debuggable isn't a big deal. Now apps are huge, therefore undebuggable. Even if you limit external dependencies that doesn't help internal dependencies.

You can prototype things quickly, as long as they're small, featureless, no one uses them, and you don't care how difficult the are to deploy or debug. Other than that, no problem. Hmm.

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

#126

Post by outworlder »

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 last paragraph then goes on to suggest that different languages are required. This seems wrong.

I feel that the programming languages are being used here as proxy for something else: the community surrounding them.

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

#127

Post by meekins »

askyourmother wrote: post #20
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.

If you learn a library, you will always be in the driving seat. If you learn a framework, well, better buckle up, because it is a bumpy ride. Frameworks are like hamburgers at maccy ds - consumption for the masses, no thinking required. Later in life those decisions can be a problem.

It's exactly the attitude you describe what gets people into trouble with frameworks.

Getting up and running and building things on a huge foundation like Rails is easy but you should also act responsibly and take the extra steps required to understand what's going under the hood. The effort of understanding a set of well defined "small" libraries is less daunting than a whole monolithic framework (probably with tons of bells and whistles you rarely even use) but both approaches (compare for example the style of the Clojure web app community vs Rails) have their benefits. A set of libs can be adapted more easily to specific needs and development of each of the individual dependencies can move fast without worrying about the others. On the other hand Rails changes relatively slowly but each Rails app being just another Rails app with all the pieces where you expect them to be can be considered a big plus in maintenance.

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

#128

Post by maaku »

astrodust wrote: post #38
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...

Nails it. There's nothing shameful in using a "boring, not cool" platform to get work done. The pioneer lifestyle is full of risks. Sometimes you want that excitement, other times you have different priorities.

Sometimes you want to read the article.

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

#129

Post by smrtinsert »

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…

The funny thing is with tooling you get the power of being able to instantly refactor your way out of a "zombie constraint" and seeing if you like it.

There is no textual or design pattern alternative to that - ides simply get you there faster and safer.

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

#130

Post by pbowyer »

geebee wrote: post #84
crdoconnor wrote: post #75

Earlier quoted context omitted.

ORMs get a lot of undeserved flak for being considered "training wheels for SQL" but they can save you from writing an awful lot of boilerplate code.

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.

I feel the problem is people go to extremes: either all handmade SQL or all ORM. Mixing both is pragmatic.

Take today's example, using the Doctrine2 ORM. I needed something simple: For every user, find the number of articles belonging to them with a specific status code.

Seems simple. Except the dumb ORM way of count($user->articles) lost the JOIN conditions, and counted every article.

So the 50% way was to use COUNT(article.id) in the query via the ORM. Unfortunately, because it doesn't know where to put the COUNT() value, the ORM destroys the easy usage, and returns a collection of the user object and a scalar value for the COUNT().

I worked with it, but TBH going back to raw SQL in this case would've been much easier.

Pragmatism, the lost art (TM)

Post reply on HN