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

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

codethinked.com

Post reply on HN
Print view View original

81–90 of 219 posts

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

#81

Post by blub »

forgotpwtomain wrote: post #42
blub wrote: post #30

Earlier quoted context omitted.

Why not? I would be curious to see how people tackle large, complex web software in an efficient way - that is with tools support, not by fighting against them and working around inadequacies. Example: if the unit tests represent 50%+ of the code base, one is probably working around dynamic typing. And here's some examples of complex software for comparison: image editor, digital audio workstation, CAD, video confere…

> Example: if the unit tests represent 50%+ of the code base, one is probably working around dynamic typing Unit tests are checking a lot more than argument type.. I have no idea what environment you worked in, but the comment comes across as rather clueless.

The 50% heuristic comes from a story I read once about a company claiming they were able to build a ~200 kloc app in a dynamic-typed language.

The secret was their ~200 kloc unit test suite. :)

It has nothing to do with argument types per se, just that one must have very high coverage in order to be able to be reasonably sure that their app won't crash after minor code changes.

In my current project we can get away with having integration tests cover a lot of ground and only unit test what makes sense thanks to static typing. High coverage is good to have, but should be balanced with test development and maintenance effort.

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

#82

Post by matwood »

blub wrote: post #6

This is the old "use the right tool for the job" cop-out. The original post went deeper than that. I would summarize it like this: can modern complex, large-scale web apps be built with the tools we have today, be they Python, Ruby or Javascript? Or do we need an entire new class of tools which have traditionally been used to build large scale systems in the past? It's a multi-faceted question of type systems, toolin…

Is Java really that unusual of tool? Java 8 + Spring boot + Jooq is a simple and powerful tool to build backend services. There is already great tooling, libraries, and a wealth of information around solved problems. Dare I say, it is almost boring to build backend services with the above stack because it is so straight forward. Maybe that is why it is not used, I mean talked about :)

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

#83

Post by mpdehaan2 »

In the original article, he indicates Swift, Rust, and Go are tomorrow's languages. The issue really is that the level of support in the various frameworks, the eons of bug-crushing and feature additions, and the libraries available, are going to be behind for some time. This is why I'd still gladly pick Django today.

What is "the future" isn't really so interesting as what is productive.

Yes, performance matters a bit, but development time is usually much more expensive than adding a few nodes to an autoscaling group, and not worth the cost of using less fleshed out libraries.

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

#84

Post by jjnoakes »

lubonay wrote: post #24
Karunamon wrote: post #12

Earlier quoted context omitted.

Sometimes that's exactly what it means. The reason you see frameworks like Rails catching on, slow and bloated as it can be (and I say this as someone that loves the RoR ecosystem), is that developer time is generally more expensive than CPU time.

Couldn't agree more. Business (the people who pay us to code) generally doesn't care about performance if it's "good enough to ship". Time to market, on the other hand, is a matter of life and death.

Life and death also hang on other factors that swing the argument in the other direction, like can you scale quickly if you are the next big thing, are you stable, is your uptime acceptable, are there huge security holes that can tear your company to the ground over night...

Speaking in generalities isn't very useful.

Each project has to weigh the pros and cons of each decision. It's basic engineering.

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

#85

Post by manifestsilence »

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 happened to be on the losing side of history. Compile-time errors are definitely easier to find, but the path to fixing them can be just as bad. What I really long for is good documentation and a clear path forward for each breaking change.

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

#86

Post by beat »

heartbreak wrote: post #75
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 hear horror stories like this, and I have one of my own. 1. Absolutely no tests of any kind 2. Over 100 gem dependencies Upgrade from 3.2.x to 4.2.x took one developer (me) three weeks of work. I don't know if that's a lot or not, given the major version upgrade and all of the gems (which were a huge pain). I've not had any problems in production reported via Honeybadger or by end users, so I think the upgrade was…

A huge upgrade on code with no tests and a bunch of magical dependencies?

The problem wasn't Rails there.

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

#87

Post by noamsml »

I feel like this is a terribly lacking reply. I'm not a trend-person by any mean: I'm a deep-backend developer, and my main language right now is Java[1]. However, when I have to maintain rails apps, even well-written ones, I find myself frustrated. I think ceding the advantages of a compiler is a fundamental mistake. Compilers and static checkers make for better software more easily; they don't replace tests, but they complement them and constitute compilable documentation for your code, enhancing its maintainability considerably.

[1] I write in Java because I work for a Java shop, but even if I had my choice of languages, I'd probably be using either Swift or a compile-to-JVM language.

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

#88

Post by r-s »

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 Rails, for the most part I find it just works. When projects get to a certain size, very roughly around 50k loc, they become very slow to work on. Slow test suites and dependency hell become problems.

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

#89

Post by weberc2 »

collyw wrote: post #34
mbell wrote: post #16

Earlier quoted context omitted.

> The original post went deeper than that. If there was depth, I missed it. The only two points I got from it were 'I prefer static typing over duck typing' and 'avoid dependency hell'. The original post didn't add anything new to either argument and both have existed and been rehashed over and over again for decades.

And he didn't point out how any of his "todays languages" are any better at avoiding dependency hell.

Go statically compiles everything into a single binary. I'm not sure what is meant by "dependency hell", but this at least simplifies the runtime story.

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

#90

Post by Tenhundfeld »

askyourmother wrote: post #57
Tenhundfeld wrote: post #52

Earlier quoted context omitted.

Your comment comes across as narrow-minded and frankly, a bit arrogant. It is just so dismissive. Rails's original popularity came from developers fleeing the excessive ceremony and boilerplate code of enterprise Java – and .NET to some extent. Sure, there are some inexperienced (or simply bad) developers in the Rails community, just as there are in every community. But most of the Rails developers I've met also have…

Uhhm, it certainly is about magic, it's creator goes on about that quite a bit. So the happy meal developers don't really have to know how to code. Just install these gems, copy these incantations from the pragprog book, you too can have your site in five minutes. You don't need to understand the shiny magic, I mean, it detracts from being saying "I'm a Rails developer", but maybe it would help if they did.

I'm curious to see examples of the shiny magic you're talking about. Honestly. I can think of some conventions that seemed a little magical at first but make more sense once you understand what's really happening under the hood.

Have you worked much in Rails? I'm asking, because it sounds like your exposure is mostly from demos and blog posts, which are obviously going to use the five-minute, "happy meal" examples. A complex, real-world application is very different from a presentation where somebody whips together a blog engine in 15 minutes. For example, I can't remember the last time I saw somebody use the scaffold generator for production functionality, other than maybe for temporarily mocking up some functionality for stakeholder feedback.

I'm wondering if some of our difference in opinion is just based on Rails appearing easy to use. Take ActiveRecord for example. Sure, you don't need to understand SQL and database engines to get started using it, but if you're going to build anything serious, you better understand how to drop down to raw SQL when necessary, how indexing works in a RDBMS, etc. I personally think ActiveRecord, while a bit bloated, is a great mix of making the simple stuff extremely easy and getting out of my way when I need to do something more sophisticated.

And I think that applies to Rails overall. It makes the simple, routine stuff very easy, and it lets me do more sophisticated things with minimum complexity overhead.

All of that said, my opinion is based on my experiences. It sounds like you've seen/had other experiences with Rails, maybe systems built by less mature developers. I've inherited some bad Rails systems, but I've inherited just-as-bad systems built in Java, .NET, PHP, Javascript, etc.

Post reply on HN