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

71–80 of 219 posts

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

#71

Post by dcrall »

danenania wrote: post #64

Moving on from Rails sounds great until you try to build a serious web app with one of the alternatives. While I think that many of the architectural criticisms are valid, Rails demonstrates the primacy of ecosystem and strong conventions over language design and cs theory. 'Tomorrow's' languages and frameworks would do well to take heed. Winning this war has as much to do with culture and marketing as algorithms and…

I agree that Rails' strong opinions are still a strength. I like Clojure a lot, but for someone new to the language trying to get a Clojure web app started is like pulling teeth. Elixir and Phoenix, with their connections to the Ruby community, really get this, and I think they provide a much better introductory experience.

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

#72

Post by neverminder »

lmm wrote: post #48
criddell wrote: post #29

Earlier quoted context omitted.

> In the future it might mean using (gulp) Java + WebAssembly You know, after being out of the Java world for about ten years now, I'm starting to get the itch to use it again. I was one of those people that used to joke about programming in XML, but that's really just a layer of indirection which is often a good solution to a problem. It's a very nice language, is fast, and has so far not been destroyed by Oracle. P…

Let me take the opportunity to plug Scala, which gives you (better than) the expressiveness of Python or Ruby but with (better than) the safety of Java. (OCaml, F# or Haskell are other options in a similar quadrant).

Scala + Play Framework, which incidentally was inspired by Rails, however in my opinion is much more consistent amongst other things.

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

#73

Post by Xylakant »

toolz wrote: post #60
cdnsteve wrote: post #53

"makes it easy to install 1,000 gems into your project without a single line of configuration, is exactly why it’s hard to debug". This "let someone else do the work, get it from a gem" mindset is what kills long lived projects. It has nothing to do with the tools and everything to do with experience. You don't need 1000 gems. Managing anything more than core dependancies in a project can easily create exponential bu…

I work on some really big projects in the wild for various clients in ruby on rails and they have so many gems that often I find unused gems they are afraid to remove them in case it actually is being used, but you know what? They were moving forward with features - their user base was happy and their product worked for the most part. You know what kinds of projects I see fail? The ones who try to architect everythin…

> often I find unused gems they are afraid to remove them in case it actually is being used,

I've worked on code-bases of small to medium size where people were afraid to remove self-written code because nobody knew if the code is actually called somewhere. It's not actually the gem that's the problem - it's being diligent. If you need a gem's function add it as top level dependency, don't rely on some other gem depending on it. require the code explicitly everywhere you use it. That way you can at least search your code base for it. Be equally diligent when removing code: Remove all code that only this code depended on. Other than that: Don't be afraid to break stuff.

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

#74

Post by zacharypinter »

It seems to me that a version of the Innovator's Dilemma might apply to software frameworks as well.

By the time a project gets large enough it starts optimizing for its major stakeholders. New use cases or new ways of rethinking common use cases come along, and the small libraries that approach it from scratch have a narrowly-defined advantage. If the advantage is significant enough (e. g. virtual dom for browser UI), then new frameworks start being written around them, bringing back some but not all of the features of the older frameworks.

At some point (different for each user/use case) the newer frameworks have enough functionality that people start considering them over the older ones for new projects. When enough of that happens, the older frameworks start looking like yesterday's software.

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

#75

Post by heartbreak »

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 success. I did end up writing about 200 unit and integration specs during the process.

I'm thinking back to my days in the .Net world at BigCorp. Unfortunately I have nothing to compare it to, because we never upgraded anything from one major version of ASP.NET MVC to another. Is that a better situation?

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

#77

Post by lmm »

neverminder wrote: post #72
lmm wrote: post #48

Earlier quoted context omitted.

Let me take the opportunity to plug Scala, which gives you (better than) the expressiveness of Python or Ruby but with (better than) the safety of Java. (OCaml, F# or Haskell are other options in a similar quadrant).

Scala + Play Framework, which incidentally was inspired by Rails, however in my opinion is much more consistent amongst other things.

I don't actually like Play (its routing in particular is very ad-hoc and doesn't make good use of Scala's capabilities). I use Spray for JSON APIs and Wicket for HTML UIs.

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

#78

Post by scardine »

cdnsteve wrote: post #53

"makes it easy to install 1,000 gems into your project without a single line of configuration, is exactly why it’s hard to debug". This "let someone else do the work, get it from a gem" mindset is what kills long lived projects. It has nothing to do with the tools and everything to do with experience. You don't need 1000 gems. Managing anything more than core dependancies in a project can easily create exponential bu…

> Senior/Lead devs need to carefully curate what a projects foundation is. A strong, well designed foundation means you have something solid to build on. If you don't understand what's in your deps, haven't read their code, see how often it's updated and how many people actively use it, and can say you are using 80% or more of the code in it then don't use it.

Having to deal with my share of poorly supported components in Django/DjangoCMS, I can confirm your observation for Python. But betting on the wrong opensource component is often better from betting on the wrong proprietary technology. It comes with the territory.

> Writing your own code is often the best route since it fixes your exact use case, no matter the language, libraries or frameworks being used.

The problem is not you supporting your own code versus you supporting the code of a random dude from Internet, the problem is when you move on to the next job and some poor guy has to support and fix bugs in your code from 3 years ago. In my experience the average quality of community components and components developed in-house are not that different.

Personally I wish project managers starting caring more for life-cycle planing.

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

#79

Post by vox_mollis »

obstacle1 wrote: post #69
vox_mollis wrote: post #62

I've come to the conclusion that those who defend weak/dynamic type systems and other unsafe toolchains simply buy into the fallacy of the uber-developer: the belief that while other, lesser developers need static typing and analysis, I'm so superior that I will never introduce those class of bugs, ever.

Could you point out where the author of this post even came close to suggesting that Rails is for great developers who don't need static typing? Or did you accidentally post this unrelated opinion in the wrong thread?

I'm responding to the article that the author linked to, which does mention static typing. This comment is an attempt at a hypothesis for why some developers dismiss the importance of such features/tools.

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

#80

Post by ionforce »

askyourmother wrote: post #21
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…

Rails codebases do not age well, and are always unpleasant to work on. I never saw the same issue with django codebases of a similar age. Nor even ones from Perl or PHP frameworks either. No. It is a special combination of the shiny insecure magic of Rails, mixed with the happy meal mentality and abilities of most Rails developers.

You've never seen a Perl or PHP codebase age poorly?

That's unbelievable.

Post reply on HN