Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ruby on Rails Audit Complete

ostif.org

Post reply on HN
Print view View original

121–130 of 171 posts

Re: Ruby on Rails Audit Complete

#121

Post by rco8786 »

vidarh wrote: post #114
rco8786 wrote: post #14

Earlier quoted context omitted.

> Then they realized it was hard to scale A rumor perpetuated by exactly one company - Twitter. I know because I was there when it happened and helped dismantle the original monolith. Rails scales just fine for 99%+ of business cases. If you're doing a sustained 5k writes per second with bursts up to 100k...sure maybe you need something more specialized.

Twitter also would've scaled a lot further on Rails just by dismantling the monolith. I don'tike Rails (though I love Ruby), but the way Rails was scapegoated for an original architecture that was not suited for scale irrespective of framework or language was annoying.

Yep totally agree. And also realistically once we hit that kind of scale it was perfectly reasonably to start looking at other options as well.

It's been a while but I think we were at like 250mm MAUs when we finally decided to break up the rails monolith (and I think it was still on Rails 3 at the time, but don't quote me on that). The number of companies that ever hit that kind of scale approaches zero, and even less in the B2B space.

Re: Ruby on Rails Audit Complete

#122

Post by kybishop »

pmontra wrote: post #99
burnt-resistor wrote: post #83

Earlier quoted context omitted.

Ecto

Ecto was literally the component I liked less in all the Phoenix stack when I worked with it after a dozen of years of Rails. I did maybe 5 years of Phoenix for a customer of mine and went back to Rails for another customer. It's good enough and overall Rails is easier to deploy IMHO. Capistrano vs I don't remember what.

Oh man, this must just be subjective because I find Ecto to be beautiful compared to the absolute trainwreck of Activerecord. Having compile time guarantees through Ecto is wonderful.

Re: Ruby on Rails Audit Complete

#123

Post by ukprogrammer »

IshKebab wrote: post #106
ukprogrammer wrote: post #12

The productivity of Rails for B2B 'CRUD' software is unmatched. Surprised to not see more newer startups make use of it!

Can you tell me why exactly? I've never used Rails but I have tried to understand and modify Gitlab's Ruby code and honestly it was a completely incomprehensible mess. I'm no stranger to large codebases but Gitlab is almost impossible to follow and it seems to be entirely because they use Ruby. I mean if you look at one file the code seems fairly clean and well written, but if you try and figure out e.g. where a func…

I echo the sentiment that you MUST use a debugger when working with ruby/rails. When using a debugger, magic becomes a call stack that is transparently visible. Once proficient and familiar with the conventions, reading it becomes a lot easier.

For Rails's productivity, there's many reasons. One is the 'Active Stack' which acts as a 'standard library' of sorts for the framework.

It provides extremely seamless tooling all the way from the most frontend of concerns (ActiveView - HTML/JS) to the backend (ActiveRecord - SQL ORM layer) and anything in between (ActiveController - HTTP Requests, ActiveMailer - Emails etc.). These tools are simple, robust and cohesive.

These primitives are built on by the community to provide powerful tooling (Devise, OmniAuth, amongst others) that allows one to implement the standard plumbing most SaaS/CRUD apps need in a few minutes - billing, auth, emails so you can get to writing business logic in a few minutes and have the boring stuff solved quickly.

Implementing just these basics in JS can take many hours and have you scratching your head wondering "Why are there 20 different ways to implement X? Why is there no tried and true way for something that are surely been done thousands of times? Why hasn't someone abstracted these details all away yet? Why do I have to npm install for this basic functionality? Wait, why did my build tooling just break?"

Re: Ruby on Rails Audit Complete

#124

Post by IshKebab »

ukprogrammer wrote: post #123
IshKebab wrote: post #106

Earlier quoted context omitted.

Can you tell me why exactly? I've never used Rails but I have tried to understand and modify Gitlab's Ruby code and honestly it was a completely incomprehensible mess. I'm no stranger to large codebases but Gitlab is almost impossible to follow and it seems to be entirely because they use Ruby. I mean if you look at one file the code seems fairly clean and well written, but if you try and figure out e.g. where a func…

I echo the sentiment that you MUST use a debugger when working with ruby/rails. When using a debugger, magic becomes a call stack that is transparently visible. Once proficient and familiar with the conventions, reading it becomes a lot easier. For Rails's productivity, there's many reasons. One is the 'Active Stack' which acts as a 'standard library' of sorts for the framework. It provides extremely seamless tooling…

So basically it's that it comes with built in libraries for common tasks? Authentication is definitely a super annoying thing to have to set up manually so I can see the attraction there.

Re: Ruby on Rails Audit Complete

#125

Post by jiggawatts »

demosthanos wrote: post #102
throwawaymaths wrote: post #98

Earlier quoted context omitted.

"willing to pay the price" what price? learning a new language that is designed to be learned from the one you already know with fewer footguns? ok fine. but you make it seem like going to elixir is some kind of heavy lift or requires a devops team or something. the lift is low: for example i run a bespoke elixir app in my home on my local network for co2 monitoring. and for that purpose (maybe 300 lines of code? yes…

To name just a few costs that aren't worth it for many businesses: * A much smaller ecosystem of libraries to draw from. * Much weaker editor tooling than with more established languages. * An entirely different paradigm for deployments, monitoring, and everything else that falls under "operations" that may be incompatible with the existing infrastructure in the organization. * When something does go wrong, using a w…

When José Valim “moved on” from Ruby development to work on Elixir, his fans followed.

It’s a bit like true believers switching faiths when their leader changes religions.

It’s hard to make sense of it from the outside looking in, but it’s definitely a thing that happened historically and occurs in small and big ways even today.

Re: Ruby on Rails Audit Complete

#126

Post by throwawaymaths »

jiggawatts wrote: post #125
demosthanos wrote: post #102

Earlier quoted context omitted.

To name just a few costs that aren't worth it for many businesses: * A much smaller ecosystem of libraries to draw from. * Much weaker editor tooling than with more established languages. * An entirely different paradigm for deployments, monitoring, and everything else that falls under "operations" that may be incompatible with the existing infrastructure in the organization. * When something does go wrong, using a w…

When José Valim “moved on” from Ruby development to work on Elixir, his fans followed. It’s a bit like true believers switching faiths when their leader changes religions. It’s hard to make sense of it from the outside looking in, but it’s definitely a thing that happened historically and occurs in small and big ways even today.

i had never heard of jose until i started working in elixir. i had about two years of grueling ruby experience[0] and boy was elixir an amazing breath of fresh air.

what is also a thing is stockholm syndrome and sunk cost fallacy.

[0] ok, now that i think about it also this was when ruby was having serious 1.84-2.0 transition troubles and i had difficulty reinstalling ruby if i needed to redo the os because some python wheel broke everything, so i had other historical reasons to leave ruby with a bad taste in my mouth. i think my gripes about activerecord are real, though.

Re: Ruby on Rails Audit Complete

#127

Post by nisa »

IshKebab wrote: post #106
ukprogrammer wrote: post #12

The productivity of Rails for B2B 'CRUD' software is unmatched. Surprised to not see more newer startups make use of it!

Can you tell me why exactly? I've never used Rails but I have tried to understand and modify Gitlab's Ruby code and honestly it was a completely incomprehensible mess. I'm no stranger to large codebases but Gitlab is almost impossible to follow and it seems to be entirely because they use Ruby. I mean if you look at one file the code seems fairly clean and well written, but if you try and figure out e.g. where a func…

You are not alone. Joined a company with a rails codebase and I really came to hate convention over configuration if you are not familiar with the convention. I've found Ruby on Roda and dry-rb much more understandable. I guess it's really a matter of taste. I've did C++ and Java before and while I appreciate Ruby rails is too much magic for me. I also hate to run into errors in runtime that a typed language would have catched.

Re: Ruby on Rails Audit Complete

#128

Post by monooso »

hotpocket777 wrote: post #57
Hnus wrote: post #55

Earlier quoted context omitted.

Serious question: do people actually enjoy writing Ruby? I feel I’m writing in something like Bash. I never felt this way until I picked up other languages like Rust, Zig, C#, and learned a tiny bit of programming language theory. After that, the loose and squishy feel of Ruby really started to bug me. Also, it seems like every Ruby programmer I know only ever uses other dynamic languages like Python. It’s never like…

> Also, it seems like every Ruby programmer I know only ever uses other dynamic languages like Python. It’s never like they’re experts in C++ or something and then decided to start programming in Ruby. Can you expand on what you’re saying here or why you’re raising this is as an issue with ruby the language or rails the library?

There are several people earlier in this very thread who moved from C++ to Ruby.

Re: Ruby on Rails Audit Complete

#129

Post by andrekandre »

PapaPalpatine wrote: post #59
Hnus wrote: post #58

Earlier quoted context omitted.

You don't miss things like enums, exhaustive switch or any other basic language features? How about `method_missing` its such a crazy idea to me that something like this exists, I know why it exists but I am like why, why such bloat and complexity.

No, I honestly don’t. I can emulate an Enum without having an Enum type. I rely less on a compiler and more on myself with automated tests.

  >  rely less on a compiler and more on myself with automated tests
jme, but i think this is a muscle that a lot of people don't have developed if they came from a language/toolset/ide that does automatic type checking and autocomplete reliably etc

Re: Ruby on Rails Audit Complete

#130

Post by mvdtnz »

ukprogrammer wrote: post #12

The productivity of Rails for B2B 'CRUD' software is unmatched. Surprised to not see more newer startups make use of it!

The idea that Rails productivity is "unmatched" is such a holdover from 13 years ago. You can like Rails all you want but it is very much matched by several quality frameworks today. Many of which don't suffer from Rails' very real downsides.
Post reply on HN