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

151–160 of 166 posts

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

#151

Post by humbleMouse »

Tenhundfeld wrote: post #122
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?

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

To expand on my offhanded comment: If you are well versed in OOP design principles/database design - I don't see why you would choose rails. I suppose if I didn't have so much experience with java I might want to try something like ruby. Java just gives you so much freedom to design things how you want and use whatever framework you feel like.

I don't feel comfortable with all these behind the scenes scaffolding things happening. I prefer to design back-ends as data endpoints that feed a separate business logic layer. I feel like I have the most control of these things using java.

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

#152

Post by humbleMouse »

vorg wrote: post #142
olavgg wrote: post #85

Earlier quoted context omitted.

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.

> you get the full power of the JVM/Spring technology stack. And Groovy If Groovy and Grails are technology "to dream about", one wonders then why VMware (the Spring backers) retrenched their 6 developers working on Grails and (what is now Apache) Groovy early last year, and why Sun Microsystems (the JVM backers before Oracle) wanted nothing to do with Groovy in its day (despite supporting the JRuby and Jython develo…

Internal politics? Budget constraints? Bad management? Idk

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

#153

Post by abc_lisper »

tunesmith wrote: post #120
abc_lisper wrote: post #97

Earlier quoted context omitted.

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…

The only dynamic language I used in production code is Clojure, hence my perspective is probably skewed by it.

> I'm having trouble thinking of a time when I felt something akin to what you describe with zombie constraints

Think of deprecated methods in a class, unneeded methods in an interface that are stubbed etc.

> I also write plenty of tests with plenty of mocking

This is good. But what happens to mock objects when the underlying class changes its implementation - It needs a large number of changes in tests.

If you are writing micro-services, the guarantees that typed system gives you are more trouble than they are worth. If your average microservice is less than 10k lines of code, it probably reduces to 1000 lines of code in Clojure, and for the codebase of that size, typed systems provide little value for the cost(atleast for me).

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

#154

Post by vorg »

humbleMouse wrote: post #150
vorg wrote: post #143

Earlier quoted context omitted.

The static compilation doesn't quite work properly. Groovy is good for scripting though, similar to the way Bash is used in Linux, so test your Java classes with it, or use it as a DSL in Gradle builds. For building systems on the JVM, use a language designed for that purpose from the ground up, e.g. Java, Scala, or Kotlin.

It works quite well in the 1.5 million code line application written in groovy that I work on. I am sure Scala and Kotlin are nice languages, but groovy static compilation seems to work great in my experience.

> the 1.5 million code line application written in groovy

That's quite big for Groovy. There's a lot of exaggerated claims coming out of that ecosystem. Most JVM apps that size are actually written in Java, perhaps with the codebase duplicated a few times, and counting testing copies of the code in the LOC count. If the harness for testing is written in Groovy, you could call it a "1.5 million line Groovy app". If some of that Java code is compiled or run as Groovy code in some testing framework, you could call it all "Groovy code". If the Groovy code is called from some app written in Java, such as Grails, you could get creative and call it a "Groovy application".

> groovy static compilation seems to work great

And just what proportion of that Groovy code is really compiled statically and run in a production app?

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

#155

Post by pmontra »

marshray wrote: post #147
shimon wrote: post #117

Earlier quoted context omitted.

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

> 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. So the important questions are: 1. Does Rails performance degrade gracefully under load? 2. Can you gradually shift away from a quick-and-dirty Rails-based implementation to something more scalable without the dreaded "rewrite-while-hair-on-fire" scenario? In my e…

Given the example of Twitter I'd say that the answer to the second question is yes. They rewrote the Ruby (not Rails) backend and continued serving tweets. Did they have theirs hairs on fire? Maybe, but I don't think you're never in hurry when you rewrite parts of a popular service.

About question number one: no idea, but you can add more machines and scale horizontally. Then you might ask if you want more efficient code between the web server and the database. You can optimize up to C. Finally, Twitter is still using Rails for the front end AFAIK, so it shouldn't be so bad.

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

#156

Post by pmontra »

mattmcknight wrote: post #41

A couple of things seem off on this perspective, mostly that modern web development has gotten weird, irrespective of Rails. "The ambiguous, english-like syntax of ruby that makes rails so easy, is exactly why it’s not simple." First, I found Rails simple and easy, but it has become more complex over time as it has grown to support a variety of uses. The simplicity is not just because of Ruby, which is a low ceremony…

+1 but about REST and the websockets: I'd keep using REST to query data and send data (and get a response). I'd use a websocket only for those cases where I should poll the server for updates. Reimplementing most of the semantic of HTTP into a websocket looks weird. Basically it would be tunneling HTTP into the websocket, which is already an upgrade of a HTTP connection.

Exceptions: I won't POST to a chat, even if there is nothing so wrong with that. Rationale: I'm already using that websocket for receiving messages, but only the messages for that chat.

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

#157

Post by olavgg »

vorg wrote: post #143
humbleMouse wrote: post #114

Earlier quoted context omitted.

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

The static compilation doesn't quite work properly. Groovy is good for scripting though, similar to the way Bash is used in Linux, so test your Java classes with it, or use it as a DSL in Gradle builds. For building systems on the JVM, use a language designed for that purpose from the ground up, e.g. Java, Scala, or Kotlin.

I also have several big projects with hundreds of thousand lines of Groovy code that works fantastically well. And performance is top notch!

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

#158

Post by gaius »

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.

There are 2 kinds of languages, those people complain about and those no-one uses -- Stroustrup

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

#159

Post by Corrado »

humbleMouse wrote: post #151
Tenhundfeld wrote: post #122

Earlier quoted context omitted.

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

To expand on my offhanded comment: If you are well versed in OOP design principles/database design - I don't see why you would choose rails. I suppose if I didn't have so much experience with java I might want to try something like ruby. Java just gives you so much freedom to design things how you want and use whatever framework you feel like. I don't feel comfortable with all these behind the scenes scaffolding thin…

> Java just gives you so much freedom to design things > how you want and use whatever framework you feel like.

This lack of flexibility is precisely the reason that people choose Rails. It is a very opinionated solution and the Rails community doesn't hide that fact. The power of a Rails project is anyone familiar with Rails can walk up to it and get productive in minutes. All the code is in a standard place, the tests are run the same way, the deployment is familiar, etc.

On the contrary, look at 100 different Java projects and you would find 100 very different solutions. Getting up to speed on an existing Java project would take multiple times longer than a Rails project, even if you were generally familiar with Java + Spring.

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

#160

Post by humbleMouse »

vorg wrote: post #154
humbleMouse wrote: post #150

Earlier quoted context omitted.

It works quite well in the 1.5 million code line application written in groovy that I work on. I am sure Scala and Kotlin are nice languages, but groovy static compilation seems to work great in my experience.

> the 1.5 million code line application written in groovy That's quite big for Groovy. There's a lot of exaggerated claims coming out of that ecosystem. Most JVM apps that size are actually written in Java, perhaps with the codebase duplicated a few times, and counting testing copies of the code in the LOC count. If the harness for testing is written in Groovy, you could call it a "1.5 million line Groovy app". If so…

To be fair - only about 2/3 of the code in the app I mentioned is written in groovy. We strictly enforce static compilation with all of our groovy files. The app is used daily by 35,000 users concurrently @peak time.
Post reply on HN