Hacker News new | ask | show | jobs
by fareesh 2102 days ago
The obvious performance and bloat overhead with RoR aside, I have yet to see a framework and ecosystem that lets you have a programmable web application up and running with typical features in comparable time.

For shipping new products or testing out ideas, I have not come across a more optimal framework in terms of going from idea to market.

Most often I've tried Phoenix, Django and Laravel as alternatives, but all of them seem to fall short. I gave .NET MVC a shot too back in its early days, it was not pleasant.

I run a dev shop and it seems to fit really well with our business model.

5 comments

> The obvious performance and bloat overhead with RoR aside.

Does the bloat matter in the end tho?

You can build a million dollar business on a single $20 / month DigitalOcean server to run everything with tens of thousands of users. That's what Chris did from https://gorails.com. We talked about his Rails driven tech stack on the Running in Production podcast[0].

Recently he tweeted out he generated a million dollars from his business[1].

If you can get 100ms or less p95 response times without a complicated infrastructure then the only thing that matters is the ecosystem, community and how much you enjoy using that technology. If performance is a web framework's biggest feature then I think they're fighting an uphill battle. Performance isn't that important for most applications as long as you can produce a nice feeling application that responds quickly. All modern frameworks have a means to do that. Now it comes down to how fast can you build it and how nice is it to maintain.

[0]: https://runninginproduction.com/podcast/12-learn-ruby-on-rai...

[1]: https://twitter.com/excid3/status/1295730795148193792

I guess it depends on what you build. At the scale of GitHub and Twitter or Shopify there are probably significant challenges caused by said bloat.
But once you reach that level of scale you have (or should have!) the resources to redevelop services that are holding you back. Not choosing Rails because you intend some day to get to Twitter scale smells of premature optimisation. (Twitter themselves used Ruby!)
Yep, which is generally why I can't see a good argument for not using it. I was hoping to see some here but it seems to be a consensus view.
I would argue that there isn’t a framework in existence that is actually built to cleanly scale to the size of any of those companies. If there is one that claims to, it is probably lying.
I have had to help scale a large scale Rails app and break it apart about 5 years ago. 500k requests per minute. That was tough. A lot of the features that Shopify and Github have upstreamed since then would have helped a lot and to be honest it is a lot easier to scale now with Rails because of those upstreamed features. Like multiple databases, viewcomponents, etc.
The weird thing is we have to keep semi-apologising for choosing Rails. Why is that? For each his own. I love Rails, sue me.
I am all for your love of Rails, but tools should not be picked based on how much you love them. Choose the correct tool for the job, if it is rails, good for you.
For me its Rails, also because I love it. None of us is 100% objective or rational about this. I'm very much aware most companies can be built with any of the common stacks, the tech barely matters for 90% of these companies. Why does it mater if advertisement algo company X or insurance tech company Y choose java/.net/ruby/php ? All these stacks are good enough and have been used countless times in varying scales.
For example if you are building something around nlp, probably pick python.

Also, since you are all into ruby, maybe take a look around as to why other languages exist.

There's a solid question as to why the tool you'd pick for CRUD databasey stuff should be coupled to what you'd pick for NLP heavy lifting by the interpreter. Different jobs, different tools.
That's quite a specific use case and as a mainly backend web developer I don't hit many nlp problems. That's usually a whole specialisation of it's own.

> maybe take a look around as to why other languages exist.

I've been around. Still like Rails, works well for me. Thanks for the advice :)

Depends why you love Ruby. If you love it because you adore programming languages with red logos then yes, bad choice. But if you love it because it lets you work quickly and performs well then that is a reason to pick it.

Not to mention, if you’re a solo developer or a small team, picking a language everyone knows and likes absolutely is a good reason. It’ll save you a lot of time.

I can list some good qualities I love about Ruby, but I don't know if that's gonna be a great answer. It just clicked with me and analysing it too much is futile. Kinda like analysing why you love your friends is futile: sure, you can list some good qualities. But you could also list good qualities of people who aren't your best friends. It just so happens sometimes a person or a tool clicks with you, it's being in the right place at the right time with this tool. I can see why C# or Python make sense for people. But they haven't clicked with me so they're not my friends. We have no history together.

Now I'm not saying you can't ever grow out of your friends (or languages), I just haven't outgrew Ruby.

I'm sure if joel loves rails, it must be working for him.

If it didn't, surely he'd hate it, no?

No. You can continue to build everything with the language you love. But there are cases where a certain thing is just easier to get done in a particular language. And there is nothing about hating any language.
This is what brought me to RoR land... and this is what made me leave.

I agree rapid prototyping is an excellent point for RoR but when you need to actually evolve the project for years, it gets really tedious and hard.

So for a dev shop RoR is quite fine -- you make the project, do very little iteration on it, and ship. That works well and I've experienced it.

For longer-lived projects however, Phoenix is miles ahead. Even Rust's Rocket, but only if you are willing to invent a lot of stuff yourself (auth for example).

> For longer-lived projects however, Phoenix is miles ahead. Even Rust's Rocket, but only if you are willing to invent a lot of stuff yourself (auth for example).

I can't speak to Phoenix, but I've looked into Rocket and don't understand how it can really be compared to Rails. There's so much you need to implement yourself that you'll end up spending a big chunk of time on implementing things that Rails (or high quality / well used gems in the Rails ecosystem) can provide for free. And don't get me wrong, I'd love to sit down and do that work, but my job is to make stuff work and make it work quickly, and my employer doesn't hire enough people that we can afford to dedicate that kind of time when it's already "solved" by a framework.

I tend to work on projects where the requirements change constantly, and they're never really "done." Saying rails is good for "prototyping" is not wrong, but in a world where software is always evolving, the features and capabilities that make Rails great for prototyping are also great for just day-to-day existence.

What makes you say it is hard to maintain longer lived projects? (I used to be a RoR developer for a few years, so I'm curious about other people's experiences.)
As a person maintaining multiple Rails codebases approaching a decade in age: RoR just bitrots incredibly fast and its really difficult to catch or update.

With each new version of RoR gems just stop being compatible without replacement, and its a fairly significant effort to migrate everything to the new shiny being introduced. In fairly stable projects where there isn't much feature churn/replacement, you pretty much have entire sections of the codebase that never move past the version they were originally written in. You're constantly maintaining controllers/models written in RoR 3.2/4/4.2/5/5.1 styles since its incredibly difficult finding which features were used, but they still kinda sorta mostly work, until they silently don't.

The difference compared to other frameworks/languages is that Rails is very heavily powered by "magic". Every other tech explicitly configures and calls features being used, but Rails is mostly held together by "convention", but convention evolves. How do you search for things like "the filename of this must match the class name of this" or "the method name must match this database feature". Nevermind the metaprogrammed methods that aren't documented anywhere. The convention evolving as developer preferences changes is generally a good thing and keeps RoR from becoming too dated but it is an expensive maintenance burden.

I quite like Rails and it's still my first choice for personal projects/prototypes. But I'm definitely souring to it for long running professional work.

It's mostly the "magical" parts like before/after hooks. When you are tracing a bug and are trying to do step-by-step debugging, it has been hell. Quickly jumping to definitions? Even RubyMine can't do it.

Furthermore, as the project grows, you need to introduce something more/bigger than MVC and people put these files everywhere. Sure it's a management problem but it doesn't help that people don't do the right thing by default.

In general, there's a breaking poing that you will very soon hit when you try to just pile things on top.

    It's mostly the "magical" parts like before/after hooks. 
I dislike a lot of the "magic" in Rails, but don't find before/after hooks very "magical" at all.

I guess when you get into inheritance perhaps. When you have an inheritance chain, which hooks are firing and in which order? That gets confusing fast. But, that also doesn't feel Rails-specific at all to me.

Rails gives you some ways to shoot yourself in the foot, but what language/framework doesn't?

    When you are tracing a bug and are trying to do step-by
    -step debugging, it has been hell.
I don't find this too much of an issue. It may be primitive but I just rely on debug output statements.

I have an expansion set up in my text editor that spits out `Rails.logger.debug("[jbootz] ")` and then I just do `tail -f log/development.log | grep jbootz`. I also have iTerm set up to highlight any lines containing "jbootz", so it stands out when it's mingled in with other output. (I just picked "jbootz" as it's a unique string)

In general that's the strategy for Rails debugging or really any dynamic language where the editor/IDE can't reason about the code like it can with a static language.... lots of debug output and then get a little creative with how you filter it in your terminal.

Helps to use an terminal app like iTerm that lets you use split panes so you can look at multiple filtered views of your log output at once if you like.

    Quickly jumping to definitions? Even RubyMine can't do it.
Yeah. I used to work in C# + Visual Studio + Resharper and oohhhhh boy, I often miss being able to lean heavily on the IDE/compiler.

Still, as far as definitions go? I don't know. I just grep for "def foo" (if I don't know what file it's in) or use my editor to jump right to the file where it exists (if I know where it is, which is usually the case)

Not as slick as the editor/IDE actually being smart, but I don't really find it to be a friction point.

> I have an expansion set up in my text editor that spits out `Rails.logger.debug("[jbootz] ")` and then I just do `tail -f log/development.log | grep jbootz`. I also have iTerm set up to highlight any lines containing "jbootz", so it stands out when it's mingled in with other output. (I just picked "jbootz" as it's a unique string)

... that seems unnecessarily complicated compared to using byebug, or hell, the RubyMine debugger.

I should have been clearer.

I use pry/byebug extensively as well.

There are times when I prefer debugging via debug output statements and times when I prefer interactive debugging.

I agree Rails only does a great job on structuring when project is started

But any large enough project needs rules for placing files/classes

I don't see how Rails failed in that way

I do agree there are some "magical" stuff like hooks that can be easily abused and introduce bad coding habits/patterns

Wish I can turn them off per class (not for the whole app since they are still sometimes useful)

Yeah. MVC is not always the right tool for the job, but it's generally fine and IMO rarely a terrible fit.

I don't see how that's a Rails-specific problem.

Before Rails, working in the wild and wooly world of Microsoft web dev (with occasional PHP thrown in) I saw some real horrorshow web apps. People hacking together their own confusing and misthought architectures. And those horrorshows were rule and not the exception.

The standardized structure of Rails apps is such a breath of fresh air. It's so nice to step into a Rails codebase and basically know where most things are most of the time.

Admittedly it's also nice to step away from Rails for smaller, simpler apps.

What do u use outside Rails and how was your experience? It's a bit embarrassing I only did Rails with Ruby.
I think there are probably a large number of people who "learn Rails" without really learning the deeper/unique concepts of vanilla Ruby. For me at least it was like a decade in between first writing some Ruby and really feeling like I've started to understand the full scope of the language and syntax that's available to me, such that I'm only now able to start thinking about what cool actual-things I can build with these concepts.
In your experience, is there good resource for discovering the "de-facto" hex packages for a particular requirement - I end up Googling things like "Phoenix paperclip equivalent" and then evaluating all the various ones.

Alternatively are there some good "kitchen sink" open source projects that implement many of the typical web application features like auth, uploads, etc. ?

Companies like thoughtbot have been a gold mine of information and battle-tested practices - is there anyone similar in the Phoenix space that's worth following?

Sadly there aren't many better ways. For the moment the best course of action is to search on ElixirForum. Even if I love the language and still look for ways to work with it (in my new job where it isn't used) I recognize that the ecosystem is not that big.

For auth, the core Elixir team has made one prototype but I am not sure if they'll pursue it further. Outside of that, use Pow. For file attachments: Waffle. Authorization: CanCan, although the area has several very solid options, I heard.

Discoverability can indeed be a problem. Covid-19 hit everything pretty heavily and Elixir's community is no exception. Just a month ago people started finally hiring for it again (on the forum).

Time for a respin of https://www.ruby-toolbox.com/ ?
edited to delete as i was discourteous.
>The obvious performance and bloat overhead with RoR aside, I have yet to see a framework and ecosystem that lets you have a programmable web application up and running with typical features in comparable time.

This answers your question indirectly. I’ve included a link below to Amber Web Framework, built on Crystal. Crystal is a statically typed language with the speed of C and the exact same syntax as Ruby.

Check out the video a couple screens below, and you’ll see a demo of how quickly an Amber Blog App is generated. You’ll notice their is almost no difference between Rails syntax and Amber syntax.

https://amberframework.org/

> the exact same syntax as Ruby

I would be very careful with that statement, because it's simply not true (example: no type-related syntax in Ruby).

Is there anyone notable using it in production?
Digital Ocean is a sponsor according to the website, so maybe that counts.
Spring Boot Kotlin is worth giving a go. It has rapid prototyping abilities, but underlying Java promise of easy refactoring, great tooling. I recently refactored entire frontend and parts of backend code without ever having to restart server.
While I wouldn't exactly put it in the Rails category, I love Spring Boot far more. I love Micronaut even MORE than Spring Boot... but that's another story.

Spring Boot doesn't tick ALL the Rails boxes (Scaffolding a backend CRUD admin interface, all of the complex templating stuff - although Thymeleaf is pretty darn good) I'd put my money on it being more maintainable a year later. Spring as an ecosystem is huge, so there's always a strong possibility someone else has already solved the problem you're trying to solve. The tooling is pretty fantastic as well. Kotlin as a language is just fantastic.

How is the ecosystem? For example - if I want to add auth, social login, profile picture and admin dashboard CRUD, are there mature packages that can be leveraged for these features?
It has decent support. It is based on sprint which has had social auth for many years now. Plus good third party support like okta.

Note to self - dont post about Java on HN, people downvote even non hateful comments!