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

141–150 of 219 posts

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

#141

Post by borkborkbork »

borkborkbork wrote: post #135
busterarm wrote: post #109

Earlier quoted context omitted.

I think this is the source of the early focus on unit testing in the Ruby community. The problem is a lot of Ruby developers have not felt this pain yet and eschew testing because they work in startups that are in a state of permanent death-march. A little (okay, a lot) of unit testing goes a long way to ease this pain. The people making breaking changes in their gems usually/hopefully have good testing in place and…

I went through the same upgrade process that the OP mentioned at scale. The company had 5 or 6 microservices that needed to be upgraded from Rails 3.1. While having 10,000+ unit tests was very helpful for reducing regressions, we still had several huge problems: 1) We couldn't be sure that we hadn't broken something because we knew we didn't have 100% test coverage. 2) Some of the gems we depended on conflicted so se…

This problem isn't specific to Rails 3.1. At some point, your frameworks need to be upgraded, because at some point the developers stop supporting your version. Django announced recently that 1.7 would no longer be getting security fixes. The question is: how much will it cost to upgrade when the day comes? Frameworks and communities that encourage less magic and less dependencies will always be less costly to maintain.

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

#143

Post by OhHeyItsE »

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…

This kind of thinking is how you end up with 8 zillion job-securing lines of custom frameworks-within-frameworks and stuff like:

  def isTrue(x):
    if x:
      return true
    else:
      return false
Code is debt: https://blog.codinghorror.com/the-best-code-is-no-code-at-al...

Reviewing vendor libraries always a good idea, but you aren't going to make it very far as a "Senior/Lead dev" if you are constantly using someone's money to reinvent the wheel.

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

#144

Post by engineerDave »

busterarm wrote: post #139
borkborkbork wrote: post #135

Earlier quoted context omitted.

I went through the same upgrade process that the OP mentioned at scale. The company had 5 or 6 microservices that needed to be upgraded from Rails 3.1. While having 10,000+ unit tests was very helpful for reducing regressions, we still had several huge problems: 1) We couldn't be sure that we hadn't broken something because we knew we didn't have 100% test coverage. 2) Some of the gems we depended on conflicted so se…

I believe it and know that sucked, but unfortunately in Rails 3 we got caught with our collective pants down in terms of security. Nobody competent was really auditing it (as was demonstrated against Github) to match the amount of momentum that it had. I see that as more of a Black Swan event than any inherent problem with the framework (yes, I'm basically blaming its users). This wasn't typical of the Rails 2 to 3 u…

I think your memory of the 2 -> 2.1 -> 2.2 -> 2.3 (if you were lucky to get bundler running) to 3 to almost immediate 3.1 with massive changes (asset pipeline) upgrade is a little fuzzy. It was the suck. A lot of companies I know of are still running Rails 2 because of this change.

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

#145

Post by engineerDave »

borkborkbork wrote: post #141
borkborkbork wrote: post #135

Earlier quoted context omitted.

I went through the same upgrade process that the OP mentioned at scale. The company had 5 or 6 microservices that needed to be upgraded from Rails 3.1. While having 10,000+ unit tests was very helpful for reducing regressions, we still had several huge problems: 1) We couldn't be sure that we hadn't broken something because we knew we didn't have 100% test coverage. 2) Some of the gems we depended on conflicted so se…

This problem isn't specific to Rails 3.1. At some point, your frameworks need to be upgraded, because at some point the developers stop supporting your version. Django announced recently that 1.7 would no longer be getting security fixes. The question is: how much will it cost to upgrade when the day comes? Frameworks and communities that encourage less magic and less dependencies will always be less costly to mainta…

true but even staying current across small SemVer changes can be a relatively large burden

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

#146

Post by collyw »

weberc2 wrote: post #89
collyw wrote: post #34

Earlier quoted context omitted.

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.

Fair enough. He would have done well to explain that. Java does the same. Is it considered tomorrows language? At the end of the day its another trade off between compiled and interpreted languages, and one thats been around for years.

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

#147

Post by engineerDave »

mordocai wrote: post #130
engineerDave wrote: post #124

Earlier quoted context omitted.

Yes. Being forced to push changes to production with zero test coverage, and hence zero confidence in your code on a Friday night. (true story) After that you always make sure test exist before even pondering a push of potentially breaking changes! :P

Oh yeah, I mean I always write tests for anything for work. I don't do TDD all the time though, sometimes I write the tests after the code. A language/framework that forced me to do TDD would just piss me off, which was my original point.

I was being tongue in cheek on that one, sorry if it didn't come across that way. Although I've been a Rails dev for 6 years now, I've come to hate the TDD approach and am a convert of FP and types, & compilers a la Haskell. Because there really is no such thing as a massive change in FP IMO. Unfortunately I'm not competent enough in it yet so Rails still pays the bills.

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

#148

Post by Bluestrike2 »

akmiller wrote: post #132
dcrall wrote: post #71

Earlier quoted context omitted.

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.

I've been doing Clojure for the better part of 3 years now and I'm not sure I get why people feel doing web development in Clojure is hard. Our first foray in Clojure was/is an API to manage our users that was built by 2 developers who were new to the language and has been running largely unmodified since being released. I actually believe the opposite. Jumping into and doing Clojure web development is extremely simp…

Is it fair to ding Rails for that, though? Regardless of what framework you're working with, eventually you're going to be peeking under the hood. Of either the framework, the language, or both. Whether that's front-loaded or not, it's still there. So the question becomes which framework eases you into the deep end of the pool, rather than which is the least complex.

I've seen plenty of Rails apps that could have written better initially. But I haven't really seen any where it was impossible to refactor and improve them as a developer learns more.

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

#149

Post by ktRolster »

eric_h wrote: post #94
beat wrote: post #86

Earlier quoted context omitted.

A huge upgrade on code with no tests and a bunch of magical dependencies? The problem wasn't Rails there.

There's an argument to be made that Rails, by not actually enforcing conventions like TDD, gives an amateur/impatient developer a very high calibre footgun. Unfortunately, of course, that gun doesn't usually go off until it's handed to someone else.

When people are forced to write tests, they merely write lousy tests. It doesn't change anything.

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

#150

Post by s_kilk »

akmiller wrote: post #132
dcrall wrote: post #71

Earlier quoted context omitted.

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.

I've been doing Clojure for the better part of 3 years now and I'm not sure I get why people feel doing web development in Clojure is hard. Our first foray in Clojure was/is an API to manage our users that was built by 2 developers who were new to the language and has been running largely unmodified since being released. I actually believe the opposite. Jumping into and doing Clojure web development is extremely simp…

> The issue with frameworks like Rails is that you get so much for free and don't have to understand how all the pieces fit and work together

Having used both Ruby/Rails and Clojure, I think Clojure swings too far in the opposite direction, where absolutely everything is foisted on the developer and they must hold the entire codebase in their head at once or drown.

We even see this in luminus, the closest thing Clojure has to a web framework. It's just a leiningen template which spits files out on disk and says "there you go, it's your problem now". Of course there are upsides to this approach, but personally I've come to find developing web servers in Clojure a withering, joyless experience. Elixir and Phoenix show much more promise and seem to strike the right balance between featureful-ness and cleanliness.

Post reply on HN