Hacker News Reader

There's a little big detail w/r/t java comparison: every company I've personally worked with who uses rails for their backend vs java moves WAY WAY WAY faster. So in terms of the "enterprise stack" dichotomy, there is a difference in kind between rails/java.

I get things done faster and more maintainably (for future me and other devs) when I do it in rails. Hopping into apps that rely on (request, response, next) always hits me with a learning curve every single time I come back to em, which gets worse as complexity rises. It could also be that I'm very bad at thinking in terms of pipes and need to practice that more.

I also find that in rails, there really aren't _that_ many ways to do things. And, in general, apps that age gracefully always figure out how to phrase their domain concepts through the smallest restful url's/resource mappings they need. There's a lot to be learned from the approach the smaller micro frameworks take, and you can get the best of both worlds in a lot of ways.

And there are some companies where you need to move fast while at the same time need to have high performance (100.000 req/s with 30-50 ms mean latency). In that case Java is the only option between Rails amd Java.

The gap between Scala + Play and Ruby + Sinatra (or cut down Rails) is not like it was in 2008. Ruby 2.5 is ~13x faster than Ruby 1.8. Now you're lucky to squeeze 3x the web throughput out of a Java/Scala service as opposed to CRuby and JRuby closes that gap further.

Can you point to me any performance site where Ruby 2.5 + Rails that backs your point? If you use JRuby than you are on the JVM already. In that case why Rails at all?

In terms of pure Ruby performance, there's a semi-official non-trivial benchmark called optcarrot. Ruby 2.4 is 14.3x faster than Ruby 1.8.7 here: https://github.com/mame/optcarrot/blob/master/doc/benchmark....

Rails performance relative to JVM+Scala+Play is tricky to measure but the closest thing to a decent benchmark I know of is this: https://www.techempower.com/benchmarks/#section=data-r16&hw=...

My own experience at ChartMogul with building production services in Ruby, Go and Rust is that the overall throughput of REST API type services increases a disappointing amount.

With JRuby you get to retain all the benefits of the Rails ecosystem. Most of the Go and Scala community is driven by much larger companies who do open source libraries but they don't really build frameworks to help developers build software quickly.

People that have the skills to pull off a complex site __correctly__ with just a micro framework are rare and expensive.

But people that can do it and make it easy for the team to scale are unicorns.

I've yet to meet one that stays on this kind of missions for long because they get a better offer, leaving the custom project to people without the skill to manage it.

And if you think all that is easy, you are not that unicorn because you don't have a perspective going beyong your code files.

I’d just like to chime in that myself and the other rails developers in my company use rails because we love it (in addition to it being the right tool for the job). I personally find ruby a beautiful language and using it every day makes me happy.

I didn't mean to say that no one uses rails because they like it -- I fully understand that rails was not only caused a watershed moment for web development (particularly server side), especially when what came before was java in large part. Also, having survived perl I've never seen a "scripting" language handle flexible syntax/paradigms as beautifully as ruby has -- it is certainly a beautiful language.

I think the increased productivity, beautiful language that rails is pushed everyone in the right direction, I just personally think stopping there is a bad idea, and that while rails is great it's not necessarily the reason it's in widespread use.

I didn't see any mention in the article of comparing install rates for rails versus other platforms (since of course this info is hard to get) -- and there are tons of rails-ish software out there (django being a huge one). If django had been the thing to break through and rails came after I think the roles would simply be reversed.

> I dislike rails because there's too much magic

This was a common complaint about Rails years ago. What are the "magic" parts in current-day Rails that you dislike?

(I disliked the dynamic finder methods, e.g. find_by_city_and_state, which you would now do using arguments to where(). I also disliked the default routing which made every public controller action routable, if I remember right. Those are now either deprecated or removed.)

These days I don't really work with rails codebases, so I don't have any recent examples in mind to call upon. There's just a bunch of stuff you need to know about how rails works before you can successfully read/understand rails code -- I just remember seeing all this stuff in code and I was just thinking "where the f did this come from", and then realizing that the version of rails we were on had this feature that tied together these two parts with some obscure method.

I haven't even looked at Rails 5 or worked in a recent Rails 4 codebase so I'm sure things are much better but the code I remember the feeling of being perplexed so often at how a worked in previously wasn't my own so I can't go back and remember what parts really made me angry.

How is that different from any new codebase you have to look at? If anything Rails reduces the confusion because it has a set of agreed to conventions. I can’t think of any decently complex codebase I’ve ever come across that didn’t have it's own weird abstractions that aren’t immediately clear.

Disliking Rails’s built in abstractions seems to come down to only liking abstractions your own devs created which sounds like not invented here syndrome.

It's more which tools are used to make abstractions -- I find that rails uses and encourages implicit (auto-created methods, stuff injected into a method's scope) abstraction creation rather than explicit (functions/higher-order functions) abstraction creation.

Interesting. I've honestly never heard the complaint about "magic" and abstractions made so concrete. I still believe many of auto-created methods are a good thing and generally done with the thinking that if you do X in 80% of cases the same developer also wants Y. Which makes perfect sense to me but I can also see how that would be surprising and/or annoying.

I’m not seeing how your complaint that there are too many ways to do things in Rails leads you to using a micro framework. Since Rails makes a bunch of choices for you ahead of time, there should be less ways to do things in Rails vs a micro framework.

I don't really have an exact example for you -- the last corporate rails codebase I touched was 2 migrating to 3/4, and the last rails guide I saw was 4 (rails is on 5 now?)...

I did a cursory google search and found:

https://stackoverflow.com/questions/29697787/rails-call-same...

More generally, my point was that smaller libraries have less space for multiple ways to do things/overlapping concepts. In the codebases I've worked with, I've found myself questioning whether to use one specific rails concept or the other and the resulting "right" choice seemed arbitrary -- like whether I should make a controller mixin or create a helper.

For example, if you look at a framework like sinatra, the smallest/simplest thing you use to respond to a request is just a function. How to use functions properly is pretty clear, there's not much else to debate over.